A Booking Page That Wants an Account

The site

A dental practice with a clear site and a prominent Book Appointment button.

The button opens a page headed Create an Account, with fields for a name, an email address, a password, a password confirmation, and a checkbox for terms.

There is no way past it.

The appointment request itself is on the next screen, after an email has been confirmed.

The inference a visitor makes

• I want an appointment, not a relationship.
• Another password to remember.
• Will they email me forever.
• This will take five minutes.
• I will telephone instead.

The last is the outcome, and it is not a failure the business notices, because the telephone rings and somebody books. What does not happen is the person who was not going to telephone.

The account serves the business

Which is worth being honest about.

It lets the practice hold a record, send reminders, and let somebody manage bookings later.

All of those are genuine benefits and every one of them can be delivered after the booking rather than before it.

The account requirement placed first is convenience for the system rather than for the person using it.

So the question is not whether to have accounts at all, but where in the sequence to ask for one.

Asking after the appointment has been confirmed converts a barrier into an offer somebody can decline.

The password is the specific problem

For a business somebody uses once or twice a year.

Nobody remembers a password chosen for a dental practice eleven months ago.

So the second booking is a password reset, which is another email, another wait, and another form.

A practice with accounts and annual visits has, in effect, built a system where every returning patient goes through a recovery flow.

That is worse than no account at all, and it is invisible from the inside because the reset emails are automated.

Count how many password resets your system sent last year, which is the measurement of this problem.

A worked example

A clinic changed the order: the booking form first, asking for a name, a telephone number, an email address, and a preferred time.

The confirmation screen then offered an account, explaining that it let them change the appointment without calling.

Online bookings roughly doubled in three months.

About a third of people took the account when offered afterwards, which is a third more than were taking it before, since previously they had simply left.

The practice kept every feature it had and changed only the sequence.

Nothing was built and nothing was removed.

What the form actually needs

Which is less than these systems ask for.

A name, a way to reach them, and what they want.

Everything else, including the address, the insurance details, and the medical history, can be collected once the appointment exists.

A practice can send a form afterwards, or take the details at the desk, both of which are what happened before the site existed.

Every field before the booking is a chance to lose it, and every field after it is a routine administrative step somebody will complete.

Move the fields across that line rather than removing them entirely.

Nothing is lost and the sequence is what changes.

Confirming an email before booking is the worst version

Since it introduces a wait into a decision.

Somebody deciding to book has a moment of intent, and sending them to their inbox ends it.

They open the email, get distracted by three others, and the appointment is not booked.

Confirm the address afterwards if you need to, by sending the booking confirmation to it, which verifies it and delivers something useful at once.

That is the same verification with none of the interruption.

Count what this costs

Which is measurable and almost never measured.

Your booking system knows how many people reached the account page and how many completed a booking.

The gap between those two numbers is the cost of the requirement.

For most practices it is between half and three quarters, which is a figure that ends the discussion.

Ask whoever supplies the system for it, since they can produce it in a minute and rarely volunteer it.

Keep the telephone number beside the button

Which is the cheapest protection while any of this is being fixed.

Somebody who abandons the account page needs an obvious alternative on the same screen rather than having to navigate back to find one.

A tappable number directly beside the booking button catches the people the system is losing, immediately, with no development work at all.

That is not an argument for leaving the booking flow as it is; it is the thing to do this afternoon while the flow is being reconsidered.

Watch whether calls rise after adding it, since that rise is a direct measurement of what the account requirement was costing.

The counter-case within the site

The rest of the site is good.

The practice explains its services plainly, publishes fees for common treatments, names the dentists with photographs, and has a clear answer about emergencies.

The booking system is bought rather than built, and the account requirement is a supplier's default rather than a decision anybody made.

Some systems genuinely cannot be configured otherwise, which is a reason to ask the supplier and, failing that, to reconsider the supplier.

And a business where every customer is genuinely recurring has a much stronger case for accounts than a once-a-year practice does.

Even there, the sequence argument holds: offer it after the first booking rather than before anybody has received anything.

The customer who has just booked is considerably more willing than the one who has not received anything yet.

Willingness follows value rather than preceding it.

What to change

1. Put the booking form first.
2. Ask three fields.
3. Offer the account afterwards.
4. Explain what it gives them.
5. Verify the email by confirming the booking.
6. Collect the rest later.
7. Ask for the drop-off figure.

Step seven is what settles this internally, since the number of people who reached the account page and never booked is available today and nobody has asked for it.

The shop version of this argument is covered in guest checkout versus making an account.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.