Engineering
Say your order number out loud — all fourteen digits of it — and even a person on the other end of the line might mishear one. Speech recognition has the same problem, and it matters more than it sounds: a booking reference, a tracking ID, or an insurance ID is exactly the kind of string where being one digit off doesn't give a slightly-wrong answer, it gives someone else's record.
Speech recognition is good — very good, at this point — at natural conversation, because language carries context that helps it correct itself. If a caller says a slightly garbled sentence, the model can usually infer the intended words from grammar, common phrasing, and what makes sense in context. A string of digits has none of that. "Fifteen, thirteen" and "fifty, thirteen" sound close enough to confuse a model, and there's no sentence-level context to disambiguate which one was actually said — every digit carries equal, isolated weight, and a single misheard one changes the whole ID.
This is exactly the failure mode long alphanumeric identifiers create: order numbers, tracking IDs, insurance member IDs, confirmation codes. Get one digit wrong and the agent doesn't fail loudly — it might look up the wrong record entirely, which is a worse outcome than not finding one at all.
We built collect_dtmf on the same telephony layer LiveKit documents for DTMF collection — a tool the agent can invoke mid-call that asks the caller to key in their order or tracking number on their phone's keypad and captures the literal DTMF tones, the same signal your phone has always sent when you press a key. There's no transcription step to get wrong, because there's no speech being interpreted in the first place. Whatever digits were pressed are exactly what the agent receives.
Once collected, that number is what gets used to actually look up the order, the tracking record, or the insurance claim — the same kind of async tool call we've described elsewhere, just fed by keypad input instead of a spoken answer.
Worth addressing directly, since we've made the case elsewhere that a rigid "press 1 for sales" menu is exactly what an AI receptionist is supposed to replace. The difference is scope. An IVR uses keypad input to navigate the entire call — every decision point is a button press, because the system can't understand anything else. Lexycall uses keypad input for exactly one thing: capturing an exact numeric identifier at the specific moment precision matters more than natural conversation. Before and after that moment, the call is a normal, spoken conversation. It's a single precise tool used deliberately, not the whole interaction reduced to button presses.
Anywhere a call needs to look something up by an exact identifier rather than a described request:
In each case, the alternative is asking the caller to say a long ID aloud and hoping speech recognition gets every character right — or worse, not asking for it at all and guessing at the caller's identity from name and context, which is far less reliable.
A misheard word in casual conversation is easy to recover from — the agent asks a clarifying question, or the caller notices and repeats themselves. A misheard digit in an ID lookup often isn't obvious until the wrong record comes back, and by then the conversation has already gone down the wrong path. As AI receptionists take on more identity- and record-dependent tasks — not just booking a slot, but pulling up an existing order or claim — the cost of a hallucinated digit goes up. collect_dtmf is a small, deliberate piece of engineering aimed directly at that failure mode: use natural conversation where it's reliable, and fall back to something more exact where it isn't.
Want to see it look up a real order or tracking number on a call? Book a free demo.
Join hundreds of teams running their phones on AI — without sounding like one. See a live agent on your own call flow in 30 minutes.
