Implementation of a Voice AI Bot for Appointment Booking

Voice bot for booking: where calls and time are lost

Peak load at the front desk occurs in the first hours after opening and in the evening period: during this window more than half of all inquiries for the day come in, and there are one or two administrators on the line at the same time.

The rest at this time process documents, take payment and accompany patients to rooms — that is physically unable to pick up the phone.

Every such call goes nowhere: some people dial again an hour later, but most simply call the next one on the list, and the booking goes to a competitor.

Missed calls in peak hours are not "a trifle against the background of overall workload" but a direct leak of the flow. Even when the phone is answered, the conversation takes three to four minutes: clarify the service, choose a doctor, free time, dictate the address.

In an hour one administrator closes no more than fifteen inquiries, and any delay — checking with a colleague by phone, finding a card in a paper log — stretches the queue on the line to ten minutes of waiting. People hang up on the fifth minute, and these calls are not reflected in any reporting.

A separate breakdown is manual logging.

While a booking is entered into a log or a spreadsheet, two administrators can create one client for the same time: double bookings surface at the appointment, when the person has already arrived, and they have to be sorted out manually, with apologies and rescheduling.

Overloading administrators makes everything worse at once — both the number of missed calls and the share of schedule errors grow.

It is precisely this bundle "peak → missed call → manual booking → double booking" that is the point where the flow is lost.

We break down how a voice bot for appointment booking closes it: it takes on answering calls during peak windows and automatic customer booking, leaving administrators the complex cases.

Measurable effect: missed calls, workload, share of bookings

We start with baseline measurements on real traffic: share of missed calls during peak hours, median time from the client's first word to a confirmed booking, number of inquiries per administrator shift.

We record the snapshot on the same weekly interval before and after launch — otherwise there is nothing to compare, and any report on the effect turns into a matter of taste.

Line availability for booking changes first. The bot holds several conversations simultaneously, so the line stops being busy during the rush: in the morning and evening windows the share of answered inquiries rises from 60-70% to 95% and above, and repeat calls almost disappear.

Processing time for an inquiry is reduced by sequential field collection without switching between windows: service, specialist, date and time are clarified in one conversation, a free slot is checked immediately, confirmation comes in the dialogue. A typical scenario fits into 40-60 seconds versus several minutes with an operator.

The share of bookings without an operator is the main indicator of autonomy: usually the bot fully closes 50-70% of inquiries, the rest goes to the administrator with context already collected, and nothing needs to be figured out again. The load per shift drops by 2-3 times, the same people process more inquiries in the same hours.

Separately, we count the share of dialogues with transfer to an operator, cancellations and reschedules, and bookings that reached the visit. These figures show which scenario to retrain and serve as the basis for the next iteration.

Voice bot scenarios: hard, dialog, hybrid

The choice of conversation mode determines how many booking rules can be imposed on the voice bot and how predictably it behaves.

The more rigid the question tree, the simpler the audit of steps and the lower the risk of incomplete data; the freer the dialogue, the higher the requirements for parsing the utterance and checking what the bot extracted from the answer.

The key thing we check in each mode is behavior at the boundaries.

If the bot fails to parse an utterance twice, a stop factor triggers such as a request for medical advice or a complaint, or the client directly asks for a human — the call is transferred to an operator together with the dialogue history and already collected fields. The operator does not ask again, but continues from where the bot stopped.

In the pilot we count two metrics: the share of conversations brought to booking without an operator, and the completeness of fields in the created booking.

They are used to choose the mode — usually hybrid, with gradual expansion of the free part as transcripts of real calls accumulate.

Implementation stages: from call analysis to handover to support

The work proceeds sequentially: each stage relies on the result of the previous one, so the scenario is not rewritten on the fly but refined based on facts. Below is the order in which we conduct voice bot implementation.

How the order of work is structured

1. Audit of incoming inquiries. We take recordings and transcripts for a period and label them by topic: booking, reschedule, cancellation, service question, refund. We count shares and dialogue length — it is visible which 15–20 scenarios cover the bulk of calls, and what is more honest to give to a human right away.
2. Call routing scheme. We fix: which number goes where, during which hours the bot answers itself, by what signs it transfers to an operator, what it does on a dropped call and repeat call. Here we also define points where the bot must request confirmation.
3. Scenario and integration with the schedule. Utterances, branches, dictionaries of service names — we proofread the wording to reduce the number of clarifying questions. We check work with free slots: the bot does not book busy time twice, but offers the nearest alternative.
4. Trial operation of the bot. First synthetic calls across the full set of branches, then a limited share of live traffic with transfer to an operator on the first failure. We collect metrics: share of dialogues without transfer to a human, average duration, number of clarifying questions.
5. Acceptance of the voice scenario. The customer runs a control set of calls: typical branches, rare cases, connection drop. The criteria are correct entries in the schedule, absence of duplicates, and clear transfer to an operator.
6. Handover to support. We hand over access, the routing scheme, the scenario description and the procedure for editing utterances; we teach employees to read transcripts and change the logic when the schedule changes.

Handover package: scenarios, integrations, regulations, access

The handover package is not a folder with reports, but a working set: with it your team edits utterances itself, adds a doctor or branch, and troubleshoots failures.

Therefore, we assemble each item below so that it can be opened without us and it is clear what to change and where.

