The Cost of Bad Call Quality: What Latency Does to a Conversation

When your phone system goes down, everyone knows within minutes. We covered what that costs, and how to put a defensible dollar figure on it, in The True Cost of a Phone Outage. But an outage is the easy case. It's loud, it's binary, and it ends.

Degraded call quality is the opposite: a slow bleed that never trips an alert, never generates a ticket, and never ends on its own. The calls connect. The audio is clear. And yet every conversation is slightly worse than it should be: people interrupting each other, apologizing, repeating themselves, wrapping up early. Nobody reports it, because there's nothing obviously broken to report. It just quietly costs you, call after call, month after month.

This post is about what latency actually does to a conversation, where the delay hides so that your ping tests never see it, and what the slow bleed adds up to in business terms.

A phone conversation is a precisely timed activity

Conversation looks casual, but the timing underneath it is remarkably tight. A large cross-linguistic study published in PNAS in 2009 (Stivers and colleagues, covering ten languages from Danish to Yélî Dnye) found that the gap between one person finishing a turn and the other person starting is typically around 200 milliseconds, with the most common response offset sitting near zero. That's faster than most people can consciously react, which means listeners aren't waiting for you to finish and then deciding to speak. They're predicting your endpoint while you're still talking and launching their response to land right on it.

That prediction machinery is calibrated for face-to-face timing: essentially zero transmission delay. Phone networks add delay, and here's the part that matters: the timing channel breaks long before the audio channel does. A call with 300 milliseconds of one-way delay sounds perfect. Every word is intelligible. But every turn transition is now off by more than the entire natural gap, in each direction.

The ITU's guidance reflects this. ITU-T Recommendation G.114, the standard for one-way transmission time, says that if mouth-to-ear delay stays below about 150 milliseconds, most applications experience "essentially transparent interactivity." From 150 to 400 milliseconds, calls are still considered acceptable for planning purposes, but with increasing degradation the higher you go, and highly interactive conversations suffer first. Above 400 milliseconds, G.114 treats the delay as unacceptable for general network planning; testing behind the recommendation found that even with echo fully controlled, a meaningful share of speakers had difficulty at that level.

Notice what those numbers describe: not audio fidelity, but interactivity. The standard is effectively measuring how badly the delay breaks turn-taking.

The talk-over spiral

Here's the mechanism, step by step, on a call with meaningful delay in both directions.

You finish your sentence. The other person hears your last word a few hundred milliseconds later, starts responding on their normal ~200 ms reflex, and their first word takes another few hundred milliseconds to reach you. From your side, the silence after your sentence has now stretched to two or three times what your brain expects. Silence that long means one thing in a normal conversation: it's still your turn, or they didn't hear you. So you start talking again, right as their delayed response finally arrives.

Now you're both speaking. Both of you hear the collision (late), both stop, both say some version of "sorry, go ahead." Then you each wait an extra-long beat to make sure the other is really done (which reads as another awkward silence), and someone jumps in again. After two or three collisions, both parties give up on natural turn-taking entirely and fall back to deliberate half-duplex: long pauses, explicit hand-offs, the conversational equivalent of radio operators saying "over." It works, but it's slow, tiring, and cold.

Echo makes the spiral worse. Echo cancellers have the hardest job during double-talk, the moments when both parties speak at once, which is exactly what excess delay produces more of. So the calls with the worst talk-over also tend to develop clipped syllables or echo artifacts at precisely the collision moments, compounding the confusion. (See Echo on VoIP Calls for why delay and echo are so tightly linked: the same echo becomes dramatically more annoying as delay grows.)

If you want the troubleshooting playbook for this symptom (finding which component adds the delay and fixing it), that's covered in Audio Delay and Talking Over Each Other. This post is about the other half: recognizing that the symptom exists at all, and what it's costing you while it goes undiagnosed.

Where the delay hides

The reason this problem survives undetected in otherwise well-run networks is that the number everyone checks (network round-trip time) is only one line item in the real budget. What matters to the conversation is mouth-to-ear delay: every millisecond between a sound leaving your mouth and arriving at the other person's ear. That's a sum, and most of the terms don't show up in a ping.

Think of it as a delay budget, itemized per hop:

• Codec and packetization. The sending side has to collect a packet's worth of audio (usually 20 ms) before it can send anything, plus encoding time and any lookahead the codec needs. Call it a few tens of milliseconds before the first bit touches the network. Details in Latency, Jitter, and Packet Loss.
• Network transit. The part your ping test actually measures: one-way, roughly half your RTT to the far end.
• The jitter buffer. The big hidden one. The receiving side deliberately holds packets in a buffer so that variation in arrival times (jitter) doesn't cause gaps in playback. That smoothness is purchased with delay, one-for-one. A well-tuned adaptive buffer might hold a few tens of milliseconds. But a fixed buffer set defensively large, or an adaptive buffer that grew during a jitter spike and was slow to shrink back, can be holding 100 milliseconds or more of your budget, on each end of the call. None of it appears in any ping test, because it's not network delay at all. It's your own equipment, waiting on purpose.
• Headsets and handsets. A Bluetooth headset adds its own radio link and codec processing: commonly several tens of milliseconds for call audio, and well over 100 ms for some codec configurations. DECT cordless handsets add their own smaller processing delay. If both parties wear Bluetooth headsets, you've added a meaningful chunk of budget that no network tool can see.
• Transcoding and middleboxes. Each codec conversion at a PBX or SBC adds more.

