AI voice agent answering calls at a clinic reception desk

Polish healthcare platform ZnanyLekarz reports that 44% of first call attempts to a medical practice fail, and that 60% of patients never call that practice a second time. A caveat you will not find on any vendor's landing page: ZnanyLekarz publishes neither the methodology nor the sample size. Treat it as a direction, not a measurement.

The direction matches what I hear on every call with a clinic owner. Run it against your own prices: if one new patient in aesthetic medicine or dentistry is worth a few hundred, and reception misses a dozen calls a day, the annual hole is six figures. It never shows up in a report, because a lost patient never enters the system in the first place.

The good news: that hole can be closed today. The technology is ready, conversation works, and deployment takes weeks rather than quarters. The bad news: not every deployment closes it. This piece is about what separates an agent that genuinely answers your phones from one that dazzles in a demo and stalls on contact with reality.

Three things decide it. None of them is how natural the voice sounds.

What it looks like when it works

Before the traps, the point of doing this at all.

It is 8:40pm. Reception went home at six. A patient calls who has just found your clinic in search results. The phone is answered on the first ring. The agent asks what treatment they need, checks availability, offers three slots, confirms the chosen one and writes the appointment into your calendar. The patient gets a confirmation text. Total call time: two minutes.

In the morning, reception does not find thirty missed calls. They find a list of appointments that booked themselves, plus a short summary of the cases the agent passed on because they needed a human.

That is not a vision. It is the standard scope of a first deployment. There is one condition: the three things below have to be settled properly — and those are exactly what decide whether you get the scenario above or an expensive toy.

Thing 1: what happens when the agent is not enough

The question that comes up in every meeting: "what if it can't handle it?" The right answer is not "it will." The right answer is: the call returns to a human without the caller noticing — and it returns even when the agent does not answer at all.

That is work in the phone system, not in the AI. Set up properly, it looks like this:

Patient calls → main number → menu
   → option "reception"
   → voice agent
        ├── resolved → appointment in the calendar → done
        └── needs a human → PBX takes over → reception

The key property: a good PBX does not lose control of the call when it hands it to the agent. It is a bridge, not a blind forward — the patient stays inside your system the whole time, and if the agent is silent or busy, a "busy / no answer" rule routes the call straight to reception. No call is lost. That is a built-in safety net, not a promise.

There is one subtlety that trips up rushed deployments: if the return action fires after every conversation, reception answers exactly as many calls as before, including the ones the agent already resolved. The fix is boring and configurational: a resolved call ends with the patient, escalation takes a separate path. You set it up and test it on a live number in week one.

The question to put to any vendor: show me what happens when the agent is busy. Anyone without a ready answer has not run this in production.

Thing 2: calendar access — this is where the project is won or lost

This is the most important section here.

An agent that only answers and takes a message is worth a fraction of one that writes the appointment straight into your calendar. One thing makes the difference: whether your software lets us in.

I will use my own example, because it cost me the most. We built a working voice reception demo for a clinic — conversation in the local language, appointment booking, calendar integration. The voice side worked immediately. The project stalled because the vendor of the medical software that clinic runs on has not, for months, responded to the client's requests for calendar access. A second, unrelated project at the same client is frozen for the same reason.

The conclusion is not "don't buy an agent." It is: check this first, before anyone starts talking about price. In most cases there is a route through, and it is usually shorter than it looks:

Your booking system	What it means
Cloud calendar with an API (Google Calendar, Calendly, web-based systems)	Green light. Integration is a matter of days
On-premise system, database reachable	Standard path. Needs access plus a data processing agreement — both doable inside a week
Vendor not responding	We start with the no-write version (answering, qualifying, handing over) and push for access in parallel. The agent earns from week one; integration lands later
I don't know	The most common answer. It is one question to your software vendor — I can help you word it

Note the third row. Even a locked calendar does not close the subject — it only changes the order. Answering after hours and qualifying patients work without any integration, and already stop the leak.

Not sure which row you are in? That is a fifteen-minute question — book a 30-min call and we will work it out before anyone sends you a proposal.

Thing 3: where the limits of the promise are

Every vendor will assure you their agent never makes things up. I will say it plainly, even though it does not help me sell: no solution built on a language model can guarantee it will never say something outside the knowledge base. Anyone guaranteeing that either does not understand the technology or is counting on you not understanding it.

The good news is that the risk comes down to a level where it stops mattering in practice — but you get there with architecture, not with a sentence in a proposal:

1. Retrieval before response. The agent only sees fragments of your own materials matched to the patient's question. It "knows" nothing else.
2. A hard refusal instruction. No confident answer means handover to a human, never a guess.
3. "Always a human" rules. Complaints, contractual matters, an explicit request, two failed attempts to understand. We set them together; they are configuration, not magic.
4. Deliberately breaking the agent during the pilot. We attack it with the questions your patients actually ask — better to find the hole yourself than hear about it from a patient.

