The booking screens automation cannot get past
If you came here for a comparison
The search that most often lands on a page like this one is a request for a med spa booking software comparison, and we should say at the top that this is not one. We audited 221 med spa booking paths across the Carolinas, and the audit identified a booking vendor on 135 of the 221 domains. It did not measure which of those vendors books patients well. It measured something narrower and less flattering to us: which vendors’ first screens our own automation could not get past.
That is the whole article. On 73 of the 221 domains the walk stopped at a booking vendor’s first screen, with no appointment times on screen and no wall on screen either, because the walker did not know what to click next. Those 73 are the largest lane in the audit. They are also, in the plainest sense, our failures rather than anybody else’s, and a piece that spent them as evidence against a vendor would be about the wrong subject.
What we walked
Between 26 and 27 August 2026 an automated walker took the booking path on 221 med spa domains across North and South Carolina, once each, over about forty-one hours. It finds the route a new patient would take to book, follows it to the vendor’s first screen, and keeps going until it either sees selectable appointment times or meets something in the way. It is read-only and it honours every robots file it meets. What it does and what it refuses to touch are described on the methodology page; the findings it produced are in the first article. This piece is about the lane that produced nothing.
The sample is a prospecting list, not a survey. 188 of the 221 domains are in the Charlotte area, and the queue they came from excludes practices we had already written to. Whatever the 73 measures, it measures this corpus on that date.
Every domain lands in exactly one of five lanes. As flagged by the walker, before review, they were: 40 domains with at least one screenshot-backed finding, 27 walked clean to appointment times or a fillable form with no wall, 73 incomplete, 19 stopped by a booking vendor’s robots file, and 62 that never reached a booking surface. That is 221. The operator review on 7 September moved four domains out of the findings lane, to 36, and this article uses the reviewed figure everywhere except in that as-flagged list, which is the only set that closes.
What incomplete means
Automation tools like ours typically work from a click grammar: a fixed vocabulary of things they know how to recognise and act on, such as a button whose text says Book, a list of services, or a calendar with times in it. When a screen shows something in that vocabulary, the tool knows its next move. When a screen shows nothing in it, the tool stops. Ours records that stop and moves on.
Incomplete is that stop, at the vendor’s first screen. No wall was seen, so it is not a finding. No appointment time was seen, so it is not clean. Nothing was proven about the site in either direction. The audit’s own caveat is the right sentence and we will not improve on it: the lane measures the walker, not the site.
Seventy-three domains, a third of the sample, sit in it. Of the 140 domains where the walker reached a booking surface at all, 73 are in this lane. The most common outcome of walking a booking path, in this audit, was that our walker did not know what to do next.
Who we could not see past
The table is the lane broken out by whose first screen the walker stalled on. It is a count of stalls, and nothing in it is divided by anything.
| Vendor | Stalled at its first screen |
|---|---|
| Jane | 8 |
| Moxie | 7 |
| Acuity | 6 |
| Square | 6 |
| Fresha | 4 |
| GlossGenius | 4 |
| Mangomint | 4 |
| Boulevard | 3 |
| Meevo | 3 |
| PatientNow | 3 |
| Zenoti | 3 |
| AestheticsPro | 3 |
| Every other vendor | 19 |
| Total | 73 |
The last row is collapsed on purpose. It holds 19 domains across vendors that appear a handful of times each, and in a sample that is 85% one metro, a one-domain vendor cell names a practice by elimination.
The screens the walker most often failed to drive belong to Jane, Moxie and Acuity. That is the whole of what the table says. It does not say how often each vendor appears in the corpus, and we have not set that beside it, because the two counts were made differently and nobody has established that they count the same domains.
The wrong way to read that table
The tempting reading is that Jane, Moxie and Acuity have booking screens that are hard to get through, and that the vendors lower down have screens that are easy. That is the reading a comparison would want, and the data does not support it.
The lane records that our grammar did not recognise a screen. It does not record why. A first screen that defeats a script is very often a screen doing something sensible for a person: asking which location, which category of service, whether you are new or returning, before it shows a calendar. We do not know, per domain, which of those it was, because the walker did not know either. That is what stalling means.
Nor is a stall for our walker a stall for anything else. A patient arrives with a browser and a thumb and reads the screen. A search crawler does not book appointments and never tried. Nothing in this lane says a patient could not get through, and nothing in it says a crawler could not index the page. It says that one script, on one day, did not know what to click.
The fairness runs the other way too. A small stall count does not mean a better-designed first screen. It may mean the vendor is rare in this corpus, or that its first screen happens to present something our grammar already knew, and the table cannot separate the two. Tools like ours drive the screens they were built against. That bias is ours, and it is sitting in the table, which can fairly be read as one thing only: the list of first screens our walker has to learn next. A roadmap for us, not a verdict on anyone.
What the 73 does to the headline
Our headline rate is 36 of 140, or 25.7%: 36 domains with a reviewed finding, over the 140 domains where the walker reached a booking surface. The 140 is findings plus clean plus incomplete. The 73 are in it.
They are in the denominator and not the numerator, which treats every one of them as a path with nothing wrong on it. That is not something we know. Behind a first screen we could not pass there may be a phone-verification wall, a login, or a calendar with Thursday open, and we saw none of it. If some of those 73 have a wall behind the screen, the real rate is higher than 25.7%. Counting them this way biases the rate down, and we chose it because every alternative is a guess.
There is a framing that drops them, and we state it once so nobody has to reconstruct it. Of sites walked all the way to a verdict, findings plus clean and nothing else, the rate is 36 of 67, or 53.7%. We do not use it. Its denominator of 67 is 30% of the audited population of 221, because it discards the 73 incomplete walks, which are exactly the cases where nothing was proven in either direction. Dropping every inconclusive result roughly doubles the rate. That is what this lane is for. It is the reason the honest number is the lower one.
Four domains that may belong here
The operator review on 7 September rejected four of the walker’s phone-verification findings, all of which had fired on gift-card checkout pages the deep walker mistook for a booking flow. Each of those four domains carried no other finding, so each leaves the findings lane and goes either to clean or to incomplete.
Which of the two, for each domain, nobody has determined, and it cannot be determined without a re-audit. So the honest size of this lane is 73 domains as flagged, and 73 or more on review, and the audit declines to assert the split. We decline too. An article about the screens we could not get past should not end by guessing how many there were.
What this does not measure
No vendor in the table is broken. The column is a count of screens our grammar did not recognise. It is not a defect rate, not a ranking, and not a measurement of how any patient fared. The right sentence is “the walker stalled,” never “the software fails.”
It is not a survey. The 221 came off an outbound prospecting queue, 188 of them in the Charlotte area, so the vendor mix reflects who sells into one market. A different metro would produce a different table. The queue also excludes practices we had already written a friction brief about, which biases the finding rate down before anything else does.
A headless browser is not a patient. One visit per site, inside one window of about forty-one hours, on an unattended machine. The next table will differ from this one because we changed, not because anyone else did.
Nothing here measures a consequence. We did not count visitors, bookings or revenue.
Every figure is pinned to two dates: measured 27 August 2026, reviewed 7 September 2026.
If you are choosing booking software
We cannot rank the vendors for you, and after the table you know why. What the audit can support is a check you can run on any of them in about five minutes, with a phone and no account.
- Open the vendor’s booking page on a phone: a demo, a practice that uses it, or your own. Tap Book and keep going to the last screen before an appointment would be confirmed.
- Count the screens before a real appointment time appears. That count is what the audit’s largest finding class is about.
- Look at what the first screen asks. A location, a category, a new-or-returning question is the kind of screen our automation stalls at, and it is fine for a person. A name, an email address and a phone number with a code to follow is a wall before any times are shown, and on 13 of the paths we walked it was a vendor default the practice may never have chosen.
- Walk your own current path the same way, on the same phone, and compare.
If the path is clean, you needed five minutes, not us. If it is not, we will walk it properly for free, and you keep the written report either way. And if your vendor sits near the top of our table, tell us what its first screen looks like. That is how the lane gets smaller.