Response quality wasn't the thing that made customers trust or distrust our voice AI responder. Response speed was. Get the words right but answer half a second too slowly, and people talk to it like a machine. Answer fast, and they talk to it like a person.
What we were doing before we learned this
Our first voice AI deployments prioritized answer accuracy and natural-sounding phrasing, treating response latency as a secondary performance metric to optimize once the core logic worked. A response in under a second felt fast enough by any normal software standard.
What changed our mind
Call transcripts told a different story than our latency dashboards did. Above roughly 400-500ms, callers changed their own behavior: shorter sentences, more pauses, more "hello, are you there?" — the classic tells of someone talking to an IVR menu, not a conversation partner. Below 250ms, the same callers spoke in full, natural sentences and interrupted the system mid-response the way they would a human.
- Latency wasn't just a UX metric — it was actively shaping how honestly people used the system
- Below the 250ms threshold, call resolution rates improved even though the underlying answer logic hadn't changed at all
People don't consciously measure latency. They just decide, within a few hundred milliseconds, whether they're talking to something worth talking to properly.
What we do differently now
Sub-250ms response time is now a hard requirement for any voice AI deployment, engineered at the SIP gateway level rather than left to whatever the underlying model happens to return. Sentinel, our internal voice gateway, exists specifically because commodity telephony stacks couldn't reliably hit that number.