Finding where a voice agent breaks on real phone calls, and telling you which layer to fix first, cheapest first.
A voice agent that demos perfectly in the office fails on a real Indian phone call, and the reason usually sits below the words, in the physics of the line and the reality of how people actually speak. Generic call-analytics and QA tools measure business outcomes and sentiment. They cannot tell you whether a booking failed because the telephony band physically erased a consonant, because the model misheard a sound that was genuinely there, or because your own noise cleanup stripped it out. My audit tells those apart, on your own recorded calls.
These are the failure modes I look for first, because they are the ones a Western-built stack and a generic dashboard tend to miss.
Callers switch Hinglish, Tanglish or Benglish mid-sentence. A single-language speech-to-text model degrades sharply right at the switch point, which is often exactly where the important word sits.
Indian names collapse into each other, Meenatchi into Minakshi, Sarita into Sita, because the retroflex-versus-dental contrast rests on the third formant and sibilant place lives above 3.4 kHz. Both are destroyed by the narrowband telephony wall. A wrong name books the wrong person.
Dead air, a frozen media path, a short-utterance stall, or a recording that was simply truncated. These are three or four different faults at three different levels, and they get reported as one vague complaint: it hung up on me.
A crisp haan or theek hai lost before the model ever hears it. Double voice-activity detection, endpointer cliffs, and backchannels miscounted as interruptions all produce the same symptom from different causes.
Suppression that pleases a human ear strips the fricatives and plosive attacks a recogniser needs. Perceived audio quality and transcription accuracy pull in opposite directions, and the cleaner-sounding file is often the worse one to recognise.
The same symptom is usually several distinct faults spread across the call path. So every finding is pinned to one stage of the pipeline: caller, telephony, the recording tap, noise suppression, voice-activity detection and the endpointer, speech-to-text, the model, text-to-speech, playback, and back down the line to the caller.
Then the findings are ordered cheapest fix first. Agent configuration before audio setup, audio before telephony, and the speech-to-text or language model blamed last, only once the cheaper causes are ruled out. This matters because the expensive instinct, to retrain or swap the model, is usually wrong. More often the fix is a setting, a capture format, or a suppression stage that was never the model's fault.
Every reported conclusion traces back to a measured claim that carries its value, its unit, the threshold it crossed, the call and timestamp it came from, and its uncertainty. A hypothesis that needs a human to confirm it is labelled as a hypothesis, never dressed up as a definite cause. The core analysis runs on-device, so the audio never leaves the machine, and the measurements are reference-checked against Praat rather than asserted. That is the discipline that makes an audit defensible to a client's own engineers.
A Hinglish calling product for bus operators was hanging up mid-call, missing clear answers and talking over customers. I took nine recordings and built a reusable diagnostic first. All nine were 8 kHz mono, energy above 3.4 kHz sat between 0.003 and 0.6 percent, and true barge-in was simply not measurable from single-channel audio. The recommendation was to stop the build before the money went in. The full teardown is on the work page.
If you own an Indian voice agent and want to know where it actually breaks, that is the engagement I run. It works on your recorded calls, not a vendor benchmark, and it hands back a labelled failure taxonomy with per-category rates rather than an architecture diagram.
Send me a few recordings and I will tell you which layer to look at first.