A voicebot that answers routine appointment calls

Who the client was and what was getting in the way

A medical clinic where reception staff answer calls all day, and most conversations are almost identical. A patient wants to confirm or cancel an appointment, ask about the next available slot, or check when a particular doctor is in. Each call takes a minute, sometimes two. The problem is that there are so many of them that the line can be busy just when someone with an issue that really needs a person at the desk is calling.

Three things also had to be handled properly from the start. First, the data. The clinic already has a medical system with its appointment schedule, and that is the single source of truth. Keeping a second schedule just for the bot to search would be harmful — it would be out of sync within the first week. Second, security. Information about a patient’s appointment is sensitive and must not be disclosed automatically to anyone who calls the number. Third, the conversation itself. Patients do not forgive unnatural pauses and a robotic voice when calling reception. If the conversation does not flow, they hang up and call again.

What we built

We started by mapping the conversations, not by choosing technology. We reviewed what actually happens on the phone and selected the routine scenarios that can be completed without a person: confirming an appointment, cancelling it, asking for the next available slot, and checking doctors’ office hours. Anything outside that list was deliberately left to reception.

The voice layer runs on ElevenLabs Conversational AI, and calls come in over a SIP connection. The bot answers on the clinic’s existing number and takes calls that reception does not pick up, with the caller’s number available. We set it up without changing the phone-number routing, so from a patient’s perspective it is still the same reception number.

The medical system integration uses pre-call and post-call webhooks. Before a conversation, the bot retrieves context for the number the patient is calling from. Afterward, it sends back what was agreed, and the record returns to the clinic’s system. The medical system remains the source of truth throughout; the bot stores nothing separately. We placed patient verification before any specific details are shared: until the bot is sure who it is speaking with, it will not provide an appointment time or a doctor’s name.

How it works today

Patients call the number they already know. If reception answers, they speak to a person and nothing changes. If no one picks up, the bot takes the call, speaks Polish, and asks what they need. It completes appointment confirmations and cancellations itself, and the change is recorded in the system. For questions about the next available slot, it first verifies who is calling and only then gives a date. It answers questions about doctors’ office hours right away because that information does not need protection.

After each call, the system creates a summary, so in the morning reception can see what happened overnight and after hours without listening to the recordings. We are rolling this out in stages: first a narrow set of scenarios and a review of recordings, then additional scenarios. This approach lets us remove a single scenario in fifteen minutes if patients turn out to phrase their requests differently than we expected.

The outcome

The helpline answers 24/7, so a call at ten p.m. to cancel tomorrow’s appointment does not go unanswered. The bot handles more than four types of requests, all of which previously took up reception staff’s time. The number of additional schedules to maintain is zero because appointment information stays where it was. Conversations are in Polish and use a natural-sounding voice; that was a requirement for launch, not an extra.

What we would do differently

The hardest part was not the voice but patient verification. Deciding how much information the bot must confirm before giving an appointment time — enough to keep things safe but still manageable for an older person on the phone — took longer than the rest of the implementation combined. Next time, we will start there and build the conversation scenarios around an agreed verification rule.

The second lesson is that starting with a narrow scope was the right call; for the next clinic, we will make it narrower still. Every scenario added too early creates more correction work than the relief it gives the phone line.