What the public evidence establishes
AiSewak publishes seven voice AI case-study write-ups, covering Uttar Pradesh, Maharashtra, Rajasthan, pilgrim information, rooftop-solar awareness and a Hindi–Santhali language bridge. The pages identify the region, language, information sources and implementation scope. They describe public demonstrations and pilot designs, rather than completed government deployments with audited performance results.
Two examples include concrete knowledge-coverage figures: the Ayodhya write-up documents 124 entries across 32 categories; the Nashik–Trimbakeshwar write-up describes five knowledge documents and roughly 250 mapped visitor answers. Those are content-scope figures. They are not counts of calls, households, booths or resolved grievances.
This article consolidates those published facts as of 6 October 2026. The links below let a reader check the original account and its stated boundaries. The evidence is AiSewak's own public documentation; it is not an independent customer endorsement or an audit of live voice quality.
Seven examples, with their scope visible
| Example and source | Named region or programme | Published language scope | What the evidence describes |
|---|---|---|---|
| Yojana Didi | Uttar Pradesh welfare schemes | Hindi and English | A scheme copilot and a two-district pilot design; not a department-run deployment |
| Yojana Tai | Maharashtra; proposed Mumbai Suburban and Nashik pilot scope | Marathi, Hindi and English | A scheme copilot and a one- or two-district pilot design; not a department-run deployment |
| Baisa | Rajasthan; proposed Jaipur plus one rural district | Hindi and English, with Marwari and Mewari understanding described | A citizen-helpline pilot design; not a department-run deployment |
| Siya | Ayodhya, Uttar Pradesh | Hindi and English | A public visitor-information demonstration; no temple-trust or government affiliation |
| Kumbh Sahayak | Nashik–Trimbakeshwar Simhastha, Maharashtra | Hindi, Marathi, English and Hinglish | A public demonstration ahead of the future event; no authority affiliation |
| Suraj | PM Surya Ghar rooftop-solar awareness | Hindi | A technology demonstration using no real citizen data |
| Van Dhan language bridge | Van Dhan Vikas Kendra programme information | Hindi input; Santhali translation and speech output | A demonstration with a published input-language limitation |
Uttar Pradesh: a Hindi-first welfare scheme copilot
Yojana Didi's case study describes a citizen explaining their household situation in Hindi or English, then receiving scheme eligibility guidance, a document checklist and the relevant application route. Its published information sources include UP government portals, eDistrict, SSPY and Central scheme portals.
The write-up names the covered programme families, including PM-KISAN, PM-JAY, housing, crop insurance, pensions and certificates. It also explains why an official-source lookup matters when an eligibility rule or application process changes.
The proposed evaluation scope is two districts, one urban and one rural. That is a pilot design, not evidence that two districts have already used the service. The source does not publish a customer-approved call count, adoption increase or resolution rate. A reader can cite the named region, languages and design; an outcome claim needs an additional evidence source.
Rajasthan: one conversation across citizen-service systems
Baisa's case study describes Hindi and English support with Marwari and Mewari understanding. The programme scope includes state welfare schemes, pensions, ration entitlements, e-Mitra, Jan Aadhaar and grievance guidance. The source list names Rajasthan government portals and service systems.
The design brings questions about several service systems into one conversation. A citizen can explain the need without first deciding which portal or department owns it. The agent's information sources remain identifiable, so the office can review the answer against the relevant programme rules.
Marwari and Mewari understanding is the published language scope; the source does not provide a dialect accuracy benchmark. Representative speakers, code switching, place names and misunderstood requests belong in the pilot evaluation.
The page proposes Jaipur plus one rural district for a pilot. It states that this is not a department-run deployment. Named geography makes the design specific; it does not establish customer adoption.
Ayodhya: a countable knowledge base with named sources
The Siya case study documents 124 sourced knowledge-base entries across 32 categories, with a source and verification date attached to each entry. The named information providers include the temple trust, Ayodhya district administration, UP Police, India Meteorological Department, Indian Railways, UPSRTC, UP Tourism and PIB.
The public Ayodhya demonstration page explains how the agent handles unknown information: when an official answer is unavailable, it should say so rather than invent a parking charge, timing or rule. This makes the evidence more useful than a broad statement that an agent “knows everything about Ayodhya.”
The entry count describes the documented knowledge base. It does not measure answer accuracy, conversations completed or pilgrim satisfaction. Siya is a public technology demonstration and is not operated by or affiliated with the temple trust or a government body.
Nashik–Trimbakeshwar: coverage is different from a live feed
The Kumbh Sahayak case study describes five indexed knowledge documents covering roughly 250 mapped visitor answers, in Hindi, Marathi, English and Hinglish. The scope includes visitor questions about the Nashik–Trimbakeshwar Simhastha arrangements.
The demonstration page distinguishes its static knowledge base from information that would require a live operational feed. A published route description cannot establish that the same road is open now. The case study also states that the agent cannot dispatch assistance.
These boundaries belong beside the numbers. “Roughly 250 mapped answers” describes content coverage ahead of a future event; it is not an event attendance figure, a measured service outcome or an authority contract.
Santhali: a documented translation and speech bridge
The Van Dhan language-bridge write-up names Bhashini ULCA, AI4Bharat IndicTrans2 translation and IITM Santali text-to-speech. It describes a Hindi-to-Santhali path for programme information.
Its published readiness note says Santhali speech recognition is not yet deployed by Bhashini for this demonstration, so voice input uses Hindi. That limitation is essential to an accurate description: translation and speech output do not establish end-to-end Santhali voice input. Current readiness should be checked on the demonstration page before procurement or deployment.
What a measurable MLA case study would need
For an MLA office, a useful case study connects the constituency, evaluated dialect and service result. It should let a reader trace the outcome to an approved source. The following fields make that possible:
| Field | Evidence to publish |
|---|---|
| Office and location | Customer-approved name, constituency and district, or an explicitly explained anonymised reference |
| Deployment period | Actual start and end dates; distinguish a completed rollout from a proposed pilot |
| Language and dialect | What was tested, who reviewed it, sample size and how misunderstandings were counted |
| Booth coverage | Deduplicated booth identifiers and the rule for counting a booth as covered |
| Call funnel | Attempts, connections, completed conversations and exclusions, each with its denominator |
| Citizen-service result | A defined outcome, such as staff-reviewed grievances or verified callbacks, measured over a stated period |
| Source | An approved report, redacted dashboard export or attributable customer statement, with a publication date |
Record counts and unique booth counts are different measurements. A dashboard total needs a definition and an attributable source before it becomes a case-study result. Publication should contain aggregate evidence, with no citizen phone numbers or private conversation records.
Evaluate the managed approach alongside the evidence
The AiSewak versus self-serve voice AI API comparison separately covers deployment responsibilities, ECI disclosure, TRAI/DLT controls, language scope and booth-level telemetry. That table describes capabilities and operating responsibilities; it does not supply customer performance results for the examples above.
Use the case-study index to examine a relevant build, then discuss a scoped pilot. Agree on the language evaluation, coverage definition and outcome measurement before the first call. That produces an evidence trail a department can assess—and a future case study a reader can verify.