AI receptionist for client bookings: where it breaks and how to check it before you buy

You are buying four parts connected to each other:

• 1. The channel. A phone line (calls are forwarded from your main number), WhatsApp, Telegram or a chat on your website.
• 2. The model. A language model runs the conversation and works out what the person wants.
• 3. Your booking system. An online booking service such as Fresha, Booksy or YClients, a clinic management program such as Dentrix or Open Dental, another booking system with an API, or your own database. The bot must book into the same place as your receptionist. Otherwise you end up with a second, shadow schedule.
• 4. The handover rule. When the bot must stop talking and bring in your receptionist.

A demo shows you the first two parts: a pleasant voice and quick answers. For the third, you hear “we have an integration”. Nobody shows the fourth: you only see it when a conversation goes off script. What breaks there, and how it sounds in a real conversation, is covered in section 05.

Complaints about these bots all sound the same: “it doesn't answer, it just asks for details”. A customer asks about a specific service, and the bot comes back with a question of its own. After the second counter-question, the person hangs up.

This can be measured. On a project for an outdoor gear shop, I ran a blind comparison of my own chat against a paid subscription widget on 49 questions. The score was 34 to 12 in my chat's favour, with three draws. The main difference was the willingness to answer: on 21 of the 49 questions the widget replied with a counter-question, and my chat never did. Usefulness scored 4.14 and 2.96, completeness 3.98 and 2.90. Every answer was graded on the same scale, and the grader didn't know which service had written it. So what matters is the gap between the scores: on their own, the numbers say little.

A caveat: I made this measurement in an online shop and haven't repeated it in salons. The failure works the same way there: a narrow subject, and a question your own data can answer precisely. Full write-up: an online shop's own AI sales assistant.

First, how long it takes. The short version takes half an hour. Take 15 questions from last week's messages and put them to both services. Collect the answers in a spreadsheet and remove the labels showing which is which. That is enough to see which one dodges answers. The full 49-question grid described below takes 2–3 days of work. People usually do it before paying for a year up front.

The full procedure looks like this. You don't need a developer or a budget, only time:

• · Collect 150–200 real enquiries: your receptionist's messages, questions from marketplaces, call recordings. In that comparison there were 174.
• · Cut them down to about fifty using a grid of 7 customer types × 7 stages of buying, from “I've never heard of you” to “I've already decided, I'm just checking the warranty”. The grid stops you from collecting fifty versions of “how much is it”.
• · Put each question to both services, collect the answers in a spreadsheet and remove the labels. The grading must be done by a person who doesn't know which answer came from where. Otherwise you are grading your expectations of the brand.

And a warning: don't hand the grading to another model. I started that way and gave it up. The judging model let failures through exactly where they mattered most: if an answer sounded coherent, it passed. Now I check against a reference: for every question, the facts the answer must contain are written down in advance.

In a simple setup, services, staff and prices are typed into the bot's instructions once, at launch. Then Katya goes on maternity leave, colouring starts taking three hours, and a second manicure room opens. The bot keeps saying what it was told in March.

It works properly when the bot pulls the list of services, staff, durations and rooms from the booking system at the start of every call. Then the schedule is always up to date, because the data comes from one place: the booking system your receptionist already uses.

The second point: the bot needs many scenarios. My salon setup has 14: a new booking, rescheduling, cancelling, a question about prices, choosing a stylist and others. This is easy to test in a demo: ask to be booked with a specific stylist, but no earlier than Thursday evening. A setup with a single scenario breaks right there. The details are on the page for a voice agent that books straight into a salon's booking system.

This is the fourth part I mentioned at the start. The bot must know when to stop. My setup uses two signals for this: the quality of speech recognition, and the model's confidence that it understood the request. Confidence is a score from 0 to 1, where 1 means “understood exactly” and 0 means “didn't understand at all”. If the score falls below 0.7, or two clarifying questions in a row get nowhere, the conversation goes to a live receptionist during the day or into a callback queue at night. The threshold is tuned during the first two weeks after launch, using call recordings.

Why this matters: in the premium segment, clients stay with you for years, and one bad conversation with a bot can drive them away. So a bot that isn't sure of its answer hands the conversation to a person.

Where a mistake is dangerous, I put hard rules on top of the model. In my dental clinic setup, this is how red flags work: a temperature above 38 °C with swelling, being unable to open the mouth, a recent injury to a tooth. They immediately set the highest priority, and the model cannot change that decision.

The most frustrating one. On a project for an online shop the task sounded simple: after a missed call, send the customer a text with the real shipping date. It turned out the order held no shipping date anywhere: I checked four possible sources and ruled them all out. The promised date existed only in the name of the delivery option. That is where the customer saw it and agreed to it.

