Clinic online booking: where patients drop out

A front desk fills gaps on the phone. A caller says they are new, the receptionist asks about insurance later, and the booking still goes through. A web form has no receptionist. It asks for every answer up front, and a first-time patient often has to stop and look something up before continuing. A returning-patient lookup wants a patient ID or an old email on file. A consent box can look ticked while the submit button stays disabled. Often the consent text opens in a small window that is hard to scroll on a phone. Each unanswered question is a reason to call the number instead.

• On a phone, can a first-time patient book without a patient ID?
• Does the visit list include a plain option such as back pain or a check-up?
• Can the consent text be read on a phone without opening a second window?
• Does the submit button turn on once every required box is ticked?
• Does the date of birth field accept the format a patient types?

A first visit usually starts from a search result or a referral text, on a phone. The first screen often asks whether the patient is new or returning. Choosing returning sends them to a lookup that wants a patient ID, a date of birth and an email already on file, and a first-time patient has none of those. Choosing new then asks for insurance, a visit reason and consent, all before a single time appears. Each screen looks reasonable alone. Together they ask a stranger to do paperwork before they have seen whether any appointment is free.

A missing visit option and a broken field look the same: the patient leaves and nobody learns why. Start with the visit list. Read every option as a patient would. If none of them fits, the list needs a new option, and no field setting can fix that. Next, open the booking in a private window on your own phone, tick every required box, and watch the submit button. A button that stays grey with every box ticked is a broken rule. A date of birth field that rejects the way a patient types their birthday is a third kind of fault, and it needs its own fix. Write down which one you hit first. Each has its own fix.

Start with one simulated visitor on a phone, using the task below. Keep every detail made up. Do not type a real patient's name, date of birth, insurance number or health notes into a test, and do not upload a patient list. The visitor has an email inbox, so a confirmation email reaches it. A code sent by text does not reach a visitor, and a payment step needs a real card, so a run stops at either one. The report shows the field and the screen where it stopped. A test does not check your booking against any privacy or health records rules, so that review still belongs to you.

How a signup flow test works

The first run finds the field. The fix changes it: a new patient route, plain visit names, consent text that reads on the page. Run the same first-time patient again and check whether a time now appears before any registration question. Run it again after the clinic changes its consent wording, adds a clinician or updates the booking tool, since each one can rebuild the form. Run it before you send paid traffic to the booking page.