Press 1 or just say it: DTMF versus speech input in voice bots

Updated 2026-09-19 · 5 min read · By the Convo360 team

Two ways to collect an answer on a call

Every voice bot needs a way to capture what the caller wants, and there are really only two mechanisms: DTMF (dual-tone multi-frequency, the tones made by pressing keys on the keypad) and speech recognition (the bot listens and transcribes what is said). Classic IVR systems ('press 1 for sales, press 2 for support') are built entirely on DTMF. Modern AI voice agents lean on speech because it lets people just talk instead of memorising a menu tree.

In practice, the best Indian deployments rarely pick one exclusively. They use each where it is strongest, and the choice usually comes down to three factors: how noisy the caller's environment is likely to be, how many possible answers the question has, and how sensitive the information being collected is.

Where DTMF is still the better choice

• Noisy environments. A caller standing in a market, on a construction site, or in a moving auto-rickshaw is hard for speech recognition to parse accurately. A keypad tone cuts through background noise reliably because it is a fixed frequency signal, not an audio waveform the system has to interpret.
• Short, fixed-choice answers. 'Press 1 to confirm, press 2 to reschedule' is unambiguous. There is no accent, dialect or mispronunciation to worry about.
• Sensitive digits. Never collect OTPs, card numbers or passwords by voice or keypad on an automated call, this is exactly the kind of request scammers imitate, and a legitimate AI agent should never ask for it either.
• Low-confidence speech moments. When the speech engine cannot confidently parse an answer, dropping back to 'or press 1 for yes, 2 for no' resolves it in one step instead of asking the person to repeat themselves.
• Language-neutral menus. A number pressed on a keypad means the same thing regardless of which of India's many languages the caller speaks, useful for a first-level menu before the bot has even confirmed a language preference.

Where speech input wins

• Open-ended questions. 'What time works for your delivery?' has too many possible answers to map to a keypad menu.
• Natural conversation. Speech lets the caller interrupt, ask a follow-up, or say 'actually, change that to Tuesday', a keypad menu cannot do that.
• Multilingual callers. A caller speaking Hindi, Tamil or Hinglish can just talk, rather than learning a new menu structure in a language that may not be their own.
• Shorter calls overall. Skipping a scripted menu and just asking the question directly is usually quicker when speech recognition is accurate for the context.
• Longer or descriptive answers. Capturing a delivery address, a complaint description, or the reason for a call is only realistic by speech, a keypad simply has no way to represent free text.

Accuracy in noisy conditions: what actually happens

Speech recognition accuracy on a phone call depends heavily on three things: background noise, network quality on the caller's side, and how far the phone is from their mouth on a hands-free or speakerphone call. A caller on a two-wheeler with traffic noise, or one who has put the call on speaker while doing something else, produces noisier audio than someone holding the phone to their ear in a quiet room.

Rather than trying to eliminate this with a better microphone setting, the practical fix is a hybrid gather with a low-confidence fallback: if the speech engine returns a low confidence score, or hears nothing usable within a short window, the bot should immediately offer the DTMF alternative instead of repeating the same open question and hoping for a clearer answer the second time. Repeating an unclear question rarely produces a clearer answer; changing the input method usually does.

Hybrid gather: the practical default

A hybrid gather listens for speech and DTMF at the same time, on the same prompt. 'To confirm your appointment, say yes or press 1. To reschedule, say reschedule or press 2.' The caller picks whichever is easier for them in that moment, no separate menu, no extra step. This is the pattern most telephony platforms (Exotel, Plivo, Twilio) support natively through their gather APIs, and it is the one that best fits how people in India actually make calls: sometimes from a quiet office, sometimes from a two-wheeler in traffic.

OTP-free confirmations: what to ask for instead

A voice bot sometimes needs to confirm identity or authorise an action without ever touching an OTP, card number or password. The safer pattern is to confirm against something the caller already has on record with you rather than something they type or say fresh, for example asking the caller to confirm the last two digits of an order number already sent to them on WhatsApp, or simply asking them to confirm their name and the service they booked. None of this should ever double as a payment credential; if payment is needed, send a secure link rather than collecting numbers on the call.

This also matters for trust: callers in India have learned to be wary of anyone asking for digits over the phone, because it mirrors how phone scams operate. A bot that never asks for sensitive numbers, and says so plainly if a caller sounds unsure, builds more confidence than one that pushes through the request regardless.

Building this on Convo360

Convo360's voice blocks include a Gather node that accepts DTMF, speech, or both together, plus a DTMF Menu block for pure keypad flows and a Transfer block to hand off to a human when neither input resolves the request. In the Flow Builder you set the timeout, the number of retries before falling back, and what happens on no input at all, typically a transfer to a live line or a WhatsApp follow-up. Because flows are drag-and-drop, you can test both input styles in Preview / Try-it before a single real call goes out, and Flow Logs show which input method each caller actually used at every step.

Step by step

1. Add a Gather block to your voice flowInsert a Gather node at the point where you need an answer, and set it to accept both speech and DTMF.
2. Write a hybrid promptPhrase the question so it invites either input, for example 'say yes or press 1 to confirm'.
3. Set a low-confidence fallbackConfigure the flow so a low speech-confidence result immediately offers the DTMF alternative instead of repeating the question.
4. Route sensitive confirmations to DTMF onlyFor anything referencing an order number or amount, prefer a DTMF Menu block and avoid asking the caller to say numbers aloud.
5. Add a Transfer for repeated failuresIf neither input resolves the request after a couple of tries, route to a Transfer block to a human agent.
6. Test both input styles in PreviewUse Preview / Try-it to dry-run the flow with both speech and keypad responses before it goes live.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.