Connect by JBRH Open Connect

The voice talked over the caller

Two opposite complaints share one set of controls. The voice talking over somebody is an interruption that was not acted on quickly enough; the voice stopping for a cough is one that was acted on too eagerly. Both are measured per reply, both have named findings in the call review, and the resume behaviour that fixes one of them is deliberately off on the host detection path.

Status
Available What this means
Audience
both
Channels
phone
In the app
#/phone-advanced, #/calls
Last verified
Product version
6.3.2

What it looks like#

Either the caller speaks and the voice carries on for a second or two before yielding, or the caller clears their throat and the voice stops mid-sentence and never picks the thought back up. Callers describe both as "it talks over me", so the review's own measurements matter more than the description.

Each reply carries an interruption measurement: how long the voice kept talking after the caller began speaking over it. Past two seconds the interruption is counted as ignored, and that is a finding rather than an impression.

The controls, and which kind each one is#

ControlKindWhat it changesCost of getting it wrong
Interruption threshold in secondsEngineHow long speech must continue before it counts as an interruptionToo high and the voice talks over people; too low and it stops for noise
Interruption threshold in wordsEngineHow many words must be heard before yieldingThe same trade, measured differently
Start-of-speech sensitivityEngineHow readily a turn is considered started — set high, so a one-word "yes" begins a turnSet low, short answers are missed entirely
False-interruption resumeEngineWhether the voice resumes after an interruption that turned out not to be oneOn the wrong detection path it resumes over a caller who really was speaking
End-of-speech silenceEngineHow long a pause must be before the caller is considered finishedToo short and the caller is cut off mid-thought

Why resume is off on the host path#

There are two ways the end of a turn can be detected: by the model's own detection, or in-process on the host, combining voice activity detection with an end-of-turn model and dynamic endpointing. The host path only works when the model's own detection is switched off — the two cannot both be in charge.

On that path, false-interruption resume is deliberately disabled. Resuming requires judging that an interruption was not real, and that judgement needs a transcript the host path does not have at that moment. Left on, every resume happened over a caller who genuinely was speaking. Off is the correct setting there, and it is not a bug report.

Causes, most likely first#

  1. The interruption threshold is set for a quiet room. Real calls have background noise, and a threshold tuned on a silent test call yields too slowly on a busy one.
  2. Noise cancellation is off or ineffective for the caller's environment. The voice hears speech that is not the caller's.
  3. A spoken acknowledgement was enabled. Do not turn this on: a host-spoken "Mm-hm" on the fast default model cut the caller off and then stalled the model for 22 seconds.
  4. The end-of-speech silence is too short. The caller pauses mid-sentence, the model believes they have finished, and the reply begins over them.
  5. Resume is on with the model's own detection, and the model misses speech starts. The host keeps its own record of presence from every transcript chunk precisely because that detection misses starts.

What Connect completed#

  • Held the conversation and measured every interruption on the wire, not from transcript timestamps.
  • Produced deterministic findings for ignored interruptions and for false stops, each paired with the setting that addresses it.
  • Kept the settings that were actually in force snapshotted against the call, so the review judges what ran rather than what is configured now.
  • Recorded the call, its summary and its follow-ups normally — an interruption problem does not invalidate the content.

What Connect did not complete#

  • It did not recover the words the caller said while being talked over. Where speech overlapped, some of it was not heard at all.
  • It did not resume the interrupted thought on the host detection path, by design.
  • It did not adjust any threshold by itself. The review recommends; a person applies.
  • It cannot fix a model-bound delay: where the model's own first token is most of the wait, no interruption setting will change the experience.

What you can do#

  1. Open the call review and look for ignored interruptions or false stops by name.

    Result The two complaints sound identical from a caller and are opposite settings changes.

  2. Change one threshold at a time in the Lab draft and place a test call.

    Result The draft applies to that call only, and the resolved settings are snapshotted with it, so the comparison is real.

  3. Test in a room like the caller's, not a quiet one.

    Result Most interruption settings that fail in production were tuned in silence.

  4. Leave spoken acknowledgements off.

    Result They are the one control here with a measured, severe failure behind it.

What an administrator can do#

  • Confirm which end-of-turn detection the line uses before changing resume behaviour; the correct setting differs between them.
  • Confirm noise cancellation is enabled for lines with noisy callers.
  • Review the interruption findings across several calls rather than one, since a single caller's habits are not a setting problem.
  • Treat model-limited findings as information, not as work — they are counted separately and do not lower the score for exactly that reason.

When to escalate#

Escalate when interruptions are ignored on most replies across several calls after the thresholds have been adjusted, when the voice resumes over a caller on a line where resume should be off, or when a caller reports being cut off and the measurements show no interruption at all — that last combination suggests the caller was not being heard rather than being interrupted.

Questions#

Why does the voice not just stop the instant anyone speaks?

Because a cough, a door, or somebody else in the room would stop it constantly, and a voice that stops every two seconds cannot hold a conversation. The thresholds exist to distinguish an interruption from a noise, and they are a trade rather than a setting with a right answer.

Should false-interruption resume be on?

Not on the host detection path — there is no transcript available to judge a false interruption by, and every resume there happened over a caller who really was speaking. On the model's own detection path it is a genuine choice.

Can a spoken acknowledgement make the voice feel more attentive?

It made it worse. On the fast default model an acknowledgement spoken by the host cut the caller off and stalled the model for 22 seconds. It stays off.