Voice is the only interface that reaches everyone
Literacy, language and device assumptions quietly exclude most of the people an advisory service is meant to serve.
Any service delivered through an app makes three assumptions before it says anything useful: that the user has a smartphone, that they can read, and that they can read in a language the app supports. Each assumption removes a large share of the intended audience, and the shares compound.
A plain phone call makes none of them. No install, no storage, no literacy requirement, no language barrier if the system speaks what the household speaks. It is also, by a wide margin, the hardest of the options to build well. Latency matters. Interruptions matter. Dialect matters. A wrong answer delivered confidently in someone’s mother tongue does more damage than a dashboard nobody opens.
A dashboard nobody opens is not information.
The engineering is worth it because the alternative is a coverage ceiling you cannot fund your way past. An agricultural collective we work with reached roughly a tenth of its nine thousand households through written advisory. The same content on an answered call reaches most of them.
There is a second-order effect worth naming. Voice produces a record of what people actually ask, in their own words, which is the best source of programme intelligence most organisations have never had.
If you are choosing one interface to build properly, build this one.
The three assumptions an app makes
A smartphone. Literacy. A supported language. Each assumption looks reasonable in isolation and devastating in combination. In a rural block, the share of the intended audience that clears all three is frequently under a third, and the people excluded are systematically the ones a programme most wants to reach.
A voice call clears all three at once. That is the entire argument, and it is strong enough to justify considerably harder engineering than an app would require.
Key points
- App delivery compounds three exclusions: device, literacy, language.
- A plain call clears all three, but demands harder engineering: latency, interruption, dialect.
- Voice produces a record of what people actually ask, in their own words.
- Confident wrong answers in a mother tongue do more harm than an unopened dashboard.
What makes voice hard to build well
Latency is the first problem. A pause of more than a second reads as a dropped call, and people hang up. Interruption is the second: real conversation is not turn-based, and a system that cannot be cut off mid-sentence feels like an IVR menu. Dialect is the third, and the least tractable; a model trained on broadcast Hindi will mishear a farmer in Bundelkhand.
The fourth problem is refusal. A voice system must be willing to say it does not know, in a register that does not sound evasive. Confidence is the default failure mode of these models and the most dangerous one in an advisory context.
Questions this raises
Does voice work for complex transactions?
Rarely. It is excellent for advisory, reminders, triage and intake; poor for anything requiring a document or a signature.
What about call cost at scale?
Outbound cost is the main constraint. Most deployments settle on inbound calls with a missed-call trigger, which shifts the economics substantially.
How do you evaluate quality?
Sample real transcripts weekly with a domain expert. Automated metrics miss the failures that matter here.