AiSewak supports three MLAs in Uttar Pradesh, handling approximately 2 lakh calls per month combined across the three engagements, according to AiSewak's operating account. The work covers an AI personal assistant that answers when the MLA misses a call and takes a message on the MLA's behalf, rally invitations, and updates to citizens about work done by the MLA.
At this scale, the useful engineering question is what happens around the conversation: how the call reaches the assistant, how a message survives processing failures, what office staff can act on, and which numbers demonstrate useful service.
This detailed account combines the confirmed engagement scope, a review of AiSewak's implemented MLA intake and reporting components, and worked planning calculations. Client names, parties, constituencies and citizen records remain private. Reported activity, implementation details and illustrative calculations are identified separately throughout.
What the three MLA engagements establish
| Engagement fact | Scope reported by AiSewak |
|---|---|
| Offices supported | Three MLA engagements in Uttar Pradesh |
| Status | Ongoing, as reported in November 2026 |
| Monthly activity | Approximately 200,000 calls combined |
| Inbound use | Answer when the MLA misses a call; take a message |
| Outbound uses | Rally invitations and updates about MLA work |
The combined total is not 2 lakh calls for each MLA. It is also not a verified count of unique citizens, connected conversations or resolved grievances. The published operating account does not yet specify the attempts-versus-connections definition, the split between workflows, or a reporting-period export.
The technical sections describe components reviewed in AiSewak's MLA implementation on 4 November 2026. They do not establish that every component, provider configuration or dashboard is deployed identically across all three engagements. The distinction lets another office inspect the engineering without mistaking a product capability for a measured customer result.
What 2 lakh calls per month means operationally
Using the approximate reported total, a 30-day planning month gives the following arithmetic:
| Calculation | Approximate equivalent |
|---|---|
| 200,000 ÷ 30 days | 6,667 calls per day across the engagements |
| 200,000 ÷ 3 offices | 66,667 calls per office if split equally |
| 200,000 ÷ 30 ÷ 3 | 2,222 calls per office per day if split equally |
| 200,000 ÷ 30 ÷ 8 hours | 833 calls per hour within an assumed eight-hour window |
These are planning equivalents, not observed daily or office-level figures. The actual distribution may be uneven: an invitation batch, a public announcement and ordinary incoming calls create different demand patterns.
The distinction changes procurement. An office buying only a monthly call allowance can still encounter a busy period that exceeds its simultaneous-call capacity. Conversely, reserving capacity for the busiest imagined hour can waste money if the actual traffic is spread through the day. Monthly volume establishes the workload; timestamped call records establish when that workload arrives.
How the missed-call personal assistant works
The confirmed workflow is straightforward: a citizen calls the MLA; when the MLA misses the call, the AI assistant answers and takes a message on the MLA's behalf. It should not be described as an automatic callback service. A later request for a callback is a separate office task.
Routing the original incoming call
A practical implementation needs a telephony rule that transfers unanswered calls to the assistant. Conditional forwarding, a managed phone number or a contact-centre route are possible approaches; the precise routing configuration for these clients is not disclosed here.
An acceptance test should distinguish no answer, busy, rejected and unreachable calls. Those conditions can behave differently. The office also needs to confirm that calls answered by the MLA remain with the MLA, and that the assistant receives the caller identity available from the telephone network.
This is why a browser demonstration alone cannot validate missed-call handling. It can demonstrate conversation quality, while an actual telephone test establishes whether the original call reaches the assistant under the agreed conditions.
Taking a useful message
The assistant's task is to preserve the caller's request clearly enough for a person to follow up. Consider this fictional message-taking example, not a customer transcript:
A caller reports that water has not reached their lane for three days, gives a nearby landmark, and asks the office to arrange a response.
A useful record separates the water-supply concern, location supplied, reported duration and requested follow-up. If the caller did not give a ward number or complaint reference, those fields remain unknown. Filling them with plausible guesses would make the message harder to trust.
The conversation should confirm ambiguous details without forcing every caller through a long form. An office can agree which fields are essential and which are optional. A caller seeking an appointment may need a reason and preferred time; a service complaint may require a locality and a concise description.
The assistant should identify its role clearly. Taking a message does not authorise it to promise a meeting, guarantee government action, or claim that the MLA personally heard the call. The handover to staff is where responsibility for the next step becomes explicit.
The technical path from conversation to office record
AiSewak's reviewed MLA components separate the live conversation from post-call analysis. The conversation gathers the message. A subsequent processing step turns the completed transcript into structured information for review and reporting.
The implemented intake path has six useful stages:
- Receive a provider's post-call event.
- Authenticate the request and validate its structure.
- Save the initial call record and available caller number.
- Analyse the transcript separately from the live conversation.
- Validate extracted fields and check supporting transcript passages.
- Store the analysed record for office views and aggregate reporting.
A webhook carries the completed call
A webhook is an HTTP notification sent from one system to another when an event occurs. In the reviewed integration, Sarvam supplies a completed inbound-call payload. Its documented fields include an interaction identifier, duration in seconds, timestamps, caller number and transcript turns. See Sarvam's inbound webhook specification.
The implementation uses TypeScript and Zod to validate incoming data. It retains a call identifier, timestamps, duration, channel and transcript before attempting model-based extraction. Redis-backed storage keeps the record and a time-ordered index for retrieval.
Saving first matters because a successful conversation and a successful analysis are separate events. If extraction fails, staff still need a record of the call. A missing model summary should not erase the evidence that someone contacted the office.
The model extracts a defined record
The extraction schema covers several groups of information:
| Record group | Examples of fields |
|---|---|
| Caller context | Name, observed language, location when supplied |
| Issues | Category, summary, requested action, supporting text |
| Follow-up | Human follow-up, meeting request, callback request |
| Processing | Analysis status, attempt count, analysis timestamp |
The caller's phone number comes from provider metadata, rather than asking the language model to invent or reconstruct it. That is a small design choice with a large practical consequence: an incorrect callback number makes even an excellent summary unusable.
The implementation can store multiple issues from one call. A caller mentioning both a water problem and a pension delay should not force the office to choose only one. Correspondingly, an issue count and a call count can legitimately differ.
Extraction has explicit failure states
The reviewed configuration permits two extraction attempts: a primary attempt and one fallback. Records distinguish pending, done and failed analysis. This is an implementation setting, not a claim about a measured success rate.
Failed analysis is included in a needs-review view. Pending analysis becomes eligible for that view after five minutes. The threshold identifies processing that needs attention; it is not a promised citizen-response time.
Repeated delivery also needs care. Storage uses the interaction identifier as the record key, and an already completed analysis is reused on later delivery. That reduces duplicate records from sequential retries. It should not be interpreted as proof of exactly-once processing under every concurrency or failure condition.
Keeping the assistant's summary tied to what was said
A fluent summary can still be wrong. AiSewak's reviewed extraction component requests transcript evidence for each issue, removes supporting snippets that cannot be found in the transcript, and flags issues left without supporting snippets.
This provides a review signal rather than a guarantee of truth. A matching quotation does not prove that every surrounding inference is correct. Names, numbers, locations and requests still deserve particular attention during quality checks.
The implementation contains 22 issue categories and four urgency levels. Categories include water supply, electricity, healthcare, roads, pensions, government documentation and appointment requests. An unrecognised category is mapped to an “other” category rather than silently becoming a new dashboard label.
| Priority | Meaning in the implemented taxonomy |
|---|---|
| P0 | Immediate danger to life or safety |
| P1 | Urgent concern needing rapid intervention |
| P2 | Ordinary grievance needing follow-up |
| P3 | Routine information, suggestion or request |
An angry caller does not automatically describe an emergency. Urgency should follow the substance of the concern. These labels support office triage; they do not turn the assistant into an emergency-dispatch service.
Department defaults can help organise the inbox, but a suggested department is not proof that the department received the complaint. Staff assignment, external forwarding and resolution need their own recorded events.
How the two outbound workflows differ
The reported engagements also cover rally invitations and updates about MLA work. These uses need different content and outcome definitions from incoming message-taking.
Rally invitations: accurate logistics and clear outcomes
For an invitation workflow, the office should approve the event name, date, time, location and relevant contact details. A versioned information sheet helps avoid one batch using an old venue while another uses a corrected address.
Technical reporting should separate a dial attempt, an answered call, delivery of the invitation and any response explicitly provided by the recipient. A connected call does not prove the invitation was understood. An affirmative response does not establish eventual attendance.
Retries should respect the agreed contact permissions, calling windows and stop requests. Repeatedly dialling the same number must not inflate a report into a claim about additional citizens reached. No attendance or conversion figures for these engagements are published here.
Work updates: distinguish each project's actual status
An update about an MLA's work needs an approved factual source. A project being proposed, sanctioned, started and completed represents four different states. The script should preserve the state and date provided by the office instead of converting progress into completion.
A useful content record includes the source document, approved wording, version date and owner of corrections. When a citizen asks something outside that material, the assistant should capture the question for follow-up rather than supply an unsupported answer.
The operational outcome is delivery of an accurate update and capture of any resulting request. It should be measured separately from whether the underlying public work is complete or whether recipients approve of it.
For the data model, Sarvam's campaign webhook specification distinguishes attempt identifiers, connectivity, completion and retry fields. Its distinction illustrates why an inbound-call record and an outbound-attempt ledger should not be treated as interchangeable. It does not verify which campaign configuration these clients use.
How much simultaneous-call capacity would this workload need?
This is a sizing example, not a production benchmark. Assume a separate scenario of 200,000 connected calls in 30 days, all occurring within eight active hours per day. The implied arrival rate is about 833 connected calls per hour, or 13.9 per minute.
Average simultaneous conversations are approximately the arrival rate multiplied by average call duration, using the same time units:
| Assumed average duration | Monthly conversation minutes | Average simultaneous conversations |
|---|---|---|
| 60 seconds | 200,000 | 13.9 |
| 120 seconds | 400,000 | 27.8 |
| 180 seconds | 600,000 | 41.7 |
At 120 seconds, the calculation is 833.3 calls per hour × 2 minutes ÷ 60 = 27.8 average occupied channels. That does not mean 28 channels are sufficient: arrivals vary, callers can speak longer, and telephone setup or ringing can consume additional resources.
For a further illustration, a three-times busier period would imply 83.3 concurrent conversations at the same duration. Dividing by an assumed 70% occupancy ceiling produces about 119.1, rounded up to 120 channels. Neither the peak factor nor that occupancy ceiling has been measured for these clients.
An actual capacity decision needs hourly arrivals, duration percentiles, ringing time, provider limits and an acceptable waiting or blocking rate. It also needs separate inbound and outbound controls so a scheduled batch cannot consume every resource required for incoming calls.
Why attempts, connections and minutes change the calculation
Now consider a different scenario: 200,000 outbound attempts, with an assumed average connected duration of 90 seconds. Changing the assumed connection rate gives very different conversation totals:
| Assumed connection rate | Connected calls | Connected conversation minutes |
|---|---|---|
| 30% | 60,000 | 90,000 |
| 50% | 100,000 | 150,000 |
| 70% | 140,000 | 210,000 |
Formula: attempts × connection rate × average connected seconds ÷ 60. These percentages are illustrative inputs, not AiSewak results. The reported 2 lakh figure cannot be assigned to this scenario until its counting definition is confirmed.
Even a provider's “completed” status needs a business definition. A call may finish technically after a recipient hangs up before the relevant message. An office should decide what evidence qualifies an invitation as delivered or an incoming message as usable.
The same care applies to unique contacts. Multiple attempts can reach the same phone, and several people can share one phone. Counting distinct numbers is a useful operational measure, but it is not verified identity or a census of individual citizens.
A transparent cost model for evaluating an MLA service
Without an agreed duration distribution and billing definition, a per-call price can conceal more than it explains. A quote should separate setup, telephony, voice processing, post-call analysis, storage, reporting and ongoing operational support.
Use the previous illustrative 150,000 connected-minute scenario to see sensitivity to price:
| Hypothetical effective rate | Connected-minute subtotal |
|---|---|
| ₹2 per minute | ₹3,00,000 |
| ₹4 per minute | ₹6,00,000 |
| ₹6 per minute | ₹9,00,000 |
These rates are arbitrary calculation inputs, not AiSewak pricing, supplier quotes or actual client expenditure. The subtotal excludes any separately billed setup, ringing, failed attempts, minimum billing increments, platform charges, taxes or human follow-up.
At 150,000 minutes, a ₹1 change in the effective per-minute rate changes that subtotal by ₹1,50,000. That sensitivity explains why buyers should compare a common workload and a complete scope rather than headline prices from differently packaged services.
For procurement, request two reconciliations: the invoice against provider usage, and usage against usable office outcomes. Cost per usable message is total relevant cost divided by accepted messages. It can reveal a poor-quality service even when cost per minute looks attractive.
Human follow-up remains a separate workload
Automation can capture contact while the MLA is unavailable. It cannot make the subsequent office work disappear. An unresolved pension issue, a meeting request and a routine appreciation message require different levels of staff attention.
In an illustrative staffing scenario, assume 200,000 connected calls, 5% requiring human follow-up, and four minutes of initial staff handling per flagged call. That yields:
- 10,000 follow-up items per month.
- 40,000 minutes, or approximately 667 staff hours.
- About 25.6 staff hours per day over 26 working days.
- Approximately 4.3 staff equivalents at six productive handling hours per day.
Those figures are workload equivalents, not a proposed headcount or measured labour saving. They exclude repeated follow-ups, coordination with departments, field visits and supervision. The actual inbound share and follow-up rate may be very different.
This calculation makes the handover design concrete. Every actionable message needs an owner, a status and a way to record what happened next. Otherwise, faster intake can create a larger unattended queue.
What the dashboard should count—and what it should not imply
AiSewak's reviewed reporting code computes totals from stored call records before generating a narrative brief. Calls, issues, urgent items, callback requests and meeting requests are separate counts. The language model helps narrate supplied information rather than serving as the calculator.
The daily brief can fall back to computed information if narrative generation fails. This preserves useful counts without treating generated prose as a prerequisite for office visibility.
An emerging-issue rule groups the same category and locality when at least three distinct caller keys occur within a rolling 24-hour window. Phone numbers supply the key when available; web calls can use their interaction identifiers. That is an alerting heuristic, not independently verified evidence of three different residents or a confirmed incident.
A practical evaluation scorecard should include the following denominators:
| Metric | Definition to agree |
|---|---|
| Connection rate | Connected outbound attempts ÷ total outbound attempts |
| Usable-message rate | Staff-accepted messages ÷ inbound conversations reviewed |
| Extraction success | Successfully analysed records ÷ eligible received records |
| Message accuracy | Correct reviewed fields ÷ reviewed fields |
| Follow-up completion | Closed eligible follow-ups ÷ follow-ups due in the period |
| Processing delay | Time from call end to record availability |
Report typical and slow-end delays, such as the median and 95th percentile. An average can hide a small group of callers whose records take much longer to reach staff.
Sentiment labels are model judgements about conversational tone. They should not be reported as verified satisfaction, voting intention or resolution. A polite ending does not prove that the caller's problem was fixed.
How to test quality before increasing volume
A convincing demonstration includes failures and ambiguous requests. Test poor audio, silence, interruptions, several concerns in one call, corrections to a location, requests for an unsupported promise and a caller who declines to provide optional information.
A useful illustrative acceptance set could contain 100 prepared calls across 10 scenarios, with 10 variations each. This is a proposed test design, not a test performed for the three clients. The variations should reflect the languages, pronunciation and background noise the office expects to encounter.
Evaluate the captured message against a human-reviewed reference. Score fields separately: name, location, issue, requested action and urgency. A system can transcribe most words correctly while getting the one landmark needed for follow-up wrong.
Keep rare but consequential errors visible. Ninety-nine correct messages and one invented commitment do not become acceptable merely because an aggregate accuracy figure is 99%. Severity and recoverability matter alongside the percentage.
Sampling also has limits. Under a simple model with independent calls and a constant 3% error probability, the chance of seeing zero errors in 100 calls is 0.97 raised to the power of 100, or about 4.8%. Zero observed failures therefore cannot establish zero risk. A constructed scenario set tests coverage; a random sample answers a different question about normal operating quality.
For ongoing operation, review a random sample alongside every processing failure and important escalation. Keep those groups separate in the report; deliberately oversampling difficult calls changes the meaning of the overall error rate.
Privacy, access and records that staff can trust
Citizen messages may contain sensitive personal circumstances. The office should define what it needs to collect, who can read the original transcript, which staff can access contact details, and when records should be removed.
The reviewed reporting components mask phone numbers in selected summary views. Masking a display does not anonymise the underlying stored record or establish access control across the whole service. Deployment review should test the permissions of each staff role and each office separately.
An effective operating checklist covers approved contact sources, clear assistant identification, recording notice where applicable, access review, deletion handling and incident escalation. These are deployment questions to settle with the office and its advisers, not a claim that this article certifies legal compliance.
Public case studies need a different data boundary from internal dashboards. Anonymisation here removes candidate, party, constituency and citizen identifiers. It also avoids publishing combinations of local events, dates and personal details that could reconstruct an individual's identity.
What an MLA office should request in a working demonstration
Ask to follow one complete interaction through the system. Call the agreed number while the MLA is unavailable, leave a message, correct one detail, and inspect the resulting office record. Check whether the correction survives into the summary and whether any unsupported fields were filled in.
Then repeat with a processing failure or controlled duplicate event. The questions become concrete: does the call remain visible, can staff see that analysis needs review, and does a retry create a second apparent citizen contact?
For outbound work, inspect the approved information version, attempt history and the difference between connection and business outcome. For reporting, reconcile a small set of known interactions against the dashboard totals. A buyer should be able to trace a count back to its records.
Agree the acceptance criteria before expanding: message quality, supported languages, routing behaviour, processing delay, staff ownership and billing reconciliation. Those criteria make a pilot useful even before a large monthly total exists.
Questions readers ask about this case study
Is the reported volume 2 lakh calls for each MLA?
No. Approximately 2 lakh calls per month is the combined figure across three MLA engagements. The equal-share calculations above are illustrations, not a disclosure of each client's actual usage.
Does the missed-call assistant call citizens back automatically?
The confirmed workflow answers when the MLA misses the original call and takes a message on the MLA's behalf. A request for a later callback is a separate item for the office; it should not be confused with this incoming-call workflow.
Which technical capabilities are verified here?
The implementation review confirms structured intake, saved call records, separate transcript extraction, validation, issue categories, review states and aggregate reporting components. It does not verify every client's live configuration, latency, availability or language performance.
Has the service demonstrated an electoral outcome?
This account reports ongoing communication work and approximate activity. It does not establish changes in voting behaviour, election results, rally attendance or grievance resolution. Those claims would require different evidence and a defined evaluation method.
How should another office assess whether AiSewak fits?
Start with the missed-call message your staff need to receive, then evaluate invitations and work updates separately. Request a telephone demonstration, inspect the record, agree the follow-up process and compare a quote using explicit volume and duration assumptions.
Explore the workflow for your office
The three engagements provide a concrete operating context: incoming message-taking and two outbound communication uses at an approximate combined monthly scale of 200,000 calls. The next useful step for another office is to examine a complete interaction and its record against that office's own requirements.
Explore AiSewak's AI voice agent for MLAs, read the 40-question MLA voice-agent FAQ, or compare approaches in the MLA voice-agent provider guide. To evaluate routing, reporting and an itemised service scope, contact AiSewak.
Evidence note: Engagement facts and approximate volume are reported by AiSewak. Technical details reflect an implementation review dated 4 November 2026. Tables explicitly labelled as calculations or scenarios are reproducible models, not historical customer measurements. No client logs, commercial invoices or outcome audit are published with this account.