Why a medical chatbot breaks down under the flow of requests
A medical chatbot breaks down not on speech recognition or the model — but on the flow.
Monday morning: reception simultaneously takes calls, checks in arrivals, and answers in messengers, while a chat request waits for an operator exactly at the moment when it should get an answer fastest.
Peak load on reception is the first point of failure. When there are three times as many requests as usual, the queue grows, some patients close the dialog and book with another clinic.
The loss of a patient request is not visible in reports: an abandoned chat leaves no request, and the next morning no one knows how many people left.
The second is handoff to a doctor. The bot collected the complaint and selected the specialty, but then the request hangs: the free time is already taken, the doctor does not confirm the appointment, and the dialog remains in an uncertain status. The patient is sure they are booked; the clinic is sure the request did not arrive.
Repeated patient questions are the third bottleneck.
Address, schedule, preparation for a test, whether a certificate is needed, how to get to a specialist: this set of facts accounts for most dialogs, and the bot answers “I will check with the administrator” — and automation turns into another channel of load.
The fourth is the gap between booking without an operator and appointment rules. The rules live in regulations and in the heads of administrators: where an appointment is by referral, where there is a separate window for follow-ups, where preliminary preparation is needed.
A bot that simply gives out free time regularly books patients in the wrong place, and the analysis of errors again falls on reception.
All four points are not a model problem but a problem of aligning data, rules, and responsibility for the request. Next, we break down how this is closed.
What automating patient request intake delivers
The effect of implementation is measured not by the number of scenarios but by the shift in operational metrics.
Patients write in Telegram, messengers, and a web widget on the clinic's website — a single entry point allows comparing these flows and seeing exactly where the bot removes load from reception.
Share of requests without an operator
The bot handles booking, rescheduling, cancellation, preparation for an appointment, and typical questions about documents and preparation. It collects the rest and passes it to an operator with ready context: who is writing, to which doctor, what has already been clarified. The share of fully automated dialogs usually stays at 55–75% and grows as the answer base expands.
Time to booking
The patient sees free slots in real time and chooses a suitable one in the same dialog, without waiting for a response or a call back.
The path from the first message to a confirmed appointment drops to 2–4 minutes versus hours of waiting when working through a call center at peak hours.
Drop-offs at peak and even load
The peak of requests is Monday morning and the first hours of booking opening: the queue grows, some patients cannot get through and go to other clinics.
The bot holds parallel dialogs without a queue, so peak drop-offs go away, and the load evens out by hour — evening and lunchtime requests are served with the same quality as morning ones.
Offloading the call center
Operators stop being the first point of contact and switch to complex cases: disputed bookings, insurance questions, coordination of several specialists.
The number of manual touches per dialog falls, and the freed-up time goes where a human is irreplaceable — not to a typical booking scenario.
Automation scenarios: comparing approaches and modes
The choice of dialog mode determines not the “smartness” of the bot but what happens when a request falls outside the scenario. A button tree is predictable but breaks on natural language; a model on language data understands free wording but requires topic restrictions.
A hybrid mode combines both: the scenario handles critical branches — booking, rescheduling, appointment cancellation — while the model covers the free-form part.
Comparison of dialog modes
| Option | When it fits | Limitations |
|---|---|---|
| Rigid scenario | Booking, opening hours, routing by department: the set of actions is known in advance | Does not understand free wording; one step aside leads to a dead end |
| Scenario dialog with prompts | Different phrasings of the same request with rigid branches | Dictionaries and rules grow with every non-standard request |
| Model on language data | Free questions about preparation for an appointment | Answers are limited by topics and checked for accuracy |
| Hybrid mode | Mixed flow: typical operations and free questions | Harder configuration; boundaries between scenario and model need to be marked up |
The limitations of approaches are visible not in a presentation but over the long run: dictionaries are expanded after every non-standard phrasing, and the model is limited by a list of topics.
The rules fix the boundaries — where the bot must clarify, where it answers in its own words, and where it immediately hands off the dialog.
Escalation rules are part of this scheme, not a separate setting. We hand off to an administrator for questions about diagnosis and prescriptions, on repeated misunderstanding, clear negativity, and a direct request to connect with a human. Each handed-off thread shows which scenario branches should be improved.
Implementing a medical chatbot: stages of engineering work
An audit of requests is needed before the first line of the scenario: without it, the bot retells what is already on the website and does not remove the main load from reception.
We export the history of calls and chats for a period, label it by topic, and calculate the share of repeated questions — it sets the priority of branches and the scope of work. Then the sequence is as follows.
- Request audit: clustering of requests, frequency by topic, share of dialogs closed without a doctor. The output is a list of scenarios in descending demand and a list of topics the bot must not touch.
- Dialog branch scheme: each branch is described as a set of states with required data. We separately fix stop points — where the conversation must go to an operator and where a doctor closes it.
- Integration setup: connection to the institution's information system — schedule, booking, rescheduling and cancellation, service catalog, and preparation for tests. The bot is given a narrow set of permitted operations; each action is logged.
- Testing on real requests: a run on historical dialogs, then work in a closed loop where the bot's answers are compared with operator decisions. We calculate the share of correct routings and adjust branch boundaries.
- Staff training: operators receive the dialog queue, handoff rules, and a procedure for failures; administrators learn to change opening hours and answer texts without a developer.
- Solution handover and support: configurations, integration scheme, instructions, and access remain with the institution. Then comes a support period with incident response times and review of disputed dialogs.
What we hand over to the clinic: configurations, schemes, and regulations
The project is closed not with a demonstration of a working scenario but with a set of documents by which the clinic operates the bot without us.
We hand over documentation in the form in which we ourselves read it when returning to a project: a description of the dialog model, decision points, areas of employee responsibility, and the procedure for a disputed answer.
- Description of dialog structure: scenario tree with exit points to an operator, a list of mandatory clarifications, and rules for handling branches where the request goes beyond the knowledge base.
- Routing rules: by what signs a dialog goes to reception, to a specialist, or to an urgent line, with what priority and by what escalation scheme in the absence of a response.
- Instructions for operators: how to pick up a dialog, what is visible in the request history, which fields are required, and where the reason for handoff is recorded.
- Access documentation: employee roles, scope of visible data, procedure for granting and revoking rights, rules for storing depersonalized request logs.
- Knowledge base update procedure: section owner, frequency of material review, mandatory verification of edits by a specialist before publication.
- Procedure for reviewing disputed answers: how a dialog gets to review, who makes the decision, how the correction reaches the knowledge base and is checked on repeated requests.
The list is not decorative: it shows who in the clinic is responsible for each edit, which means the bot continues to answer correctly even after we have left the project.
Case study: how a clinic network removed load from reception
Starting point
The MedLine clinic network has fourteen branches and a single reception for all locations.
During morning peak hours — from 8 to 11 — the share of missed dialogs reached 18–20%: administrators physically could not handle messengers and the phone in parallel, and the first response in chat took 9–14 minutes.
Each missed dialog meant an unmade booking, and on busy days almost a quarter of requests closed without an appointment.
What was changed
The chatbot took on typical scenarios: appointment booking and rescheduling, clarification of the doctor's schedule and free slots, reminders, questions about preparation for tests, and delivery of results.
The dialog followed a branching scenario with input validation at each step, and on any non-standard reply control was passed to an operator along with the chat history — the human did not ask the same questions again.
Metrics before and after
The share of requests closed without an operator reached 68–72%. The first response during peak hours dropped to 4–6 seconds, missed dialogs to less than 1%, about half of all bookings go through the bot, and the flow is distributed evenly rather than in peaks.
What remained with humans
Disputed complaints, second opinions on complex diagnoses, insurance coordination, and handling conflict situations still go to a live administrator.
We deliberately do not automate these branches: there the cost of an error is higher than the benefit of speed, and the wording requires human tact. The chatbot's task is to remove routine work, not to replace the entire reception.
How a scenario dialog differs from a language model
The modes differ in who formulates the answer. The scenario selects a reply from approved options: the bot recognizes intent and guides along a branch — booking, reminder, preparation for a procedure. The model composes the answer itself based on the clinic's knowledge base and the dialog history.
Answer predictability is the main difference. The scenario gives the same reply to the same question: it is approved by a doctor before launch and is reproducible when reviewing a dialog.
The model answers more flexibly, but the wording changes from dialog to dialog — it cannot be approved once and for all.
| Criterion | Scenario dialog | Language model |
|---|---|---|
| Answer predictability | One question — one approved answer | Wording changes |
| Risk of an incorrect answer | Low: only approved replies | Rules and source-based verification are needed |
| Doctor control | Edits in the branch text | Prohibited topics, boundaries, escalation |
| Cost of ownership | New topics — manual work | Topics are covered without rewriting branches; higher load on quality control |
The risk of an incorrect answer is determined by who is responsible for the content. In the scenario, it is the doctor who approved the wording, so extraneous replies will not appear in the dialog.
For the model, a layer of restrictions is needed: the answer is built only on the approved knowledge base, diagnoses and prescriptions are prohibited, and going beyond the topic boundary hands the dialog to a doctor.
In practice, the choice of dialog mode is hybrid: booking, visit rescheduling, and reminders go to the scenario; questions about preparation and clinic rules go to the model — there are too many of them for manual branches.
Quality is measured by the share of requests closed without a human and by the number of escalations to a doctor.
Common technical doubts and answers to them
Before starting, clinics ask the same set of questions: who is responsible for the wording, how the bot connects with existing systems, what happens during a failure. We briefly answer each.
Who is responsible for answers to patients?
The bot handles the organizational part: booking, reminders, documents, opening hours. Clinical topics — diagnoses, prescriptions, symptom assessment — are outside its scope: the answer base is approved by a doctor.
How does a complex request reach a doctor?
The dialog is evaluated by signs set by the clinic: complaints about well-being, deterioration, questions about a medication. Such a request goes to an administrator or the on-duty specialist with the full context of the chat.
Will you connect to our medical system?
Booking, schedule, and patient records are synchronized with the existing medical information system — via the HL7 FHIR standard or through the vendor's software interface. If the system is closed, we install an intermediate layer.
How is patient data protected?
Processing takes place in the customer's environment or in an isolated cloud; rights are delimited by role. Accesses to the patient record are logged; dialogs for model improvement are taken in depersonalized form.
What happens during a failure of an external service?
The bot does not return an error but moves the dialog to a backup route: it accepts the contact, queues the request for an operator, and offers an alternative way to get in touch. After recovery, the history goes into the common feed.
Let's discuss the task: where setup begins
Setup begins not with code but with a description of how the clinic receives patients. As long as there is no list of requests and booking rules, the scenario remains a guess, and acceptance becomes a dispute about tastes. Here is what is needed from the clinic before the project starts.
- List of frequent questions: an export of the reception and call center log for several months, grouped by topic — booking, rescheduling, tests, preparation for a procedure. This shows the real distribution of requests.
- Appointment and booking rules: specialties and branches, booking horizon, actions on refusals, who receives a complex case. This is the basis for dialog branches and handoff to an administrator.
- Access to systems: a test environment of the medical information system, service catalog, doctor schedule, exchange with external services. Without a test environment, there is no way to check the bot on real data.
- Responsible person on the clinic side: one person with decision-making authority — they consolidate questions from doctors and administrators and confirm wording. Without them, approval sprawls.
- Procedure for approving scenarios: who checks the answer texts, whether medical proofreading is needed, and within what time edits are returned. We fix this in advance so that iterations follow one route.
- Depersonalized dialog examples: several dozen requests with administrator answers — we use them to configure tone, length, and the boundaries the bot does not cross.
We assemble the first version of scenarios immediately after receiving the materials, then proceed in iterations: we show dialogs, collect edits, and fix the next version. Timelines become predictable, and the result is checked in the test environment before launch.
