Audit the Branch Selection Step in Online Booking and Appointment Funnels

A booking can fail before the calendar appears

Multi-location booking flows often ask customers to choose a location twice: first on the branch landing page, then again in the booking tool. The second selector may default to a different centre, discard the location parameter or show a list with ambiguous names. The resulting booking may technically succeed while being operationally wrong.

Walk the journey as a customer

Test three paths: start from a branch-specific landing page, start from a generic service page, and start from a campaign link. For each path, record the selected branch at entry, after any redirect, on the booking form and in the confirmation. Include mobile devices and a return visit from the booking provider.

Do not only test the happy path. Try changing the location, using the browser back button, opening the booking flow in a new tab, and refreshing the confirmation page. Check whether the branch choice survives each transition and whether the final confirmation clearly names the intended address.

Score the handoff on five dimensions

1. Context preservation: does the destination retain the selected branch?
2. Choice clarity: can users distinguish branches by locality, address or service—not only by internal code?
3. Capability match: does the chosen branch offer the requested service and appointment type?
4. Error recovery: can the customer correct a wrong selection without restarting the entire process?
5. Confirmation clarity: does the final screen state the branch, date, time and next step?

A page can be fast and visually polished but still fail this test if the location silently resets.

Instrument the steps separately

Where analytics and consent settings allow, measure branch page view, booking CTA click, booking form loaded, branch selected, slot selected and booking confirmed. Keep event definitions stable across branches. If the vendor does not expose a step, state the measurement gap rather than inferring it from a generic page view.

For journeys crossing domains, review whether Analytics cross-domain measurement is supported and correctly configured; Google's cross-domain guidance explains why identifiers may otherwise split a journey into separate sessions.

Example defect log

Test case: mobile booking from Pune-Kothrud page | Expected branch: Kothrud | Actual branch: Baner | Reproduction: CTA → vendor page → default branch reset | Severity: high | Owner: booking vendor | Retest: pending.

This is more actionable than “booking flow is confusing.”

Prioritise fixes

Fix silent branch changes and bookings for unavailable services first. Then address confusing labels, excessive re-selection and cosmetic friction. Compare abandonment only after confirming that events fire consistently; otherwise analytics changes can look like conversion improvements.

Exit criteria

Every tested path preserves or clearly re-confirms branch selection, the service is available at that branch, and the confirmation is unambiguous. Retest after booking-vendor updates and new branch launches.