-
I have ste up all the things . because of free trial I am unable to call the US number
-
In future I will upgrade my account and it will work fine
-
Incoming calls are shown here . In future work I am extending this project by creating an multi-agent orchestration to work better.
Inspiration
Every small-city bus stand in India has an "enquiry number" — but ask anyone who's actually called one. Lines ring endlessly, staff are overwhelmed during peak hours, and commuters end up standing at a stop with no idea if a bus is coming in five minutes or fifty. Big-city apps like Chalo or Google Maps transit solve this beautifully — for cities where every bus has GPS and every rider has a smartphone with data. Small towns and district transport corporations have neither.
The real trigger was simple: while looking into complaints on public grievance forums, we found the exact same message repeated across dozens of cities — "tried calling the bus stand ten times, nobody picked up." That's not a UX problem app designers usually think about, because it doesn't happen to people with smartphones and data plans. It happens to people who only have a basic phone and a language they're comfortable speaking in — not typing in.
That's where Yenna Bus came from: what if the "app" was just a phone call, and the interface was your own voice, in your own language?
What it does
Yenna Bus lets anyone call a single number and get bus information back — no app, no internet, no English required.
The caller dials the number. An IVR system greets them in Tamil and asks for their source, destination, and preferred time. The caller simply speaks their answers. Speech is transcribed, the source/destination are matched against known stops (handling mispronunciations, shortened place names, and Tamil-English code-mixing), and the system looks up the relevant route and timing. The commuter receives a spoken voice response with the next available bus(es) and route number, followed by an SMS with the same details for reference.
How we built it
Telephony / IVR layer — handles the incoming call, plays prompts, and captures voice input. Speech-to-Text — converts the caller's spoken Tamil (and code-mixed Tamil-English) into text. Intent & entity extraction — a lightweight LLM pipeline (Groq/Llama) pulls out source, destination, and time from noisy, conversational speech, and fuzzy-matches spoken stop names against a known stop list. Route/schedule lookup — a structured dataset of real local routes and timings (manually curated for a pilot set of Coimbatore-area routes) is queried against the extracted source/destination pair. Text-to-Speech — the matched result is converted back into natural spoken Tamil. SMS gateway — sends a text summary as a fallback/reference alongside the voice response. We drew on our existing experience with IndicTrans2 for vernacular language handling and Groq/Llama 3.3 70B for fast, low-latency inference, since call-based interactions need the response to feel near-instant
Challenges we ran into
No live GPS data for small-city buses. We initially scoped this as "real-time tracking," but small-town transport corporations don't equip buses with GPS. We had to honestly reframe the project as a schedule and route assistant rather than overpromise live tracking we couldn't back with real data — a scope correction that made the project more credible, not less impressive. Messy, code-mixed speech. Real commuters don't say clean, single-language sentences — they mix Tamil and English mid-sentence, shorten place names, or use local nicknames for stops. Getting intent extraction to handle this reliably was harder than expected. Designing for zero visual feedback. Every UX decision had to work purely through audio — no screen to fall back on for confirmation or correction, which meant rethinking how errors and misunderstandings get handled gracefully over a voice call. Latency on a live call. Voice interactions have a much lower tolerance for delay than a chat interface — every extra second of "thinking" is awkward silence on a phone call, so we had to be deliberate about keeping the pipeline fast.
Accomplishments that we're proud of
Built a genuinely novel assembly — while the individual pieces (IVR, STT, LLM, TTS) all exist off-the-shelf, nobody had put them together for this specific problem: small-city public transport access for non-smartphone, non-English-first users. Corrected our own scope honestly (real-time tracking → schedule assistant) rather than overselling a feature we couldn't deliver. Handled Tamil-English code-mixed speech, which is how people actually talk — not the clean textbook Tamil most vernacular NLP demos assume.
What we learned
The best hackathon ideas often aren't found in new technology, but in old, unsolved, unglamorous problems — a non functional enquiry helpline is not exciting to build a startup pitch deck around, but it's a real daily pain point for thousands of people. Scoping honestly (what's truly buildable and demoable) makes a stronger impression on judges than an inflated feature list. Designing for a phone call — not a screen — forces a completely different, more disciplined way of thinking about user interaction.
What's next for YennaBus
Expand the route/schedule dataset beyond the pilot set to cover more districts. Explore lightweight crowd-sourced "bus just left/arrived" reporting via SMS to approximate real-time status without requiring GPS hardware. Add support for more regional languages beyond Tamil to extend the same model to other states.
Log in or sign up for Devpost to join the conversation.