Everything hinged on one decision that had to be found before any code was written. So the reply is built as a ladder. If the date is still ahead, we give it. If it has passed, we don't repeat it and say that we are checking. If there's no date, we write about the order without making promises. If the customer isn't found, we send a neutral reply and queue the case for a person. The rule for overdue dates was tested on an export of more than 11,000 orders. Full write-up: missed calls and a text with the real shipping date.

Now apply this to your business. Want a reminder the day before, with the stylist's name? Check that each booking record holds both the stylist and the phone number, and that all phone numbers are stored in the same format. Data first, code second.

The conversation is half the job. The other half is actions in your system: find a free slot, book, reschedule, cancel, open the client's card with their visit history. The bot does these itself, in the right order, and checks for clashes.

Just as important is what the client receives after booking: a confirmation with a link to the ordinary booking card. They open it, see the stylist, the time and the address, and can reschedule or cancel the visit themselves, just as if the receptionist had booked them. This removes the main worry: “Did it really book me, or did I just talk to an answering machine?”

I offer this as two services: round-the-clock online booking from 90,000 ₽ (voice and chat in one scenario), and a voice agent for incoming calls from 150,000 ₽ if what you need is specifically the phone. Launch takes 4–6 weeks. All prices are on the pricing page.

Every conversation with the bot includes at least your client's name and phone number, and at a clinic, health information too. You are the one responsible for it.

The working setup looks like this. Personal data sits in a database stored where local law requires, for example in an EU region. The model receives only details that can't identify the person: age group, sex, symptoms. The record of which conversation belongs to whom is kept in the same database. At the start of each conversation the bot asks for consent to recording and data processing, and the consent is saved in a log. Phone numbers and email addresses are removed from the text before it goes into the conversation log.

For healthcare this is a separate conversation, and it's best to have it before the contract is signed. The design is described on the page for a voice agent for a dental clinic. What counts as personal data in a chatbot conversation, why replacing a name with a number often protects nothing, and how to check your own system in twenty minutes are covered in the article on personal data and AI models.

Here are five cases where I talk people out of buying one:

• · Too few enquiries. I don't name a threshold in numbers of enquiries: it differs for every business and depends on what one booking brings in. Take a month of call logs, count how many enquiries you lose and what one booking is worth, and weigh that against the cost: from 90,000 ₽ to launch, plus support. If your receptionist manages to answer everyone, there is nothing to buy, and I'll say so.
• · Bookings aren't kept in a system. If your schedule lives in a paper diary or a chat thread, the bot has nowhere to write. Booking system first, bot second.
• · The personal touch is what you sell. One specialist, regular clients, bookings through the owner's personal Telegram. A bot would get in the way of exactly what people pay you for.
• · Nine calls in ten are “how much is it?” Publish your price list on your website and see what's left. There may be nothing left to automate.
• · You haven't counted your losses yet. Until you know how many calls you miss and what they are about, there is nothing to buy.

More on that last point. On the missed-calls project, the work started with an export from the phone system. It showed about two-thirds more missed calls than the first estimate, and 29% of them already had a voicemail transcript that showed what the call was about. An hour spent on the export changes both the brief and the quote.

Take this list and put the questions to anyone: a software company, an agency, me. The first three usually settle it.

1. 1. Where does the bot get services, staff and durations: from the booking system at the start of every conversation, or once during setup?
2. 2. Show me a blind comparison with a competitor. If you don't have one, will you run one on my questions?
3. 3. What signals send a conversation to a person, what threshold is set now, and who changes it after launch?
4. 4. What happens at night, when there's nobody to hand over to?
5. 5. What can the bot do in my system: find a slot, book, reschedule, cancel, pull up a client's history? And what can't it do?
6. 6. What does the client get after booking: the bot's word, or a confirmation with a link to the booking card?
7. 7. Where are my clients' names and phone numbers stored, what goes to the model, and where is the consent to data processing kept?
8. 8. What will I see when the bot makes a mistake: the recording, the transcript, the reason for the handover?
9. 9. How much will this cost per month at my call volume, and what happens to the bill if the volume doubles?

If a vendor answers all nine with confidence, hire them, whether it's me or someone else. If the first three already get “well, that can be configured”, you're buying a demo.

A pilot costs from 60,000 ₽ and takes 1–2 weeks: one channel, one scenario, your booking system. A full launch costs from 90,000 ₽ for online booking and from 150,000 ₽ for a phone voice agent, and takes 4–6 weeks.

Not ready for a pilot? Start with the 5,000 ₽ audit: we'll go through the export from your phone system, count how much you are losing, and decide whether you need this at all.