Two seconds of silence is long enough for a caller to decide the line has died. Ofcom, the UK communications regulator, has a name for that experience: its persistent misuse policy defines a silent call as one where the person answering hears nothing and has no means of establishing whether anyone is at the other end. An AI receptionist on a failing mobile signal produces those same seconds by accident. Handling it well is three moves inside roughly ten seconds: detect the dead air, ask once for a repeat, then bridge the caller to a text message or a human callback. A badly built agent does none of that. It waits, and the caller hangs up.
What happens when an AI phone agent hits a bad signal or a dropped line?
Four things happen in sequence, and only the first two are automatic. The agent stops receiving usable audio. Its transcription confidence collapses or returns nothing at all. At that point the build either has a rule for what to do next, or it does not, and everything the caller experiences after that is a design decision somebody made months earlier.
The behaviour worth paying for looks like this. After a short, fixed window of silence, the agent speaks: a single, plain re-prompt that names the problem rather than repeating the question word for word. If the second attempt also fails, the agent stops talking and changes channel, sending a booking link by SMS or WhatsApp to the number that called, or writing a callback task with the partial transcript attached. If the audio stream disappears entirely, that is a drop, not silence, and it should trigger the same record with a different label.
Take a dental practice as the running example through this article. It is an illustration rather than client data, and the numbers inside it are yours rather than ours: how many inbound calls the main line takes in a week, which hours the agent covers, and who clears the callback queue between patients. Fill those in as you read, and the rest of this becomes a test you can run against your own build.
How do I know the AI has not heard me, versus the line actually dropping?
As the caller, you cannot tell, and that is the entire design problem. Both failures sound identical from the handset: nothing. Ofcom treats that dead air as the harm in itself, regardless of what caused it, which is the right way for an operator to think about it too.
The system, unlike the caller, can tell the difference, and a good build acts on it. If media packets stop arriving, the call has dropped or the mobile has lost the cell, and there is nothing to talk to. If packets keep arriving but carry no speech energy, the caller is there and quiet, or in a place too loud to be understood. If packets arrive and the transcriber returns low-confidence fragments, the audio is degrading rather than absent, which is the case most builds handle worst.
Those three states deserve three different responses. Absent audio should end the call cleanly and write a record. Silence should get one re-prompt, then a channel switch. Degrading audio should trigger the shortest possible question, because a yes or no survives a bad line far better than a date, a name or an email address does.
How often does this happen on live calls?
No regulator or platform publishes a dead-air rate for inbound AI answering, so anyone quoting you one is guessing. What is published is latency, and latency is the cause. An AI agent that takes too long to respond produces silence that is indistinguishable, to the caller, from a broken line.
The working threshold in the industry is that voice AI needs to respond in under 800 milliseconds to feel like a conversation. That threshold, and the platform figures below it, come from one industry comparison of voice platforms rather than from independent research, and they should be read as vendor-side evidence: no neutral research house publishes a comparable set. On the numbers that comparison gives, one platform averages 950ms globally, a second reaches roughly 600ms but only in optimal configurations that assume network conditions rarely found when routing across continents, and users of a third report latency above 1,450ms on India to United States routing, close to two full seconds of silence after each thing the caller says. Real deployments on that path consistently exceed one second of total response time.
Here is where that second goes, using the stage by stage breakdown from the same comparison. Redo it with your own call path.
| Stage of the round trip | Delay added |
|---|---|
| Network round trip, India to United States, before any processing | 265ms to 309ms |
| Transcribing what the caller said | 100ms to 200ms |
| Language model deciding the reply | 200ms to 400ms |
| Text to speech | 100ms to 200ms |
| Total, before any network jitter | 665ms to 1,109ms |
| Threshold where the call still feels natural | under 800ms |
Read the bottom two rows together. On a good path you clear the bar with room to spare. On a long path you are over it before the caller has finished being impressed, and every wobble in the mobile signal is added on top. For the practice in our example, this is the argument for keeping the media path regional rather than accepting whatever region a vendor defaults to.
What does an AI receptionist bad phone line failure sound like on the recording?
It sounds like a person talking to something that is not there. The documented version, from a developer describing latency around 1,450ms in that same platform comparison, is audio turning garbled and connections timing out rather than recovering, and the recording carries all of it.
Play back twenty calls and listen for five specific things. The caller repeating themselves unprompted, which means the pause was long enough for them to assume they were not heard. The agent answering the question before last, which means the transcript arrived late and was matched to the wrong turn. The agent talking over the caller, which is barge-in tuned too aggressively to compensate for lag. A re-prompt that repeats the original question verbatim, which tells the caller nothing about what went wrong. And the loop, where the agent asks the same thing a third and fourth time until the caller gives up, which is the failure that costs you the booking and the goodwill together.
Degraded audio has causes other than a weak signal. A caller with a speech difficulty, a heavy accent on a compressed codec, a child in the background, all produce the same result at the transcriber: input in, nothing useful out. Treat them as one failure class. A system that cannot get a person to a human when it stops understanding them is not finished, whatever the cause of the audio problem.
How do I test for this before going live?
Degrade the line deliberately and listen, which takes an afternoon and costs nothing. Run each of these against your own agent and write down what it did.
- Call from a lift, a basement car park and a moving car, and time the gap between your last word and the agent's first.
- Answer, then say absolutely nothing, and time how long the silence runs before the agent speaks or ends the call.
- Say three words, then go silent mid-sentence, which is the commonest real pattern on a failing mobile.
- Call with a hands-free kit in traffic, so the agent gets speech plus constant road noise rather than clean silence.
- Hang up mid-answer and check what the system wrote: a labelled dropped call with a partial transcript, or nothing at all.
- Give a name and a mobile number through a bad connection and confirm which digits survive.
- Count how many times the agent will ask the same question before it changes tactic. If the answer is more than twice, that is the bug.
Then check the other half: whether the fallback actually fires. A text should arrive at the number that called, a task should exist in the CRM, and someone should own it. The rules for when the machine steps aside are worth writing down explicitly, which is what human handoff triggers are for.
What rules and fines am I exposed to if I get this wrong?
The enforceable numbers all come from outbound dialling rules, not from inbound answering, and that gap matters. No regulator has published a rule written for an AI agent answering a call it did not place, so that question is unsettled. In the UK, the regime with teeth is Ofcom's persistent misuse policy, and its abandoned call rules are specific: a recorded message must play no later than two seconds after the telephone is picked up or two seconds after an individual begins to speak, unanswered calls must ring for a minimum of 15 seconds, and abandoned calls are limited to no more than three per cent of live calls on each campaign over a 24 hour period. Non-compliance carries financial penalties, which Ofcom imposed on four companies at the end of the first phase of enforcement in January 2007.
Apply that three per cent cap to your own line as a self-imposed standard rather than a legal one, since it was written for outbound campaigns. Count the calls in a week where the caller got dead air, divide by the calls the line took, and hold the result under three in every hundred. That is a figure you can produce from your call logs every Monday without buying anything.
Outside the UK, the exposure shifts from platform behaviour to consent and to data. United States rules on artificial and prerecorded voice calls were written for outbound campaigns, which is exactly where an automated callback after a failed call puts you, rather than for a caller who dialled your number. In the UAE, voice services and numbering are licensed, so obligations reach you through your telecoms provider and your number routing. Healthcare adds recording and health-data duties in both markets, and they bite on the recording you just made of a patient describing a symptom on a bad line. None of those regimes has published guidance aimed at inbound AI answering, so the specifics turn on your jurisdiction and your call flow, and they are worth putting to your own counsel before you automate anything outbound.
Which dropped-call recovery moves are safe, and which are not?
The rules constrain what you may do after a call fails, not whether you may recover it. Start with the moves that are both safe and effective.
- ✅ Send a service message to the number that just called you, with a booking link and one line naming the problem, because it responds to contact the customer initiated.
- ✅ Set your silence threshold in seconds, using Ofcom's two second message rule as the model for how quickly a system should react to dead air.
- ✅ Hold your own dead-air rate below the three per cent abandonment cap and review it weekly from recordings, not from vendor dashboards.
- ✅ Keep media routing regional, since cross-continent round trips alone add 265ms to 309ms before anything is processed.
- ✅ Write a callback task with the partial transcript attached, so the human who rings back opens with what was already said instead of starting again.
- ✅ Cap re-prompts at two, then change channel, which is the single change that removes the loop from your recordings.
Then the moves that look reasonable and are not.
- ❌ Auto-redialling a number after a dropped or silent call without guaranteeing a person will be on the line. Ofcom's 72 hour rule requires that wait before a number receiving an abandoned call may be called again without the guaranteed presence of an agent, and the regime is backed by financial penalties.
- ❌ Leaving the agent in silence while it thinks, which is the exact condition Ofcom defines as a silent call: the person hears nothing and cannot establish whether anyone is there.
- ❌ Letting the agent keep trying on a clearly failing line, because every extra turn on garbled audio increases the chance the booking detail it captures is wrong.
- ❌ Treating an automated outbound callback as if it carried the same permissions as the inbound call. Outbound artificial-voice calling in the United States sits under a consent regime written for campaigns, and that is a legal exposure, not a platform setting.
And the borderline moves real operators use, with the risk named honestly.
- ⚠️ Running the agent on the cheaper platform despite a global average near 950ms. It gains margin and loses naturalness, and the risk is commercial rather than regulatory: callers hang up in the silence and you never learn why. Suits low-stakes lines, not first-contact sales lines.
- ⚠️ Recording every call to find these failures. It gains you the only real evidence of what went wrong, and it carries legal risk around notification and consent, sharper again where the caller is a patient and health-data rules apply. Suits operators willing to run a clear disclosure line and a retention policy.
- ⚠️ Moving the fallback to WhatsApp rather than SMS. It gains a threaded, richer conversation the customer can answer later, and it carries platform-policy risk on the Meta side rather than legal risk, since template and quality rules apply to what you send. Worth understanding what triggers reviews before you route recovery traffic there, and worth testing the wording, since template tests change reply rates more than most operators expect.
- ⚠️ Letting the AI keep a clinical or symptom-related call that it is struggling to hear, rather than handing off immediately. It gains coverage outside staffed hours and carries both clinical and regulatory risk. Voice deployment in healthcare is running ahead of any formal assessment of it, which makes this the setting most worth being conservative about.
Questions owners still ask before the AI answers the main line
If the caller drops mid-booking, should the AI ring them straight back?
Not automatically, and not without a person on the line. In the UK, Ofcom's regime sets a 72 hour wait before a number that received an abandoned call may be rung again without a guaranteed agent present, and an automated callback into dead air is the pattern that rule was written about. Text them instead, then let a human ring if the text goes unanswered.
Should the fallback be SMS or WhatsApp?
SMS if you want certainty of delivery to a number you have never messaged before, WhatsApp if the customer is already a contact and you want the reply in a thread your team can pick up later. Most practices end up using both: SMS for the first recovery, WhatsApp for the conversation that follows.
How long should the agent wait before it speaks into silence?
Seconds, not tens of seconds. There is no published standard for inbound AI answering, so the nearest defensible anchors are the two second window Ofcom sets for a recorded message and the 15 second minimum ring time, both of which describe a regulator that thinks in seconds. Anything that leaves a caller in silence long enough to check their screen is too long.
Can I trust a vendor's quoted latency figure?
Only with your own call path attached to it. Published figures are measured in optimal configurations, and the gap between roughly 600ms in ideal conditions and over a second in real deployments is the whole story. Ask which region the media terminates in, then test from a car park.
The question to ask yourself this week is not whether your AI agent handles a perfect call, because it does. It is this: when was the last time you listened to a recording of a call that went wrong? If the answer is never, that is the afternoon's work, and everything above tells you what to listen for.
If you would like another read on what your recordings are telling you, send us three calls that went badly and we will tell you which of these failure modes you are looking at.
