Describe the latency requirements for a voice interface and why they are stricter.
Harlowmere built Duskbell to answer a restaurant's phone, take the order or the booking, and talk back like a host would. The model doing the talking was never the hard part. The hard part was making Duskbell reply inside the same silent window a real host would, because a phone call punishes a slow reply in a way a chat window never does.
The direct answer
Set the target at 700 to 800 milliseconds between the moment a caller stops talking and the moment Duskbell starts replying, and treat anything past about 1,200 milliseconds of dead air as broken, not just slow. That target is roughly three to four times tighter than what a text chat interface gets away with, because a phone call has no spinner or typing dots to prove the system is still working, only silence, and once that silence runs past about a second, people assume the line dropped, start talking over the reply, or just hang up.
Do this, in order
Set the response gap budget at 700 to 800 milliseconds for a normal turn, not "as fast as the model allows."Why: this is the number the whole pipeline has to hit, and every stage below only matters because it protects this one.
Break the gap into its five real stages, turn detection, transcription, the reply decision, speech synthesis, and the network hop, and own a number for each.Why: "voice latency" hiding inside one vague number is how a single slow stage burns the whole budget without anyone spotting which one did it.
Replace any fixed silence timer copied from a text product with a live, adaptive endpointing model.Why: a flat timer either cuts a caller off mid-sentence or leaves dead air, and both cost far more than the milliseconds saved.
Cover a live lookup with a short spoken filler instead of silence.Why: checking a table or a stock count can run past budget on its own; a filler phrase resets the caller's clock so the wait reads as checking, not broken.
Use a faster, slightly less sharp model on fast-path turns that never touch a lookup.Why: those turns have no slack left in the budget, so speed there buys more than the small accuracy loss costs on a plain confirm-and-repeat-back line.
Watch the false-cutoff rate, not just the average latency number.Why: an average can look fine while a rising share of interrupted callers quietly repeats themselves or hangs up, exactly the failure a milliseconds-only dashboard won't show.
How to answer this, stage by stage
Nobody is grading whether you can name a number. They're grading whether you know that number has to come from five real stages added together, and that voice gets a much tighter clock than text for a reason you can actually explain.
1
Scope it to one system, and name the gap before naming a number
Say it like this
"Let's ground this in one system. Duskbell is a voice assistant that answers a restaurant's phone line, built by a company called Harlowmere. Nireesha Vaskoff owns its latency budget. Before I give you a number, I want to say what 'latency' even means here: the gap between the caller going quiet and Duskbell starting to talk back. That gap is really five stages added together, not one dial you turn."
Why this works
Naming the gap precisely, before touching a number, stops the answer from treating "voice latency" as one vague feeling.
2
Ground the target in how human conversation actually runs
Say it like this
"In an ordinary phone call between two people, a reply lands about 200 milliseconds after the other person stops talking. That's true across pretty much every language it's been measured in. Let it drift past 600 to 1,000 milliseconds and a pause starts to feel like a pause. Past about a second of total silence, most people say 'hello, you still there?' or just hang up. A chat window doesn't run that same clock, because a spinner or a typing dot proves something is still happening even before any words land."
Why this works
This is the actual reason voice is stricter than text, not an assertion. Naming it stops the answer from sounding like a guess about UX preference.
3
Break the equation into its five stages
Say it like this
"Duskbell's response gap has five parts. Turn detection, deciding the caller has actually stopped. Transcription, finishing the speech to text. The reply decision itself, working out what to say, and whether that means checking a table or a stock count. Speech synthesis, turning the reply into audio. And the network hop over the phone line itself."
Why this works
Naming five separate stages, out loud, stops "it feels slow" from being treated as one number that either exists or doesn't.
4
Own each number and where it came from
Say it like this
"Turn detection runs 150 to 300 milliseconds, call it 200 on a good day. Transcription, if it's already streaming and just needs a final flush, 80 to 200, call it 100. The reply decision, on a fast path with no lookup, 150 to 400, call it 200. Speech synthesis, streamed so it starts on the first phrase instead of waiting for the whole sentence, 120 to 300, call it 150. The network hop over a proper phone trunk, 40 to 150, call it 70. Add those up and a normal confirm-and-repeat-back turn lands near 720 milliseconds."
Why this works
A number nobody can trace back to a stage is a guess wearing a stopwatch.
5
Give the range, then show what the lookup does to it
Say it like this
"Stack the slow end of every stage instead of the fast end, still with no lookup, and that same turn already runs 1,350 milliseconds, past the point where a caller assumes the line dropped. Add a live table or stock check, 200 to 700 milliseconds on its own, and a turn that needed real information can run from about 740 up to 2,050. The lookup is the single biggest lever in the whole budget, bigger than any other stage's own swing."
Why this works
This is the moment a strong candidate shows they know which assumption actually decides the answer, not just that a range exists.
6
Sanity check the number, then name the trade-off you're accepting
Say it like this
"720 milliseconds is already about three and a half times slower than two people just talking, and there's no spare room left in that number, which is the whole argument for streaming every stage instead of waiting for full sentences and full transcripts. On the fast-path turns I'd rather run a smaller, quicker model that's a little less sharp on rare menu items than a bigger one that's dead accurate but eats the whole budget by itself."
Why this works
Naming the trade-off out loud, instead of pretending speed and accuracy are both free, is what makes this a real design decision.
7
Close on the one line
Say it like this
"So: keep the ordinary turn under about 800 milliseconds, cover anything that needs a real lookup with a spoken filler instead of silence, and treat a full second of dead air as the line where a caller stops trusting the call is still happening, because that's roughly where they do."
Why this works
Ending on the actual line, in one breath, is what makes this sound like a rehearsed answer instead of a story that trailed off.
Let's learn
Duskbell answers a restaurant's phone, takes the order or the booking, and talks back like a host would, without a person picking up the receiver.
Before Duskbell, Harlowmere's pilot restaurants found their phones went unanswered on about one call in five during a Friday dinner rush, each one a missed reservation worth roughly $80 in an average night's spend, because the one host on shift was already running food or seating a table. A phone that at least kept ringing told a caller to try again in a minute.
Knowledge spark: what does "latency" mean on a phone call?
The time between the caller going quiet and the assistant starting to talk back. Not how long the whole call takes, just that one gap, repeated every time the caller stops and waits for a reply.
Duskbell answers every call within one ring and finishes a normal order in under a minute, as long as its own reply lands inside the same window a person would expect from another person on the line.
The turn: The extra half second here or there was never really the problem on its own. The problem is what a caller does the moment that gap crosses a line in their head: they think the call dropped, so they start talking over the reply, repeat their order, or just hang up and try a competitor instead.
A ringing phone at least tells someone to try again in a minute. A voice that goes quiet mid-call, then answers late, teaches a caller the line can't be trusted at all.
The build-up: what Duskbell's ordinary response gap is made of
Turn detectionTranscriptionReply decisionSpeech synthesisNetwork hop
Five stages, each streamed so it starts working before the one before it fully finishes. Add them up on a fast path with no lookup and the total lands near 720 milliseconds, in the range where a pause still reads as thinking, not broken.
The choice that mattered
Duskbell's very first turn-detection logic was an 800 millisecond silence timer, borrowed straight from Harlowmere's earlier text-based ordering bot, where it decided a typed message was finished. It shipped a working phone demo in a week. Nobody on the founding team had run a real phone line before, so nobody questioned whether a typing timer belonged on one.
At its worst, a phone line that pauses a beat too long doesn't just annoy a caller once. It trains them to distrust the line faster than a phone that never picked up at all, because now they can't tell, from one call to the next, whether Duskbell heard them or froze.
The fast path, even at its worst, stays under the 1,350 millisecond mark. A live lookup with no spoken filler to cover it sails past the point where dead air starts reading as a dropped call.
What I'd leave alone: the confirmation summary at the very end of a finished order, "so that's two margherita pizzas and a salad, table for four at seven, see you then", doesn't need this same treatment. There's no more turn-taking left to break by then, so an extra half second there costs nothing.
The lesson: a voice interface doesn't get graded on whether it's fast. It gets graded against a clock nobody wrote down, the same one that runs whenever two people talk. Miss that clock by half a second too often and a caller stops trusting the call is still happening at all.
Now here is the same thing as a story
Read the long version below when you want to feel why a pipeline that never once crashed still made callers hang up on a working phone line.
Junius Kettridge had built chat bots before joining Harlowmere, and when Duskbell needed its first turn-detection logic, he reached for what already worked: an 800 millisecond silence timer, the same debounce Harlowmere's earlier text ordering bot used to decide a customer had finished typing. It was simple, it had shipped before, and nobody on the founding team had run a phone line before.
At the first three restaurants, quiet lunch counters all of them, that timer barely showed up in a report. Diners called in slow, deliberate orders, one item at a time, and the pause before Duskbell's reply felt no different than a call center on a slow Tuesday. Nireesha Vaskoff, who owned Duskbell's latency budget and had run a host stand herself for years before joining Harlowmere, signed off on it without much thought.
Then Harlowmere signed its first Friday-night steakhouse, and the calls got faster, and messier. People say "I'll have the, actually, can I get the salmon instead" mid-sentence, pause to ask a partner what they want, then keep talking. The 800 millisecond timer, tuned on a slow lunch counter, started cutting people off mid-thought, hearing the pause after "actually" as the caller being done.
The invoice was never wrong. The decision to let a text bot's typing timer decide when a phone caller was done talking, was.
Nobody noticed a single bad call. There wasn't one. Calls just started running a little longer, a little more often, week after week, buried inside a general "average call length" number that was trending up but not alarmingly so.
It surfaced when a new host trainee, listening in on live calls her first week, said something offhand to Nireesha in the break room: "doesn't it feel like it keeps interrupting people?" Nireesha hadn't listened to a call end to end in weeks, she'd been watching the dashboard instead, and the dashboard said average response time was fine. She pulled ten real recordings that night.
What she found: on 4 of the 10 calls, Duskbell had started talking while the caller was still mid-sentence, catching a natural breath or a "let me think" as the end of the order. Every one of those callers had to stop, say "no wait," and repeat themselves. The timer wasn't broken. It had simply never been taught the difference between a caller who paused and one who was done, because at three quiet lunch counters, that difference had never mattered enough to notice.
Nireesha's first instinct was the sensible one: tighten the timer instead, maybe 500 milliseconds so Duskbell would answer faster overall. Junius talked her out of it fast, a shorter fixed timer doesn't know a pause from a stop any better than a longer one does, it just cuts people off sooner and more often. What they actually needed already existed inside Duskbell's own live transcript: a running confidence score on whether the sentence so far sounded grammatically finished, something the text bot had never needed, because a typed message always ends with someone hitting send.
The decision that opened the door went back to that very first sprint, when Duskbell was three weeks old and reusing the chat bot's timer wasn't a real cost, it was a shortcut that shipped a working demo in a week instead of a month. Nobody in that sprint planning meeting decided a text debounce timer should still be running restaurant phone calls a year later, on a Friday night, for a steakhouse instead of a sandwich counter. It just kept working, the way a decision that never once crashes stops looking like a decision anyone made.
Run that same first-week discovery again, with the adaptive endpointing model in place from the start. The new host trainee never says anything in the break room, because there's nothing to notice: Duskbell waits through the "actually, can I get the" pause the same way a real host would, and the average call finishes in under a minute without a single repeat-back. The number that would have needed a hallway comment never gets big enough to draw one.
One design let a single fixed number decide when every caller was done talking. The other lets what the caller is actually saying decide that, which is the only thing turn detection was ever supposed to be listening for.
What Junius would tell himself, back in that first sprint: reusing the chat bot's timer wasn't wrong when it shipped a demo in a week. It was a shortcut that had never been asked to survive a Friday night at a steakhouse, and nobody had put a date on when to ask it to.
The five letters, run against Duskbell's actual phone line
Not a story question wearing a framework's clothes. This is an estimation problem, and BOUND is what keeps a pipeline that "just works" from quietly training callers to hang up on it.
BBreak it down. What's the actual equation?
Duskbell's response gap equals five stages added together: turn detection, transcription, the reply decision (plus a live lookup when one's actually needed), speech synthesis, and the network hop over the phone line. Five terms, not one number standing in for "it feels slow."
Say the equation before naming a figure, or a copied-over text-bot timer gets baked into the estimate before anyone questions it.
OOwn the numbers. Where did each one come from?
Turn detection: 150 to 300 milliseconds, tuned by how confident the endpointing model is that a sentence has actually finished. Transcription: 80 to 200, streamed continuously so only a final flush is left once the caller stops. Reply decision: 150 to 400 on the fast path, plus 200 to 700 more whenever a live table or stock check is genuinely needed. Speech synthesis: 120 to 300, streamed so it starts on the first phrase. Network hop: 40 to 150, over a proper phone trunk.
This is also where the rejected alternative sits, see below: a flat 800 millisecond silence timer instead of live, adaptive endpointing.
UUse a range, not one number.
A fast-path turn with no lookup runs 540 to 1,350 milliseconds, best estimate near 720. Add a live lookup and the same kind of turn runs 740 to 2,050, because that one stage alone can add 200 to 700 milliseconds on top of everything else.
A range this wide next to a text interface's own two to five second window is exactly what makes voice the stricter one, not a stylistic preference.
NNail the sanity check. Does the number survive being compared to something real?
720 milliseconds is about three and a half times the roughly 200 millisecond gap between two people talking, so even the best case already feels a beat slower than a real host. It's a text chat window that gets the easy comparison: a user will sit through two to five seconds of a streaming reply without blinking, because a typing indicator proves the system is still working. Silence on a phone line proves nothing. That's the whole reason voice's threshold sits at roughly a quarter of text's.
The hardest step, and the one most answers skip. A number that looks reasonable on its own can still be sitting in the wrong comparison entirely.
DDirection. Which assumption would move the answer most?
Not the transcription model, not the network path. Whether a turn needs a live lookup swings the total by up to 700 milliseconds on its own, more than the combined swing of every other stage. Second biggest: whether speech synthesis streams on the first phrase or waits for the whole sentence to render before it starts talking.
Naming the assumption you trust least, out loud, is what a good estimator does that a bad one skips.
What moves Duskbell's total the most, by how wide each swing runs
Live lookupReply decisionSynthesisTurn detectionNetwork
Bar length is how many milliseconds each factor can swing the total, low to high. Whether a turn needs a live lookup dwarfs every other lever, which is why the filler-phrase fix targets that stage first, not the model doing the talking.
Three things worth stating directly, since this is where the real judgment sits. The alternative Junius's original design used, and the one Nireesha's team moved away from, was a flat 800 millisecond silence timer, rejected once the sampled recordings showed 4 of 10 calls getting cut off mid-sentence, each one forcing a caller to repeat their order. The AI-specific failure worth naming by name is false turn-end detection: an endpointing model that reads a caller's thinking pause as the caller being finished, and unlike a crash or an error, it never announces itself, it just quietly makes the caller repeat things. The guardrail is scoring the live partial transcript for grammatical completeness, not just counting milliseconds of silence, so "I'll have the" stays flagged as unfinished through a pause that a flat timer would have already cut off. That guardrail isn't free, it costs a small amount of extra model inference running continuously alongside transcription, small next to the cost of a caller who stops calling back. And the bar Duskbell holds itself to was never a single fixed millisecond number, no phone line this varied earns a fixed target. It's a range, watched against the false-cutoff rate as much as the average, because a fast average sitting on top of a rising cutoff rate is the exact number that looks healthy right up until it isn't.
And if you want to be sure it really works, try it somewhere else
Same five letters, a warehouse pick-by-voice headset instead of a restaurant phone line, and this time the lever isn't whether a stage needs a live lookup, it's what's actually waiting on the other end of the pause: a caller's patience, or a picker's hands, already moving.
Loadcall is a pick-by-voice system Barrowfen runs across its regional warehouses. A headset reads a picker the next bin and quantity, the picker grabs it and says "pick complete," and Loadcall reads the next instruction. Havilah Corravik owns its latency budget.
The decision Havilah would take back
Loadcall's first release read back a full item description every time, "grab three units of the blue ceramic mixing bowl from bin fourteen," modeled on the same wordy readback human supervisors had radioed over two-way handsets for years. Barrowfen's own operations manual recommended the full readback, so nobody questioned it.
Loadcall never needs a live lookup, the whole shift's pick list downloads to the headset at clock-in, so that lever barely moves here. What moves the loop instead is how many words the reply says. Trimming the readback to bin and quantity only, "bin fourteen, three," cut the confirm-and-next-instruction loop from about 1,100 milliseconds to about 340, and picks per hour on regular runs rose by roughly 9 percent, not because recognition or the reply logic got faster underneath, but because Loadcall stopped saying words a trained picker didn't need to hear.
Same method, different lever: for Duskbell, the lever that swung the estimate was whether a turn needed a live lookup. For Loadcall, every pick already runs off data sitting on the device, so there's no lookup to swing. The lever here is how much the reply actually says, since a picker's hands are already reaching for the next item before Loadcall finishes talking, and every extra syllable is time spent standing still with an empty hand.
Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: state the target the way the person waiting on it would feel it, then name what's actually eating that window.
Cost: there's no budget this quarter for a full re-record of Loadcall's prompts and a change to the readback logic both. Trim the readback first, it's a config change, not a re-record, and it's the bigger lever anyway.
The model got better, for real: say Loadcall's speech recognition gets meaningfully faster next quarter. That shaves maybe 40 milliseconds off one stage. It does nothing about a confirmation phrase that's still saying six more words than a picker needs to hear.
Where people run it wrong.
They copy a confirmation style from wherever it was written first, a two-way radio script, a chat bot's timeout, instead of asking what this specific interface's own turn-taking clock actually is.
They chase milliseconds inside a stage that's already fast, shaving 40 off recognition, while ignoring a stage that's needlessly slow by half a second, a readback nobody asked for.
They set one latency target for the whole company instead of asking who is actually waiting on each kind of turn. A caller's patience and a picker's hands run on two different clocks.
How to use it live. Ask the real question before quoting a number: "before I give you a millisecond target, who's actually waiting on this reply, and what are they doing while they wait?" That's the question that tells you whether 700 milliseconds is generous or already too slow.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework is this, and what's its one job?
Tap to flip
ANSWER
BOUND: show the arithmetic, own the assumptions. Built for estimation and sizing questions like a latency budget, not a story about someone's habit.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Nireesha Vaskoff, who owns Duskbell's latency budget at Harlowmere, working alongside Junius Kettridge, the engineer who built its original turn-detection timer.
3 · THE BLIND SPOT
What did the original 800 millisecond timer never tell apart?
Tap to flip
ANSWER
A caller who paused mid-sentence and a caller who was actually done talking. It cut people off either way, and 4 of 10 sampled calls needed a repeat-back because of it.
4 · THE EQUATION
What five stages make up Duskbell's real response gap?
Tap to flip
ANSWER
Turn detection, transcription, the reply decision (plus a live lookup when needed), speech synthesis, and the network hop over the phone line.
5 · THE OLD DECISION
What decision would Junius take back?
Tap to flip
ANSWER
Reusing Harlowmere's text bot's 800 millisecond typing timer as Duskbell's voice turn-detection logic, a fast shortcut for a one-week demo nobody revisited once real Friday-night calls got messier.
6 · THE NUMBER
Fill in the blank: Duskbell's fast-path best estimate lands near ___ milliseconds. Dead air past about ___ milliseconds reads as broken.
Tap to flip
ANSWER
About 720, and about 1,200. A turn that also needs a live lookup can run from about 740 up to 2,050, which is why it needs a spoken filler instead of silence.
7 · THE REPLAY
Same first-week discovery, new design, what changes?
Tap to flip
ANSWER
With adaptive endpointing from the start, Duskbell waits through a real mid-sentence pause instead of cutting it off, the average call finishes in under a minute, and there's no cutoff rate for a new hire to notice or mention.
8 · CROSS-PRODUCT TRANSFER
Section 4 answers this same question again for a different product. Which product, and what's the different lever there?
Tap to flip
ANSWER
Loadcall, a pick-by-voice system Barrowfen runs in its warehouses. There the lever isn't a live lookup, it's how many words the reply says back, since a picker's hands are already moving before Loadcall finishes talking.
Check yourself Score: 0 / 0
Multiple choice
1. Why does a voice interface's silence threshold need to be so much tighter than a text chat interface's response time?
A. Voice models always run slower than text models.
B. A caller has no visual proof the system is still working, so silence past about a second reads as a dropped call, while a spinner or streaming text keeps a chat user's trust for several seconds.
C. Phone networks carry less bandwidth than the internet.
D. Restaurants have stricter customer service rules than software companies.
Show hint
Look at the N step in the framework recap, the paragraph comparing voice's threshold to text's.
Show answer
B. A chat window's typing indicator is ongoing proof of life. A phone line's silence proves nothing either way, so people fall back on the same clock they use talking to another person.
Fill in the blank
2. Duskbell's ordinary, no-lookup turn should land near ___ milliseconds. Dead air past about ___ milliseconds reads as a dropped call.
Show hint
Look at the O and U steps in the framework recap, right after the equation is broken down.
Show answer
About 720 milliseconds, and about 1,200 milliseconds. The fast-path range runs 540 to 1,350; a turn that also needs a live lookup can run all the way to 2,050, well past the point where dead air starts reading as broken.
True or false
3. True or false: the single biggest lever on Duskbell's total response time is which speech-to-text model does the transcribing.
True
False
Show hint
Check the sensitivity chart in the framework recap section and see which bar is longest.
Show answer
False. Whether a turn needs a live lookup can swing the total by up to 700 milliseconds, more than the swing of any other single stage, including transcription.
Short answer, name the rejected alternative
4. What alternative did Junius's original design use for turn detection, and why did Nireesha's team move away from it?
Show hint
Look at the O step in the framework recap, in the paragraph right after the five letters.
Show answer
Model answer: A flat 800 millisecond silence timer, borrowed from a text ordering bot's typing-indicator debounce. It was dropped once sampled recordings showed 4 of 10 calls getting cut off mid-sentence, forcing the caller to repeat their order.
Short answer, apply it yourself
5. Think of a voice assistant or phone system you've used yourself, a smart speaker, a bank's automated line, a customer service call. Name one moment it made you wait, and say whether that wait felt like thinking or like something was broken.
Show hint
Think about whether anything told you the system was still working during the wait, or whether you just got silence.
Show answer
Model answer: A bank's automated line that goes silent for several seconds while pulling up an account feels broken, because nothing tells you it's still working. The same wait, covered with "let me pull that up for you," feels like thinking instead, even at the same length.
Multiple choice
6. If Duskbell's live lookup step got twice as slow, from a best case of 350 milliseconds to 700, what happens to the best-case total for a lookup turn?
A. It stays near 720 milliseconds, since the lookup runs in parallel with everything else.
B. It rises from about 1,070 to about 1,420 milliseconds, comfortably past the 1,200 millisecond line where dead air starts to read as broken.
C. It falls, because a slower lookup gives the model more time to prepare a better answer.
D. It has no effect, since the sanity check only applies to the fast path.
Show hint
Start from the fast-path best estimate of 720 milliseconds and add the new lookup time on top.
Show answer
B. 720 plus 350 is about 1,070; 720 plus 700 is about 1,420. That's why a slower lookup needs a spoken filler even more urgently than a fast one does.
Before you close the answer
Why this works
Tests whether you'll treat "latency" as one soft feeling instead of five real stages, and whether you know the actual reason voice's threshold is tighter than text's, not just that it is.
Follow-up traps
"Why not just always use the fastest, smallest model everywhere, and skip all this budgeting?" Response: a model swap only touches the reply decision's 150 to 400 millisecond range. The live lookup, the biggest lever at up to 700 milliseconds, doesn't care which model is running, so a faster model alone can't fix a lookup-heavy turn.
"Isn't one 800 millisecond number, applied everywhere, close enough?" Response: no, because "everywhere" isn't one clock. A phone caller's patience and a warehouse picker's already-moving hands run at different speeds, and a number tuned for one reads as sluggish on the other, or overcautious the other way around.
If pressed
The adaptive endpointing model doesn't just watch for silence. It scores the live partial transcript for grammatical completeness in real time, so "I'll have the" stays flagged as unfinished through a pause, while "that's all for the salad" scores as done the moment the sentence actually resolves, which is what lets it wait through a pause a fixed timer can't tell apart from a stop.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
