AI receptionist for client booking: where it breaks and how to test it before you buy

Not "a bot". You are buying four parts connected to each other:

• 1. The channel. A tracking phone number sitting in front of your main line, WhatsApp, Telegram, or web chat.
• 2. The model. The part that runs the conversation and works out what the person wants.
• 3. Your booking system. YClients, Dikidi, a practice management system, an ERP, or your own database. The bot must write where your receptionist writes — otherwise you end up with a second, shadow schedule.
• 4. The handoff rule. When the bot must stop talking and pull in a human.

A vendor demo shows you the first two: pleasant voice, snappy answers. The third gets a one-liner — "we integrate with that". Nobody demos the fourth, because it is invisible in a demo: it only fires when the demo goes off-script. And your friend whose "bot messed everything up"? That's the part that broke.

The most common complaint about off-the-shelf services is always phrased the same way: "it doesn't answer, it clarifies". The customer asks about a specific service, the bot replies with a counter-question. A second counter-question and the customer hangs up.

This is not a feeling — it is measurable. On an outdoor-gear e-commerce project I ran a blind comparison of my own chat against a paid subscription widget across 49 questions. The score: 34 : 12 with 3 draws in favour of my build. The real difference was not intelligence but willingness to answer: on 21 of the 49 questions the paid widget asked a counter-question instead of answering. Mine did that zero times. Usefulness scored 4.14 against 2.96; completeness 3.98 against 2.90.

To be straight with you: that measurement was on an online store, not a salon. But the failure mode is identical — a closed subject area and a question your own data can answer precisely. Full write-up with the methodology: AI sales chat replacing a SaaS widget.

This is the only honest way to compare two services. It needs no engineer and no budget:

• · Pull 150–200 real inbound messages: your receptionist's WhatsApp threads, marketplace enquiries, call recordings. In that comparison the questions were built from 174 real customer enquiries.
• · Compress them to about fifty across a grid of 7 customer types × 7 funnel stages — from "never heard of you" to "already decided, just checking the warranty". The grid is what stops you from collecting fifty variants of "how much does it cost".
• · Put every question to both services, drop the answers into a spreadsheet, and strip the labels. A human grades them without knowing the source — blind is the whole point, otherwise you are scoring your expectations of the brand, not the answers.

One warning from experience: do not hand the grading to another model. I started that way and dropped it — the model-as-judge systematically waved through failures exactly where they mattered most, on product-choice questions: the answer looked coherent, so it "passed". I replaced it with a strict reference check, where each question has a pre-recorded list of facts the answer is required to contain.

In a cheap setup, services, staff and prices are typed into the prompt once at launch. Then Katya goes on leave, colouring with the senior stylist starts taking three hours instead of ninety minutes, a second manicure room opens — and the bot keeps saying whatever it was told back in March.

The right way is to pull the catalogue of services, staff, durations and rooms from the booking system into the conversation context at the start of every call. Then the schedule isn't "synced nightly" — it is simply always current, because there is one source of truth and it's your YClients, not the bot's settings screen.

A second consequence of the same principle: the bot needs many scenarios, not one script. My salon architecture carries 14: new booking, reschedule, cancel, price question, stylist consultation, and so on. Testing this in a demo is easy — ask to be booked with a named specialist for a named service, but no earlier than Thursday evening. A single-script bot falls apart right there. Architecture in detail: voice agent booking straight into YClients.

This is that fourth part. The bot has to know how to stop. In my builds two signals drive it: speech recognition quality, and the model's confidence that it understood the request. If confidence drops below 0.7, or the bot fails to understand after two clarifying attempts, the call switches to a live receptionist during the day or goes into a callback queue at night. The threshold itself gets tuned over the first two weeks after launch — from call recordings, not from guesswork.

The point worth the whole section: in the premium segment a bad experience costs more than a lost booking. "A clumsy booking beats no booking" is a poor rule when the average ticket is high and clients stay for years.

Where a mistake is dangerous, a layer of hard rules sits on top of the model and overrides it. In my dental architecture that's how red flags work: a temperature above 38 °C together with swelling, an inability to open the mouth, a recent tooth injury — top priority immediately, bypassing the model entirely. The model does not get to change its mind.

The most frustrating one, and the most common. On an e-commerce project the brief sounded simple: when a call is missed, text the customer the real shipping date instead of the stock "we'll call you back soon". It turned out there was no calendar shipping date anywhere in the order. I checked and discarded four candidate sources in a row. The only carrier of the promise was the name of the shipping tariff the customer picked at checkout — that is where they saw a date and agreed to it.

