What makes a med spa booking path longer
The short answer
A booking path is as long as whatever was switched on, and almost none of it was chosen.
Ask a practice what stands between the booking button and an appointment time and the answer is usually a guess, and usually short. The path was set up once, by somebody who already knew the way through it, and it has not been walked cold since.
So this article is the same journey rendered twice: the shortest version that can exist, then the version most practices end up with. Reading them beside each other is the quickest way to see what got added, and by whom. We are not going to tell you the number. We have never counted screens across a sample and we are not going to invent a figure here. What we can do is fix the unit, show you both versions, and hand you the question to ask at each step of your own.
What counts as a step
The count is meaningless until the unit is fixed, and there are at least four units in play.
A screen is a page or a modal that replaces what was there before. A tap is any deliberate action — a button, a dropdown, a checkbox. A decision is a point where the visitor has to know something in order to continue: which service, which location, which provider. A field is a box that has to be filled.
These give different answers about the same path. A screen asking for first name, last name, email and mobile number is a single screen, a few taps, no decisions and four fields. A screen offering a dropdown of service categories is a single screen, a single tap, and a decision a first-time visitor may not be equipped to make.
We use the decision as the unit, because it is the one a visitor feels. Filling in a name is tedious. Being asked to choose between “Injectables” and “Aesthetic Consultation” when you wanted to ask about a line on your forehead is the point at which somebody closes the tab and decides to think about it later. Count taps instead if you prefer — just say which you counted, or the number means nothing to the person you quote it to.
The shortest path that can exist
Here is the whole thing.
Somebody arrives on a phone. They tap a control that says Book. Appointment times appear. They choose one. They give a name and a phone number. It is confirmed.
That is not hypothetical. Paths that reach selectable appointment times with nothing standing in front of them are a lane the audit records, and real practices are in it. Nothing about the short path is unusual or expensive.
Notice what it does with the order. Everything the practice needs is still collected. All of it is collected after the thing the visitor came for has been shown. Nothing was removed to make the path short — it was sequenced.
The path most practices have
Same visitor, same phone, same intent.
They tap Book. A booking surface opens, hosted somewhere other than the website, and asks them to choose a location. Then a service category. Then a specific service, from a list written in the vendor’s vocabulary rather than the practice’s. Then a provider, from a set of names a first-time visitor does not recognise, with no option for whoever is free. Then a screen asking for first name, last name, email address and mobile number, with consent checkboxes underneath it. Then a code sent by text, which has to be read off the same phone and typed back.
Then the times.
Then they choose one, and there may be a card to enter before it is held.
Every screen in that sequence is defensible on its own. Put together they are a different journey from the short path, and the difference is not design, effort or budget.
Where the extra steps came from
Nobody sat down and built the long path. It assembled itself, out of three kinds of decision that were each made somewhere else.
The vendor’s defaults. A hosted booking product ships with a flow already switched on, and most practices never reopen its settings after the day it was installed. Verification before times is one of those defaults. It is worth being fair about: text verification cuts fake bookings and no-shows, and a vendor that ships it switched on is not doing anything underhanded. It is still a step, and it is still one nobody at the practice chose.
The service menu. Catalogues grow. Each new treatment gets its own entry, and once there are enough entries somebody groups them into categories, and the grouping becomes a screen. The list is organised the way a practice thinks about treatments, which is not the way a first-time visitor thinks about the thing they want fixed.
The front desk. Provider selection is usually there because somebody asked for it. So is the deposit, the intake question, and the box about how they heard of you. Each was a reasonable request from a person with a real problem to solve. None of them was weighed against the sequence it landed in, because nobody was looking at the sequence.
That is the honest shape of a long booking path: a stack of small, locally sensible decisions, made by people who were never looking at the same screen.
What a longer path is not
A longer path is not a broken one. Every screen in the version above works. Somebody who wants an appointment badly enough will get to the end of it, and plenty do.
What this article does not measure is what the extra steps cost. Nothing in our audit data would let us. We walk booking paths and record what was on screen; we do not see who left, when they left, or whether they rang the front desk instead and booked that way. Anybody who tells you each additional step costs a fixed share of bookings is quoting a study of somebody else’s checkout, not of your practice.
A longer path is also a different problem from a path that stops. If yours never reaches an appointment time at all — a wall it cannot get past, a booking link that resolves to an error, no booking control anywhere on the site — that is a failure rather than friction, and we have written up the ways a booking path fails separately. This piece assumes yours works, and asks what it asks for on the way.
What we cannot see from outside
Our view of any booking path is a single visit, on a single day, from an unattended machine in one place. We cannot see a returning patient’s path, which is usually far shorter because the account already exists. We cannot see what the flow looks like to somebody already signed in. We cannot see what your front desk sees.
We also cannot see the steps that are not on a screen. A practice that answers every inquiry within the hour has a short path that runs through a person, and none of that shows up in a walk of a website.
And the long path above is a composite. It is assembled from the kinds of screens we see rather than transcribed from a particular site, because transcribing a particular site would name it. Treat it as a shape to hold yours against, not as a claim about anybody.
Walk it once and ask why
Ten minutes, on your own phone, as a stranger would. Not your laptop, and not signed in.
- Go all the way to the last screen before it would confirm. Do not stop at the point where you can see it working. The steps worth finding are the ones past where you normally check.
- At every screen, ask who put it there. A vendor default, a service menu that grew, or somebody’s request. If nobody at the practice can name the reason, that is the answer.
- Ask whether the times would have appeared without it. Anything a visitor is asked for before an appointment time is shown could have been asked for after. That is sequence, and sequence is usually free to change.
- Note which ones are settings rather than code. Verification, account creation, deposits and provider selection are switches inside a booking product far more often than they are anything a developer has to touch. A path can get shorter the same afternoon somebody opens those settings.
You do not need us for any of that. If you would rather we walked it and wrote it up, we will do that for free, and the call is thirty minutes.