The result: an agent whose worst case is saying "let me pass you to reception" — exactly what a good employee does when a question is beyond them.

What it costs, and what to compare it against

Separate two numbers vendors like to blend.

Consumption cost scales with every minute of conversation — you pay for how many calls the agent actually handles. Implementation cost is one-off and depends on how many integrations are needed and how open your system is.

Demand both lines broken out in every proposal. A vendor quoting one lump sum "for the agent" has either not calculated consumption or buried a margin inside it that grows with your call volume. Second question: whose name is on the invoices for third-party services? In an honest arrangement they go directly to you — otherwise you are paying commission on your own volume.

The right comparison is not "what does it cost" but "what does not doing it cost". On one side, the implementation. On the other: a reception hire you do not have to make, and the patients who are calling your competitor today. If recovering a handful of patients a month covers the whole thing, the rest of the discussion is about timing, not price.

What your patient will actually hear

If you operate in an inflected language, this used to be the real barrier — and it is why everyone remembers hotlines where "sorry, I didn't catch that" came back on a loop.

That barrier has fallen. Neural networks pushed speech recognition down to a few percent error, roughly human parity. Inflection — one surname appearing in half a dozen written forms depending on grammatical case, six unrelated strings to a machine — has stopped being the problem.

One area is still worth asking about if you run a medical practice. A study from ICM at the University of Warsaw on recognising drug names in Polish puts it bluntly:

Contemporary automatic speech recognition (speech-to-text) models have difficulty accurately transcribing the names of Polish pharmaceutical products.

The same study shows the fix: after fine-tuning on synthetic data, the system recognised over 7,500 commercial drug names, scoring an F1 of 87.4% on phonetically varied ones. In other words: specialist vocabulary can be tuned — provided someone actually does it.

Hence a concrete test when choosing a vendor: do not evaluate the agent on "I'd like to book an appointment." Give it your practitioners' surnames, your treatment names, your drug names. A vendor who agrees to that without flinching knows what they are doing.

Data protection: standard, not an obstacle

Patient conversations are sensitive data, so the order is non-negotiable. This is not a list of obstacles — it is what a properly run deployment looks like:

• A data processing agreement signed before the vendor gets any access.
• Transparency about where recordings and transcripts land — which provider, which jurisdiction, for how long.
• Least-privilege access — permissions to the calendar, not to the patient record.
• A deliberate choice between cloud and your own infrastructure — with medical data, sometimes only the latter survives an audit. I covered that in local AI without the cloud.

It is also worth knowing where such a system sits under the EU AI Act and what it means for your company. A vendor who waves that away is a risk in itself.

How to start so it actually pays

The order that works is the reverse of most proposals.

1. Measure how many calls you are losing. One month of PBX logs: how many calls, how many unanswered, at what hours. That single number frames the whole decision — and it is usually higher than anyone internally expects.
2. Check calendar access. One question to your software vendor. The answer defines the scope of stage one.
3. Pick one scenario. After-hours pickup, or booking, or confirmations. One — ideally the one losing you the most.
4. Pilot on a real number, on limited traffic. Your number, your patients, with a kill switch. Not a demo.
5. Expand on pilot data. Two weeks of transcripts will tell you more about your patients than any pre-deployment analysis.

This order is not cautious for its own sake. The MIT report The GenAI Divide: State of AI in Business 2025 — 52 executive interviews, surveys of 153 leaders, 300 deployments analysed — found that 95% of generative AI pilots produced no measurable P&L impact. The cause is organisational, not technological: companies fail to fit the tool into an existing process. (MIT has taken the report off open access, so I link Fortune's coverage — better to point you at something you can open.)

Put differently: the project does not fall over on the model. It falls over on integration and process — things 1 and 2 above. Which is why we start there, not with choosing a voice.

One honest limit: at very low call volume — say under two hundred a month — good online booking usually solves it more cheaply. I will tell you that on the call if that is what your numbers show.

The short version

Conversation is solved and is no longer the risk. Three things decide the outcome: whether calls return to a human without any going missing, whether the agent can reach your calendar, and whether someone drew an honest line around what the model can promise.

A vendor who raises those three in the first meeting has done this in production. A vendor who only talks about how natural the voice sounds is selling a demo.

The expensive option is not a bad deployment. It is another year in which 44% of patients cannot reach you on the first try.

Book a 30-min call — we will go through your numbers, check access to your calendar, and decide which scenario to start with. You will leave that call with a concrete answer, including if it is "not yet."

More on how we approach deployments like this: AI agents for business and process automation. Concrete examples from other sectors are in AI automation across 12 industries.