Two weeks of work came down to one design decision that had to be found before writing any code. Which is why the reply there is built as a ladder: promised date in the future — quote the date; date already passed — never repeat it, say honestly that we're checking; order found but no date derivable — talk about the order without inventing promises; customer not found — a neutral reply and a queue entry for a human. The overdue-date rule was validated against an export of more than 11,000 orders. Full write-up: missed calls and auto-SMS with a real ship date.

Now translate that to your business. Want the bot to send a day-before reminder naming the specialist? First check that the booking record actually holds both the specialist and the phone number, and that phone numbers are stored in one format rather than three. Data review first, code second — otherwise the bot starts politely making things up.

The conversation is half the job. The other half is the set of actions the bot invokes itself, in whatever order it decides: find an open slot, book, reschedule, cancel, pull up the client card with visit history. Not "an operator will move it manually later" — the bot does it in your booking system, with conflict checking.

And the thing that matters more than a pretty voice: after booking, the client gets a confirmation with a link to the ordinary booking card in your system. They open it, see the specialist, the time and the address, and can reschedule or cancel themselves — exactly as if a receptionist had booked them. That removes the client's core anxiety: "did it actually book me, or did I just talk to an answering machine?"

On my side these are two distinct services: 24/7 client booking from 50,000 ₽ — voice and chat in one scenario, and voice call automation from 80,000 ₽ if what you need is the phone line with answers to common questions. Typical timeline in my practice is 4–6 weeks from kickoff to launch. All customer-facing pricing sits on the pricing page.

Every conversation with the bot carries at least your client's name and phone number. In a clinic, health information too. You are the one accountable for it — not the contractor, and not the service you plugged in.

The working pattern looks like this: personal data lives in a database on a server inside Russia; the model receives only de-identified attributes — age bracket, gender, symptoms — with no name, phone or ID details; the mapping between a conversation and a specific person stays local; consent is requested before the conversation starts and lands in a consent log. Separately: phone numbers and email addresses are stripped before anything is written to conversation logs, so they don't spread through your log files.

For healthcare this is its own conversation, and it belongs before the contract is signed rather than after the first inspection. How I build it: dental voice agent with triage under Russian data law (152-FZ).

The section that will never appear in a product company's deck. Five cases where I talk people out of it:

• · Too few enquiries. I don't quote a threshold in enquiries — it depends on what one booking is worth to you. Pull a month of telephony logs, see how many enquiries you lose and what a booking earns, then weigh that against the cost: from ₽50k to build plus monthly support. If your receptionist copes, there is nothing to buy, and I will say so.
• · There is no booking system. If the schedule lives in a paper diary, phone notes or a chat thread, the bot has nowhere to write. Booking system first, bot second. Cheaper and more useful in that order.
• · The personal relationship is the product. One specialist, regular clients, bookings through the owner's personal Telegram. A bot would wedge itself into precisely what people pay you for.
• · Nine calls in ten are "how much is it". If your prices aren't published, publish them and see what's left. You may find there is nothing worth automating.
• · You haven't measured the loss yet. Until you know how many calls you drop and what they are about, there is nothing to buy.

That last one deserves a note. On the missed-calls project the work started not with code but with a data export from the phone system — and the review showed there were 1.6× more missed calls than the owner believed, and that 29% of them already had a voicemail transcript nobody was using. Three facts that appeared in no report. An hour of data export changes both the brief and the quote.

Take this list and put it to anyone — a product 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 against a competitor. Don't have one — will you run it on my questions?
3. 3. On what signals does a conversation go to a human, what threshold is set now, and who changes it after launch?
4. 4. What happens at night, when there is nobody to hand off to?
5. 5. What can the bot do in my system: find a slot, book, reschedule, cancel, pull client 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 a booking card?
7. 7. Where are my clients' names and phone numbers stored, what is sent to the model, and where does the processing consent live?
8. 8. What will I see when the bot gets something wrong: recording, transcript, reason for escalation?
9. 9. What does this cost per month at my call volume, and what happens to the bill if volume doubles?

If a vendor answers nine out of nine with confidence — hire them, whether that's me or somebody else. If the first three turn into "well, that's configurable", you are buying a demo.

Not ready for a pilot — start with the 5,000 ₽ audit: we look at the export from your phone system and your booking records, count what you are losing today, and decide whether you need this at all.