Wedding planner website: the package mismatch

A couple browsing a planner's site wants to know what they are buying before they write anything. The page calls the services 'Full planning', 'Partial planning' and 'Day-of coordination'. They click the request button and find a dropdown offering 'Full service', 'Monthly retainer' and 'Other'. Nothing in the form matches the first choice. A careful couple picks 'Other' and writes a paragraph. A careless one picks the nearest name and leaves. Either way the owner receives a request whose package means something different from what the couple wanted, and sees no problem in it.

• Copy each package name from the page and search for it in the request form. Does every name appear?
• Can a couple tell what each package includes from that package's own section, without opening another page?
• Does the form ask for a budget or guest count before the couple has seen what the packages cover?
• Does the request button open the form, or a calendar that asks for a call before any details?

Planners often name packages by what a couple will feel, such as 'Day-of coordination' or 'Full planning'. The request form is often built from whatever list the form tool offers, such as 'Full service' or 'Coordination only'. The two lists are written by different people at different times, and a package added in the spring can reach the page long before the form changes. The mismatch often goes live with the first page, because no one compares the two lists.

Find the cause by writing the package names down from the page, then searching for each one on the request form with the find-in-page command. A name missing from the form is the cause. A name in the form that the page never describes is a second cause, and it looks like a choice the couple cannot understand. The run follows the same path with a simulated visitor, which reads the packages, picks one and reaches the form, then records the choice and the step where it stopped.

Planners often ask for a budget on the request form, since it helps them decide whether to take the work. A couple who has not seen what a package covers does not know what to name. They may give a figure far below the planner's range and feel they failed the form, or leave the field empty and find it will not submit. Either way the couple returns to the page, where the package list has not changed.

Check it by filling the form the way a couple with no idea of the budget would, then read the field labels. If a required field asks for a number the page never mentions, the cause is where the field sits in the flow. Move the budget question to the call, or make it optional with a range the couple can pick. A simulated visitor shows whether the form submits with that field empty, and what the error says if it does not.

Some planners send the request button to a calendar for a discovery call. The couple sees a calendar before they see a price range, a list of what is included, or a sample timeline. A couple who wants to know whether the planner handles destination weddings may close the calendar without picking a time. The page asked for a commitment before it answered the question that started the visit.

Test a visitor with a specific question, such as remote planning in another city, and see whether the page answers it before the calendar opens. Then test a visitor who only wants an email reply. If the calendar is the only way in, the run stops at the calendar and shows what it displayed. The run records the calendar as the screen it stopped on, with a screenshot, so the fix can name that screen.

A new destination package, a seasonal offer or a second planner on the team can add a name to the page that the form does not know. The change shows up only when a couple reaches the form. Rerun the package path after each change, with each package picked once, and read the form's dropdown against the page. Check it again before a busy season, when new packages tend to appear.