• Dialogue scenarios — branches for booking, rescheduling, cancellation, clarifying the specialist and address; utterance texts, pronunciation variants of names, behavior when the caller interrupts or is silent.
• Inquiry escalation rules — conditions for transferring the conversation to an operator: an unrecognized request after several clarifications, a conflictual phrasing, a request to change an existing booking, an urgent case outside the schedule.
• Connection to the booking system — which entities the bot reads and which it creates, the authorization scheme, a test environment for checking edits, behavior when the external system is unavailable (what the bot says and where it writes the request).
• Voice bot documentation — scenario map, dictionary of entities and synonyms, description of fields and booking statuses, instructions for editing utterances and adding new branches.
• Support procedure — what changes we make on request, response times by failure classes, who on your side approves texts and when changes are rolled out.
• Access and ownership — accounts, roles and keys are registered to the customer, the entire edit history is in your environment, and when work is completed nothing remains "on our side."
• Metrics and reporting — share of bookings closed without an operator, share of breakdowns at the confirmation stage, time to answer; we will agree where we look at these indicators and with what frequency.

Acceptance follows the same list: we check each item in the test environment — run the scenario, break the connection to the booking system, trigger escalation. What cannot be reproduced on your side has not been handed over.

Case: appointment booking in a clinic network — before and after implementation

Before: peak hours and lost inquiries

The clinic network had three lines for administrators: in the morning hours and after work, the share of answered inquiries fell to 62%, the rest of the calls went to missed — some patients never reached an administrator.

Booking confirmation stretched to several hours: the request was recorded in a log and returned to when the line became free.

A separate loss category was cancellations by mistake: the administrator mixed up the direction, doctor or time, and for such an inquiry the booking had to be redone.

After: first line on a voice bot

A voice bot was placed on the first line, which handles the inquiry entirely: clarifies the direction, doctor and convenient window, checks against the schedule and confirms the booking.

Speech recognition was configured for medical vocabulary — names of specialties, doctors' surnames, phrasings like "next week after lunch"; when unsure about an answer, the bot transfers the call to an administrator rather than guessing. Confirmation is sent immediately after the conversation, and no repeat call to clarify is needed.

Metrics before and after:

• share of answered inquiries — from 62% to 97% in peak hours;
• time to booking confirmation — from several hours to a minute of conversation;
• cancellations due to a booking error — from 18% to 3%;
• the load on administrators shifted to complex cases: reschedules, questions about preparation for the appointment, working with those who ask for a live interlocutor.

Technically, the project relies on cloud speech recognition Yandex SpeechKit and integration with the clinic's schedule, so the bot sees only free slots and does not create double bookings.

What was the bottleneck before implementation is visible from the first figure: the growth in the share of answered inquiries gave an increase in bookings without expanding staff.

How is a dialog scenario different from a question tree?

A question tree is a pre-built graph: an intent corresponds to a transition, the route is set by the scenario author. A dialog scenario maintains conversation state: it stores collected information and at each step decides what to clarify next. The difference is visible where a person answers not according to the script.

Handling non-standard answers is the main divide. The utterance "I'd like next week, but not on Thursday" in a tree does not fall into any branch: the conversation goes to an operator.

The dialog layer parses it into slots — desired time, constraints — and fills in the missing part with a follow-up question.

Speech recognition robustness is the second divide. A tree requires matching the expected phrasing: noise on the line, a slip of the tongue, or a name dictated letter by letter breaks the transition.

A dialog scenario compares several recognition hypotheses and asks for confirmation, retaining the session context.

Scenario maintenance complexity grows differently. In a tree, a new answer variant multiplies branches, and an edit to one question is rechecked across all incoming paths. In a dialog scenario, the data collection rule or the order of clarifications changes.

In practice, the approaches are combined: service selection and time confirmation are kept on rigid rules, while data collection is given to the dialog layer — the scenario remains manageable but stops being fragile.

Technical doubts: speech recognition, noise, transfer to an operator

Engineers usually have the same doubts about a voice bot: what will happen on a noisy line, how it distinguishes a pause from the end of an utterance, and by what logic it gives the conversation to a human. We break down how these situations are handled in the scenario.

How is the conversation transferred to an operator?

Transfer follows explicit rules: a direct request "connect me to a human," several failed clarifications in a row, a topic outside the scenario or a raised tone.

Before switching, the bot gives the operator a short summary — the goal of the call, the data named, the chosen time — so the conversation continues from the middle, not from "hello, how can I help."

How does the bot reschedule and cancel a booking?

A new booking, reschedule and cancellation are separated before confirmation, otherwise the bot creates a duplicate. It finds the existing booking by number or named time, offers the nearest free slots in the schedule, records the change and sends confirmation to the messenger.

If the booking is not found, transfer to an operator is activated with the context already collected.

Let's discuss the task: we'll analyze the call flow and come back with a plan

So that the assessment of voice bot implementation is based on facts, not assumptions, we start with an analysis of the inquiry flow.

Send a call export for a typical week — with duration, queue waiting time and the share of unanswered calls: it shows where bookings are lost, which scenarios the bot closes immediately, and which are more reasonably left to an administrator.

Then we discuss voice bot implementation concretely. For the work plan we need at least this additional context — from it we calculate the load and choose the order of stages:

• recordings or a call export for several working days — we count the share of typical inquiries and repeat questions;
• list of booking scenarios: directions, branches, rules for rescheduling, cancellation and reminders;
• access to telephony and its settings — queues, voice menu, call recording;
• description of the system where the bot places the booking, and its software interface for data exchange;
• requirements for personal data processing and retention periods for call recordings;
• contact of the administrator or call center manager — we will verify the wording and escalation rules.

As a result, you receive not a generic presentation, but an analysis of the inquiry flow, a call routing scheme, draft scenarios and a stage plan with the order for starting work. Describe the task — we will come back with an assessment and a plan.