Designing an AI Receptionist With Emergency Escalation
DBB Software designed an out-of-hours receptionist to answer the calls a practice cannot, turn them into appointment requests staff can work through in the morning, and route anyone showing signs of an emergency to emergency services. It classifies urgency and stops there. It never assesses symptoms.
Industry
Healthcare & Biotech
Service
AI Development
Team
1 Product Owner, 1 AI Engineer, 1 Solution Architect
Project State
July 2026 - Ongoing
Country
United Kingdom
About the Client
A UK-based healthcare technology company operates a global platform that enables patients to review and rate healthcare providers while accessing reliable information to make informed care decisions. With a presence in markets like London, Germany, Austria, Australia, Dubai, and Ireland, the company aims to improve transparency and trust in healthcare through patient feedback and data-driven insights.
The Client's Initial Request
The client engaged DBB Software to establish what it would take to answer a practice's phone after it closes, and to stand behind a specific commercial promise on behalf of its clients: that a practice would never lose a patient to a missed call again.
Revenue Lost After Hours
Every unanswered ring outside opening hours hands a patient with intent to whoever picks up first. Voicemail was not catching them either: most people do not leave a message, and the ones who do leave partial information somebody transcribes by hand the next morning.
01
Emergency Handling on First Call
A caller describing chest pain to a system that responds by offering appointment slots is a catastrophic outcome, and emergencies do not check opening hours before happening. Anything taking that call needed a tested route to emergency services before it could take a single one.
02
A Defensible Safety Standard
A US competitor has run an AI voice assistant on practice phone lines since 2025. Its published figures report around 70% of scheduling calls resolved, an average under three and a half minutes, and pricing per booked appointment. The open question for the client was whether the same thing could be done to a standard a healthcare platform is willing to defend.
03
Solutions We Delivered
DBB Software delivered the design for an out-of-hours receptionist built on one rule: the system is allowed to be unhelpful, and never allowed to be unsafe or to invent an answer. The first release is designed to buy the conversational voice layer from a white-label vendor and put the engineering into the parts that carry risk: when calls switch over, how urgency is detected and escalated, what happens to a captured request, and what the system does when any part of it fails.
Emergency Escalation as Release Gate
When the system detects urgency signals it routes the caller to emergency services. That escalation path has to pass a clinician-signed test set before it can take a live call.
The urgency check is specified as a fixed rule that runs ahead of the conversational model, so the urgency decision never depends on the model raising it.
The system classifies urgency and nothing more: no triage, no symptom assessment, no medical guidance. Where confidence is low it asks a question, because one of the categories being told apart is whether the caller needs an ambulance.
DBB recommended one emergency ruleset shared with the client's on-site chatbot: authored and signed by a named clinician, version-controlled with its test set, and clearing that set before any release. One ruleset leaves one clinician to appoint as sign-off owner instead of two, and that appointment gates any rollout past internal testing.
Vendor Voice Layer and Switchover
The conversational layer for the first release is a third-party white-label engine. DBB's engineering goes into the platform integration.
The first release tests whether patients will talk to an automated receptionist, before the deeper build is committed.
Natural turn-taking is a vendor acceptance requirement.
Calls route to the assistant outside opening hours, on a default evening-to-morning window with per-practice hours on top. A practice sets its own hours, and a change takes effect without a manual delay.
Calls Captured as Appointment Requests
The system first establishes what the caller needs: a booking request, a general query, or something urgent. A completed booking call produces an appointment request, with the details captured, in the dashboard the practice already uses.
If the caller hangs up before giving a callback number, the request is still created with whatever was captured and flagged as incomplete.
Two similar calls stay two separate requests.
If the system cannot understand a caller after reasonable attempts, it offers to take a message and gives clear next steps.
Guaranteed Route to a Person
There is always a route to a human or to voicemail.
If the routing service is unavailable at switchover, or the voice vendor has an outage during the coverage window, calls fall back to a safe default instead of dropping silently.
An availability target is a contract requirement on the voice vendor, agreed before any practice is switched over.
Voice Data at Healthcare Standard
Callers are told they are speaking with an AI, and everything captured by voice is treated as patient personal data.
Recording and consent follow UK telephony and data protection law.
Captured voice data is encrypted in transit and at rest with access controls, on the same footing as any other patient information the platform holds.
A retention and deletion policy covers call transcripts, and no supplier in the chain receives data until its data-processing agreement is signed.
The Designed Second Release
The first release takes a message. It does not say which clinicians work at a practice, what they treat, or when anyone is free. The designed second release opens platform data access, and then real availability, so the receptionist can suggest a suitable clinician and work against open slots. It is designed and not yet scoped in detail.
Access is designed to come through the same shared data layer DBB designed for the client's AI connector, so the receptionist reads platform data the way the chatbot and the search do.
If the data connection is down, it takes a message instead of inventing an answer about a clinician or a slot.
Where nothing suitable is free soon, it gives realistic timing and still logs the request.
Success Metrics and Named Risks
Three measures were named: the reduction in missed after-hours calls per practice before and after, the number of appointment requests captured through the assistant against the prior voicemail capture rate, and the call completion rate, meaning calls where a usable request is captured against calls that stall.
The availability requirement is stated as 99.9% or better, because the product replaces a practice's out-of-hours line.
Three risks were registered with likelihood and impact:
Failing to recognize a genuine medical emergency, rated low likelihood and high impact, answered by the tested escalation path as a release gate
A vendor outage during the coverage window, rated medium and high, answered by the voicemail fallback at switchover
Patients declining to speak with an automated receptionist, rated medium and medium, tracked through the call completion rate
Call completion is the number that validates or kills the product, because some patients will not discuss their health with a machine.
Results Achieved
0 dead ends
No state exists in the design where a caller cannot reach somebody. Every failure resolves to a person or voicemail.
1 clinical sign-off gate
Emergency escalation cannot take a live call until a named clinician signs its test set.
3 defined call outcomes
An appointment request in the dashboard staff already use, a routed emergency, or a handoff to a person.
4 failure points with a specified fallback
Routing at switchover, the voice vendor, an unclear conversation and a partial capture each have a defined ending.
Put AI on a Line Where Mistakes Matter
DBB Software designs AI for regulated settings, where the safe path is specified before the useful one and there is always a route back to a person.
Contact Us
"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.
If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”
Mina Morkos
Business Development Manager
Want a similar outcome for your team?
Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.
