Does a med spa need a chatbot?
Probably not yet
The honest answer to whether a med spa needs a chatbot is probably not yet, and the reason is on the site that would host it.
We build one. Claire answers what a front desk answers, at the hours nobody is at the desk, and moves the conversation toward booking. We would like every practice to have one. We still say not yet to most practices that ask, because a chatbot sits in front of whatever the practice’s booking path already does, and on the paths we walked, what it already does is often the problem. A chatbot in front of a broken booking path does not fix the path. It makes the failure conversational.
This article is the argument for that order of operations. It uses what we saw on 221 med spa booking paths across North and South Carolina in August 2026, and it concedes at the end what that audit cannot tell anyone about chatbots.
What a chatbot is for
Strip the vendor language away and a chatbot on a med spa website does two things. It answers the questions the front desk answers all day: what the practice offers, what a treatment costs, what to do before and after, hours, parking. And it walks whoever is asking to the place where they can book. The first job is answering. The second is handing over.
The second job is the one that matters here, because it is the one the chatbot does not do itself. It cannot show an appointment time. It can only take a visitor to the thing that shows appointment times, which is the practice’s booking vendor, the same calendar or form the site already links to. The chatbot page on this site says as much in its own words: it works with the site a practice already has, and if the booking path underneath it is broken, we say so on the call rather than sell the chatbot.
So the question of whether a practice needs a chatbot is really two questions. Is there something to hand people to? And is the handover the part that is missing?
What the handover lands on
We took the booking path on 221 med spa domains, once each, with an automated walker, between 26 and 27 August 2026. What it does and refuses to do is described on the methodology page. After the operator review on 7 September, 36 of the 140 domains where it reached a booking surface had at least one finding, or 25.7%. The denominator is the walked population: findings plus walked-clean plus incomplete. It leaves out the 19 domains a vendor’s robots file kept the walker out of and the 62 where no booking surface was reached, because nothing was walked there.
Look at what those findings are, because every one of them is a place a chatbot would deliver somebody to.
13 are a phone-verification wall. The booking flow asks for a name, an email address and a mobile number, sends a code by SMS, and shows no appointment time until the code is entered. All 13 are one vendor’s default hosted booking flow, AestheticRecord’s, across 12 practices. 4 are booking links that resolve to an error page. 2 are login walls with no visible new-patient route, and 1 is an account wall that asks for a sign-in or a sign-up before any time appears. 2 are booking widgets that rendered nothing after a 22-second settle. 11 are phone-only, meaning the walker found no online booking mechanism on the pages it walked, which is a business-model choice as often as it is a defect and has its own article. 3 are pages rendering wider than a 390px viewport, 1 is a form that surfaced a page error while it was being filled, and 1 is a redirect loop. 38 findings across 36 domains in total; two domains carry two.
Each of those rows describes what was on screen. None of them describes what a visitor did.
A chatbot in front of a wall
Now put a chatbot on each of those sites and follow the conversation to its end.
On the 13 phone-verification sites, the chatbot answers the price question and the hours question, then offers to book. The visitor says yes. The chatbot hands them to the booking flow, and the booking flow asks for their mobile number and a code before it shows a single time. Nothing about the wall has changed. What has changed is that a visitor who was ready to book after a conversation is now looking at a verification form, and the practice paid for the conversation.
On the 4 broken-link sites, the handover lands on an error page. On the 2 login walls and the 1 account wall, it lands on a sign-in form. On the 2 widget failures, it lands on nothing. The chatbot did its job in every case, and in every case the thing it delivered the visitor to did not show a time.
That is what we mean by making the failure conversational. A broken booking path with no chatbot fails silently: a button leads somewhere, the somewhere is wrong, and nobody emails to say so. The same path with a chatbot fails after an exchange that felt like customer service. The practice now has a transcript of somebody being politely walked into a wall, and the wall is the same wall.
The fix is not the chatbot. It is the repair: the work of making the practice’s existing booking vendor show a time to a stranger, on a phone, before it asks for anything. That is a one-off job, and it comes first, because everything else on the site delivers people to it.
The case for one
The other side’s case deserves to be made properly, so here it is.
The desk is closed for more hours than it is open. People decide on a practice in the evening, on a phone, and the question they have at ten at night is usually one the desk answers ten times a day: what it costs, whether there is parking, what to do the day before. A page can answer some of that. A page cannot answer the follow-up. An assistant can, in the practice’s own approved words, and it can decline the medical questions and hand them to a person, which is the boundary the whole thing is built on.
None of that depends on the booking path. A visitor whose questions are answered at ten at night is better served than one whose questions are not, whether or not they book that night. And the audit has nothing to say about it either way, because the walker asks no questions. It presses the booking affordance and photographs what appears. It has never opened a chat widget and does not know whether one was there.
So the case for a chatbot is real, and it is a case about questions, not about bookings. The mistake is buying it as a booking fix. A practice whose path shows a time on the first screen gets both halves. A practice whose path does not gets the answering half and a very articulate way to reach the wall.
When the answer is yes
Three conditions, and the order matters.
The booking path shows a time first. Open the site as a stranger, on a phone with nothing remembered, and count the screens before a real appointment time appears. If the first thing on screen is a form, a login or a code, the chatbot is second in line. If a time appears, the handover has somewhere to land, and the rest of this list applies.
The desk is answering the same questions more than it is answering new ones. A chatbot earns its place on repetition. If the front desk’s afternoon is prices, hours, prep and parking, those answers can be approved once and given a thousand times. If most calls are genuinely clinical, an assistant that refuses clinical questions will hand most of its conversations back, which is correct and not much of a saving.
Somebody will read what it said. Every conversation it has is readable the next morning. A practice that reads them learns what people ask at night, which is worth having on its own. A practice that never opens the log has bought a thing it is not using.
If all three hold, then yes, and the order of costs says the same thing the order of conditions does. Claire is $199 a month, with no setup fee and no contract to get out of. The repair starts at $750, once. A practice that buys the monthly thing before the one-off thing is paying every month to deliver visitors to the screen the one-off thing would have fixed.
What the audit cannot tell you about chatbots
The walker does not see chatbots. It has no finding class for a chat widget, open or closed, present or absent. It walked the booking affordance on 221 sites and recorded what the booking path showed. Whether any of those practices already runs an assistant, and how it performs, is not in the data. This article argues from what a chatbot would hand a visitor to, not from anything measured about chatbots.
Nothing here is a consequence. We have not measured what a phone-verification wall costs a practice, with or without a conversation in front of it, and we are not going to invent a figure for this paragraph. The wall is what was on screen. The rest is argument.
The sample is a prospecting queue, not a market. The 221 domains came from metro text searches for med-spa-type businesses, filtered by a predicate that excludes practices we had already written a friction brief about, which biases the finding rate down. 188 of the 221 are in the Charlotte area. Any service-area claim in this piece is about the Carolinas and nothing more specific.
73 domains were incomplete, a third of the sample, because the walker stalled at a vendor’s first screen with neither a time nor a wall visible. They stay in the 140 because nothing was proven about them in either direction, and any of them could be exactly the clean first screen a chatbot needs.
A headless browser is not a patient, and it is not a chatbot either. One visit per site, in a single forty-one-hour window, on an unattended machine. Every figure is pinned to two dates: measured 27 August 2026, reviewed 7 September 2026. Some of these paths will have been fixed since.
How to decide without us
Four steps, and none of them needs a vendor on the call.
- Open your own site on a phone, as a stranger, and press whatever books. Count the screens before a real appointment time appears. If the count is more than one, the path comes first. The audit found a form, a login or a code standing before any time in 13 phone-verification walls, 2 login walls and 1 account wall.
- Write down the five questions the desk answered most yesterday. If they are the same five as the day before, that is the chatbot’s job description. If they are clinical, it is not, and the assistant would hand them straight back.
- Look at what the site offers at ten at night. If it is a phone number and a contact form, the after-hours path is a callback in the morning, and an assistant in front of it can take a message but cannot show a time.
- Decide the order on purpose. Path first, then answers.
If you would rather we walked it, we will do that for free, and the report says whether the path is ready for an assistant to stand in front of. If it is, talk to Claire and decide for yourself whether one belongs on your site.