Add it up honestly and the arithmetic gets uncomfortable fast. A 60 ms one-way network path (perfectly respectable) plus packetization, a conservatively-sized jitter buffer on each end, and a Bluetooth headset on each end can land you past 250 ms mouth-to-ear. Everyone involved checks the ping, sees 120 ms RTT, and declares the network fine. The network is fine. The conversation isn't.

This is why voice is such an unforgiving workload: it's the only common application where a quarter-second of buffering, invisible and harmless anywhere else, directly degrades the product. We dig into that theme in Why Voice Is Hard.

Why nobody reports it

Choppy audio generates tickets. Words drop out, the caller says "you're breaking up," and someone emails IT with a specific, describable complaint. Latency generates nothing, because there's no moment of failure to describe. Nobody files a ticket that says "the conversation felt awkward." They just interrupt each other, apologize, unconsciously shorten the call, form a slightly worse impression of the person and the company on the other end, and call less.

The problem is equally invisible on the monitoring side, for a subtler reason. The MOS number on your dashboard is almost always a listening quality score, what ITU-T P.800.1 calls MOS-LQ. It answers: how clear does the received audio sound? Delay doesn't muffle audio, so a high-latency call can score a pristine listening MOS. Conversational quality (MOS-CQ, which the ITU E-model captures with an explicit delay impairment term) is a different measurement, and it's the one that collapses when turn-taking breaks. If your tooling only reports listening quality, a call can be conversationally miserable while every metric you collect says it's excellent. (Our guide to understanding MOS scores covers the distinction, and you can watch delay drag the conversational score down interactively in the MOS explorer.)

So the failure mode is complete: users don't report it, dashboards don't show it, and uptime is 100%. The only way it surfaces is if someone goes looking.

What the slow bleed costs

The business cost of latency is a customer-experience cost, and it shows up in places nobody attributes to the phone system:

• Longer handle times. Every talk-over collision costs a repair loop: stop, apologize, re-establish who's speaking, repeat the lost sentence. On a support call with a dozen turn transitions per minute, those loops add up to real minutes.
• Lower first-call resolution. Half-duplex conversations transmit less information per minute, and callers cut awkward calls short. Details get missed; callbacks follow.
• Damaged rapport on sales calls. Selling runs on conversational rhythm: matching pace, reading hesitation, well-timed silence. Talk-over torpedoes all of it. A prospect who spends the call fighting for the floor doesn't remember your pitch; they remember the friction.
• The "cheap" perception. Callers can't diagnose latency, so they attribute it to the people and the company: distracted, rude, unprofessional, or running discount phone service. Fairly or not, your call quality is part of your brand.
• Agent fatigue. People who spend all day pushing conversations uphill end the day more drained, and it compounds: flatter agents produce worse calls, which produce worse outcomes.

A worked example: the talk-over tax

In the same spirit as the outage cost exercise, here's a deliberately modest model. Every number is an assumption; replace each one with your own. We are not quoting industry statistics, because the honest ones don't exist at this granularity.

Assumptions:

• 8 staff spend most of their day on the phone (support and inside sales)
• 25 calls per person per day, 200 calls/day total
• Excess delay adds 20 seconds of pure overhead per call: collision repairs, "sorry, go ahead," repeated sentences, over-long safety pauses (a handful of talk-over incidents per call at a few seconds each; conservative for a genuinely laggy setup)
• Loaded labor cost: $40/hour

The math: 200 calls × 20 seconds = 4,000 seconds ≈ 67 minutes of staff time per day, on both ends of a two-party call but we'll count only your side. 67 minutes × $40/hour ≈ $45/day, or roughly $11,000 per year at 245 working days.

Eleven thousand dollars a year is not a catastrophe; that's rather the point. It's small enough to never force a decision, and large enough to dwarf the cost of fixing it, which is usually a jitter buffer setting, a QoS policy, or an afternoon of measurement. And the measurable time cost is the floor. The lost sale that never closed because the rapport never formed, the customer who quietly started emailing instead of calling, the agent who burned out a few months sooner: none of that is in the $11,000, and all of it is real. As with outages, the honest move is to acknowledge the unmeasurable costs exist rather than book them at zero.

What to do about it

The fix-it playbook lives in the troubleshooting post; here's the short version, ordered by what this post adds:

1. Measure mouth-to-ear, not ping. Your ping test measures one line of the budget. Run a VoIP quality test to see latency and jitter under real voice load, then account for the endpoint contributions on top.
2. Audit your jitter buffers. Find out whether your phones and PBX use fixed or adaptive buffers and what they're actually holding. A fixed buffer sized for a bad day is charging you that delay on every good day too.
3. Fix the jitter, not just the buffer. An adaptive buffer grows because jitter made it grow. Reduce the jitter (QoS, uplink congestion, Wi-Fi) and the buffer can shrink, returning milliseconds to the conversation.
4. Count your headset hops. Bluetooth on both ends of a call is a silent budget item. For latency-sensitive roles, wired headsets are the cheapest milliseconds you'll ever buy back.
5. Test from the actual user setup. The real path includes the agent's Wi-Fi, their headset, and their VPN, not the ideal-conditions path from the server closet. Test where the conversations actually happen.

The thread running through all of it: conversation is a timed activity, and the timing budget is small. An outage announces itself. Latency never will; you have to go find it, because your callers are already paying for it in three-hundred-millisecond installments.