Building a Hindi voice agent for driver support: a technical proof
of concept
A working proof of concept for Battery Smart, India's largest EV
battery swapping network: a voice agent that speaks Hindi, pulls
live data from driver, battery, and station APIs, and was designed
to resolve in-scope calls end to end. Built and validated. Not
deployed to production.
POCBuilt and validated, not deployed to production
HindiPlus code-mixed Hinglish, natively handled
3Live data systems wired in: driver, battery, station
Client Context
Phone-first support at fleet scale
Battery Smart operates India's largest EV battery-swapping network.
Its users are drivers on the road all day, Hindi-speaking and
phone first. When a driver needs to know their battery status, find
the nearest station with available batteries or check a payment, they
call.
That made the call centre the operational bottleneck: every new cohort
of drivers added call volume and the only way to absorb it was more
headcount.
The Problem
Support costs scaled linearly with growth
Most inbound calls were repetitive, structured lookups, battery
status, station availability, swap history, account and payment
queries; consuming trained agents on work a system could do.
Peak hour queues left drivers waiting at swap stations for answers
they needed immediately.
The caller base is Hindi first. Conventional IVR menus and
English centric bots performed poorly and drove calls straight back
to human agents.
24/7 coverage meant night shifts and redundancy, expensive to
staff, hard to retain.
The Solution
A voice agent proof of concept wired into live data
We built a Hindi voice agent that answers the call, understands the
request, fetches the answer from live systems, and speaks it back in a
full conversation loop designed to run without a human in it.
Hindi native speech pipeline. Sarvam AI STT/TTS
tuned for Hindi and Hinglish code switching, robust to noisy
roadside audio.
Real answers, not scripts. The LLM agent layer
calls Battery Smart's live APIs at answer time, so battery state,
station availability, and account data are live, never canned.
Hard scope guardrails. The agent was built to
resolve in-scope queries end to end and gracefully hand anything
else to an escalation path with full context; it doesn't guess.
Conversational latency. A streaming STT/TTS
pipeline keeps response times natural by never doing work in
sequence that could happen in parallel.
What We Validated
A working proof of concept, not a production deployment
This was built and validated as a proof of concept. It was
never deployed to Battery Smart's production call flow, and
Battery Smart is not using it today.
The build answered the hard technical questions that decide whether
a project like this is even possible:
Hindi-first conversation held up. The agent
handled natural code-switching between Hindi and English,
including mid-sentence switches, without falling back to a
translation pipeline.
Live-data tool calling worked end to end. The
agent queried driver, battery, and station APIs mid-conversation
and spoke back real, current data rather than canned answers.
Scope guardrails held. Queries outside the
defined scope, disputes, refunds, anything contractual, routed to
an escalation path with the full conversation context attached
instead of the agent guessing.
The hard parts were real. Tuning speech
recognition for noisy roadside audio, keeping the response loop
conversational under streaming constraints, and writing scope
guardrails tight enough to trust with account and payment data
were each their own engineering problem, not a footnote.