Should an AI receptionist handle emergency calls?
It should catch them and pass them on within seconds. Assessing one is the thing it must never do.
Answered in short
6 things that decide this
- 01An AI receptionist should detect an emergency and transfer it to a person immediately, and should never assess severity or advise the caller.
- 02Detection has to be over-sensitive on purpose, because a false transfer costs one interrupted person and a missed one costs something you cannot refund.
- 03The escape path is the real build: which number it rings, how long it waits, and what happens when nobody picks up at 3am.
- 04Any caller who asks for a human gets one, without the assistant trying to resolve the issue first.
- 05Gas, fire, flood, injury and anything mentioning smoke or a smell of gas belong on a keyword and intent list agreed with your operations team before launch.
- 06Every emergency call needs a recording, a transcript and a timestamped record of what the assistant did, because these are the calls that get reviewed.
Triage is a judgement your assistant cannot make
Vendors will show you an assistant that asks a few questions and works out how urgent a call is. It demos well. Do not ship it.
The problem is the shape of the cost. Nearly every wrong answer an assistant gives is recoverable: a rebooked appointment, an apology, a callback. An emergency it decided was routine is not in that category, and no accuracy figure makes it acceptable.
So we treat it as a design constraint rather than a model setting. The assistant is not permitted to judge urgency. It recognises the signals, says something short and calm, and transfers. The judgement stays with a person who can act on it.
What the assistant does with each kind of call
Agreed with your operations team before the build, and written into the system rather than into a prompt.
| What the caller says | What the assistant does | Why |
|---|---|---|
| I can smell gas | Short safety line, transfer immediately | Life safety. No questions, no booking flow |
| There's water coming through the ceiling | Transfer immediately | Damage compounds by the minute |
| Someone is hurt | Direct to emergency services, then transfer | Outside your business entirely |
| Just put me through to a person | Transfer, with no resolution attempt | A stated preference is not a problem to solve |
| My boiler is making a noise | Handle normally, book the job | Ordinary work, which is what the assistant is for |
| Anything the assistant is unsure about | Transfer | Uncertainty resolves toward the human, always |
A transfer nobody answers is not a transfer
Detection is the easy half. Teams spend their time on the keyword list and almost none on where the call actually goes.
Then it is Sunday night. The on-call phone is in a coat pocket. The assistant transferred correctly, the call rang out, and the caller heard nothing useful. The system did what it was told and the outcome is the same as having no system.
So the escape path gets built with fallbacks. A second number after a set number of rings. A text to the owner with the caller's number and what they said. A recording either way. And a record that says an emergency call arrived and was not answered, visible the next morning rather than discoverable after a complaint.
- 01Test the path by calling it out of hours before launch, not by reading the configuration.
- 02The caller should never have to repeat themselves to the person who picks up.
- Detect earlyOver-sensitive by design.
- Say one lineShort, calm, no questions.
- Transfer nowWith the transcript attached.
- No answer?Second number, then a text.
- Record itAudio, transcript, timestamps.
- Surface itFlagged for review next morning.
The fourth station separates a real system from a demo. Nearly every emergency-handling failure we have looked at was a fallback nobody tested rather than a detection the model got wrong.
Systems answering real customers
ZhoopZhoop
AI receptionist and parts procurement for a multi-branch auto repair business.
Read the case study →
Maidily
Integrated operations platform for residential cleaning businesses.
Read the case study →
WorkMateAI
Dispute resolution, payments, and compliance for Australia's on-demand trades.
Read the case study →
Related questions
01Will over-sensitive detection annoy our on-call staff?
Somewhat, and that is the trade we recommend making deliberately. A handful of unnecessary transfers a month is a known, bounded cost. Tuning detection down to reduce them moves risk onto the calls you cannot afford to get wrong, so we tune sensitivity with your team and review the transfers after a few weeks.
02Can the assistant at least take details before transferring?
Name, number and address, briefly, and only where the transfer is already in motion. What it must not do is work through a questionnaire while somebody stands next to a gas leak. The details are useful to the person picking up; collecting them is never a reason to delay the handoff.
03What about after-hours calls that are not emergencies?
Those are exactly what an AI receptionist is good at. Booking a slot, taking a message, answering a question about opening hours, all without waking anyone. Handling routine out-of-hours volume is usually the business case, and the emergency path is what makes it safe to run.
04Do we need to tell callers they are speaking to an AI?
Assume yes, and build the disclosure in. The EU AI Act's Article 50 requires people be told they are interacting with an AI system unless that is obvious, and it applied from 2 August 2026. Several US states have their own disclosure rules, and a short line at the start costs nothing while an argument about it later does.
Related
- TCPA rules for automated service texts →The messaging side of automated customer contact.
- Field service software →Where a missed call is a lost job.
- Field service case studies →Systems we run for trades businesses.
- AI chatbot development →How we build the refuse list and the handover.
- Human in the loop →Where the model is not allowed to decide.
