There's a precise moment when a voice experience tips from "fluid" to "broken." It's not the wrong answer. It's not the crash. It's the silence: the user asks a question out loud, and nothing happens.

The threshold is known: roughly 800 milliseconds of unmanaged silence, and the illusion collapses. In a real conversation, a pause that long is filled by a glance, a breath, a "hmm", signals that say "I heard you, I'm thinking." Remove them, and the same pause turns anxious. The user wonders: did it hear me? Is it thinking? Did it crash?

A collapsed illusion of conversation doesn't rebuild. The user won't leave a negative review. They'll just stop using it.

The KPI nobody looks at

The voice hype produced dashboards full of familiar metrics: conversion, NPS, session length, drop-off. Useful, and blind to the problem.

The time between the end of the user's utterance and the start of the agent's response shows up nowhere. Google Analytics doesn't see it. Session recording tools capture it poorly. Yet it's the first quality signal users perceive, before they've heard a word of the answer.

Cognitive science is unambiguous: beyond 700–800ms with no processing signal, the brain reads the pause as an error, not as thinking. The experience doesn't degrade gradually. It breaks.

Measuring conversion without measuring that silence is like counting sales in a store where the clerk stares at customers without answering.

Technical latency ≠ perceived latency

Confusing the two is the most widespread mistake in voice deployments.

Technical latency is actual processing time: transcribing the voice, generating the answer, synthesizing speech. On a classic pipeline, expect 800ms to 1.5 seconds. Not catastrophic in absolute terms.

Perceived latency is what the user feels. And it can be engineered independently of the tech. A human doesn't go mute while looking something up: they say "let me check that…" and keep working. An audio or visual processing signal massively reduces perceived latency, at identical technical latency. With nothing, 800ms is an eternity.

At Scenaro, this principle is built into the agent itself. It exposes a state, listening, thinking, speaking, synchronized with the interface. And it's designed to talk while it works rather than leave dead air. Unmanaged silence isn't an incident: it's a design flaw.

The extreme case is the long wait. At Urbansider, building an itinerary takes real time, tens of seconds of search. Rather than hiding that wait behind a spinner, the experience transforms it: while the search runs in the background, the agent offers the traveler an interlude, a piece of Parisian culture, a neighborhood guide, a French word to learn. Pedagogical content, a relaxed tone, a touch of the unexpected.

The wait stops being a hole in the conversation: it becomes a moment of the experience.

Unmanaged silence isn't an incident: it's a design flaw.

Latency is a choice, scenario by scenario

The other mistake is treating latency as a single number to optimize. It's a trade-off, and it's made per scenario.

Two architecture families exist. Realtime: 200–400ms, full duplex, natural interruptions, the architecture of fluid conversation, at the price of less flexibility on voice selection. The STT→LLM→TTS pipeline: every component chosen and swappable independently, higher latency offset by processing signals, the architecture of flexibility and specific constraints.

On Scenaro, each brand picks its stack per scenario, across dozens of providers, with no lock-in, and the estimated cost of each configuration displayed in the editor. Discovery in full duplex demands realtime, every millisecond counts when users expect to interrupt and be interrupted. Support in discreet mode, where the agent replies in writing, tolerates a pipeline: the user reads at their own pace.

The same 900ms of technical latency produces radically different experiences depending on mode, architecture, and processing signals. Which is why benchmarking in text chat, or at launch, under ideal conditions, misses the metric that actually drives abandonment. A provider answering in 400ms when idle can climb to 1.2 seconds at peak. Without monitoring, teams don't see it. Users do.

Perceived latency is a KPI. It belongs in your dashboards, right next to conversion rate, because it's what decides whether anyone comes back.