Containment rate is the share of support sessions your WhatsApp bot closes without a human ever touching them — bot-resolved sessions divided by bot-opened sessions — and cost per resolution is what each closed ticket costs you end to end. In India in 2026 the bot side of a support ticket lands near ₹1–₹2 because Meta does not charge for user-initiated service conversations, while a human-handled ticket sits in a ₹20–₹45 band once you load the agent's salary. This article gives you the exact formulas, the funnel instrumentation that stops the usual mis-counts, directional benchmark bands by vertical, and a cost-per-resolution model you can rebuild with your own numbers.
Containment, deflection and resolution are three different numbers
Most vendor dashboards print one number and call it all three. That is how support heads end up defending a "78% automation rate" that the CFO can pick apart in four minutes. Define them separately, in this order.
- Deflection rate = (inbound support contacts − contacts that became a human ticket) ÷ inbound support contacts. It counts everything that did not reach an agent, including people who gave up. It is the most flattering and least trustworthy of the three.
- Containment rate = bot-closed sessions ÷ bot-opened sessions. Narrower and honest: only sessions the bot actually engaged, only sessions the bot actually closed. Abandoned sessions belong in neither the numerator nor a "contained" bucket.
- Resolution rate = sessions where the user's stated intent was satisfied ÷ sessions closed. It is a quality measure, not a routing measure, and it applies to bot and agent sessions alike.
The number worth putting in a board deck is the intersection of the last two. Effective containment = (bot-closed sessions not reopened within 72 hours) ÷ bot-opened sessions. A bot that "contains" 70% but has 20% of those threads reopened inside three days is really running 56% — and every reopen also spent an agent's time, so the cost model has to charge the ticket twice.
Instrument four states, not one flag
You cannot compute any of the above from a boolean. Log four timestamped states per session and derive everything else.
The four states
- bot-opened — an inbound message started an automated session. Timestamp, intent classified, entry point (ad click, QR, saved contact, IVR deflect).
- bot-resolved — the bot reached a terminal node and the user confirmed. Confirmation is the load-bearing part: an implicit close after silence is not a resolution.
- handed-off — routed to a human, with a reason code (low confidence, out-of-scope intent, user asked, policy rule, sentiment trigger).
- reopened — the same contact returns on the same intent inside a defined window. Seventy-two hours is a reasonable default for e-commerce and services; use your own repeat-contact distribution to pick it.
The four mis-counts that inflate every deck
- Abandonment counted as containment. The user opened a session, got a menu, and left. No human touched it, so a naive query calls it contained. Give it its own state and report it — abandonment above roughly 15% of opened sessions is a menu-design problem, not a win.
- Reopens counted as contained. The first session closed clean, so it scores. The follow-up two days later opens a fresh session and scores again. Both count, the ticket was never solved, and the cost model reports a saving that never happened. Deduplicate by contact plus intent.
- Post-resolution handoff counted as failure. The bot solved the refund question and the user then asked something unrelated. That is one contained session plus one new session, not a failed handoff.
- Multi-session tickets counted as multiple resolutions. One customer problem that spans three WhatsApp sessions is one resolution. Cost per resolution divides by problems solved, not by threads opened.
If your session model and your ticket model disagree on what a "ticket" is, fix that before you build any economics on top of it. The same discipline underpins response and resolution targets — see our WhatsApp customer service SLA playbook for Indian support teams for the timing side of the same instrumentation.
India benchmark bands by vertical (directional)
The bands below are directional planning ranges drawn from how these intent mixes typically behave on WhatsApp in India, not published research and not a survey. Verify every one of them against your own baseline before you commit to a target. Two teams in the same vertical can be twenty points apart purely on catalogue complexity and backend API availability.
| Vertical | Top automatable intents | Directional effective containment | What caps the ceiling |
|---|---|---|---|
| D2C / e-commerce | Order status, returns, exchange, COD confirm | 55–75% | Exceptions: damaged, partial, courier disputes |
| Logistics / courier | Tracking, reschedule, address change | 60–80% | Address edits needing hub confirmation |
| BFSI / lending | EMI date, statement, KYC status, balance | 40–60% | Regulated advice, dispute handling, hard auth |
| Healthcare / clinics | Booking, reschedule, reports, directions | 50–65% | Clinical questions must never be automated |
| Edtech | Batch timing, fees, access issues, syllabus | 45–65% | Refund policy and counselling conversations |
| Travel / ticketing | PNR status, cancellation rules, e-ticket resend | 50–70% | Date-change pricing, group and partial cancels |
| Real estate / broking | Site visit booking, availability, documents | 30–45% | Negotiation-heavy; most value is qualification |
Read these as "where a well-built deployment tends to settle after 60–90 days of tuning", not as a first-month expectation. Month one usually runs 15–25 points lower while intent coverage is still thin.
The bot side: why service conversations change the arithmetic
The economics of WhatsApp support in 2026 rest on one fact: user-initiated service conversations are free on Meta's side. A customer messages you about an order, your bot handles the whole thread, and Meta charges nothing for that conversation. Marketing, utility and authentication templates are the billed categories — and inbound support does not need them.
On RichAutomate that leaves usage-only pricing with ₹0 setup and ₹0 monthly. Two ways to pay:
- Client Pay — you connect your own Meta account and pay ₹0.10 per message as the platform fee, with Meta billing you directly for whatever it charges (nothing, for service threads).
- SaaS Pay — ₹1.20 per marketing and ₹0.30 per utility, Meta's cost included. Relevant only when you proactively template out; a purely inbound support thread does not touch these rates.
So a contained support session is not "cheap automation" — it is close to a rounding error. A twelve-message contained thread on Client Pay costs ₹1.20 in platform fees and ₹0 in Meta conversation charges. Our detailed breakdown of WhatsApp AI agent and chatbot pricing in India walks through the per-category maths if you need to model proactive sends too.
Get a 1-minute BSP audit on WhatsApp
Drop your WhatsApp number — we line-item your current invoice against Meta India rates in under 60 seconds. India-hosted, DPDP-compliant.
The agent side: assumptions you must replace
There is no honest published number for "cost per ticket" in Indian support, so build it yourself from four inputs. The values below are illustrative assumptions, not benchmarks — swap in your payroll and workforce numbers before showing this to anyone.
- Assumption: tier-2 city chat-support agent CTC ₹18,000–₹30,000 per month.
- Assumption: loading factor 1.35–1.5× for supervision, tooling, seat, attrition and training.
- Assumption: 22 productive days per month, 45–65 concurrent-chat tickets handled per agent per day.
- Assumption: 8–12% shrinkage already netted out of that ticket count.
Take the midpoint: ₹24,000 CTC × 1.4 = ₹33,600 loaded, over 22 days = ₹1,527 per day, over 55 tickets = ≈₹27.80 per agent-handled ticket. Move any one input and the answer moves a lot — which is exactly why the assumption table has to be visible in the business case rather than buried.
Cost per resolution, side by side
| Line item | Bot-contained session | Agent-handled ticket |
|---|---|---|
| Meta service conversation (user-initiated) | ₹0 | ₹0 |
| Platform message fee, Client Pay ₹0.10/msg | ₹1.20 (≈12 msgs) | ₹1.80 (≈18 msgs) |
| Human handling time (assumption above) | ₹0 | ₹27.80 |
| Setup fee | ₹0 | ₹0 |
| Monthly licence | ₹0 | ₹0 |
| Cost per resolution | ≈₹1.20 | ≈₹29.60 |
Blended cost per resolution = (contained × ₹1.20 + human-handled × ₹29.60) ÷ total resolutions. At 10,000 support sessions a month and 55% effective containment that is roughly ₹14.00 blended, against ₹29.60 at zero automation. Two CFO-grade caveats: reopened tickets must be charged at the sum of both paths, and the saving is capacity released, not cash out the door, unless headcount or overtime actually changes. Say that out loud before finance says it for you.
Escalation design that buys containment points without tanking CSAT
Containment bought by hiding the exit is containment you pay back in CSAT and in angry public reviews. These levers move the number the honest way. Deltas are directional and additive only up to a point — measure each one behind a holdout.
| Design lever | Directional containment delta | CSAT risk |
|---|---|---|
| Confirm-before-close ("Did that solve it?" with Yes / Still need help) | +2 to +4 pts | Low — also fixes reopen mis-counts |
| One-tap "Talk to a human" visible on every node, never hidden | −1 to +3 pts | Lowers risk; raises trust and completion |
| Deflect into a Flow form instead of an FAQ link | +3 to +6 pts | Low — keeps the user inside WhatsApp |
| Scoped fallbacks (re-ask within intent, not a generic menu dump) | +2 to +5 pts | Low if capped at two retries |
| Backend API for order/booking status instead of a canned reply | +5 to +12 pts | Very low — biggest single lever |
| Queue-time transparency before handoff ("agents reply in ~7 min") | +1 to +3 pts | Low if the estimate is honest |
Three anti-patterns to ban outright: burying the human exit behind three taps, looping "I didn't understand" more than twice, and answering a specific account question with a generic help-centre link. Each raises measured containment and destroys the resolution rate underneath it. The handoff mechanics themselves — context passing, reason codes, agent-side queueing — are covered in our guide to WhatsApp bot-to-human handoff design, and if an LLM is doing the answering you also need a scored regression set, which our WhatsApp AI agent evaluation framework lays out.
Transcript analytics on de-identified data under the DPDP Act 2023
Every number in this article comes from reading conversations. Under India's Digital Personal Data Protection Act, 2023 — with rules being operationalised in phases, so confirm current obligations with counsel — that reading is itself processing of personal data and needs to be designed, not assumed. Practical carve-out for an analytics pipeline:
- Purpose limitation. "Support quality and volume analytics" is a stated purpose. It does not silently extend to remarketing off the same transcripts. If you want to market from support data, that is a separate purpose and a separate notice.
- De-identify at ingest, not at query time. Phone numbers become a salted hash, names, addresses, order IDs, card fragments, UPI handles and IDs are redacted by pattern before the row lands in the warehouse. The analyst never sees raw identifiers because they were never written.
- No raw PII in the analytics warehouse. Keep the identified copy in the operational store with real access control; keep the analytics store on de-identified text plus structured labels (intent, outcome, handoff reason, sentiment bucket).
- Retention. Set a retention period per store and enforce it with a job, not a policy document. Aggregates can outlive transcripts — keep the monthly containment number, drop the message bodies.
- Erasure requests must reach the analytics copy. If a Data Principal asks for deletion, the hashed key has to be resolvable enough to delete their rows, or the pipeline has to be genuinely anonymous. Decide which, and document it.
- Vendors are processors. Any third-party LLM, transcription or BI tool touching transcripts belongs in your processing register with a contract behind it.
Done properly this costs a sprint and removes the single most common reason support analytics projects get frozen by legal review.
Putting the business case on one page
Support heads lose this argument by leading with the automation rate. Lead with the money instead, in this order: current blended cost per resolution, current volume and its growth curve, effective containment today, target containment with named levers, and the resulting blended cost per resolution — then the capacity or cost outcome, honestly framed. Attach the assumption table and the definitions from section one so nobody can relitigate the arithmetic later.
Refresh the model monthly against actuals rather than annually against hope. Three things drift fastest: message counts per contained session, ticket mix as new intents arrive, and abandonment as menus grow. If you also run proactive campaigns off the same number, keep those metrics in a separate ledger — our WhatsApp campaign KPIs and metrics guide covers that side so outbound performance never gets blended into support economics.
Build the model on real numbers
You can instrument the four states, run the containment maths and pay nothing but usage while you prove it. RichAutomate is usage-only — ₹0 setup, ₹0 monthly, Client Pay at ₹0.10 per message on your own Meta account, or SaaS Pay at ₹1.20 marketing and ₹0.30 utility — and inbound service conversations stay free on Meta's side, which is the whole reason the bot column in that cost table is a rounding error. Create a free RichAutomate account, connect your WhatsApp number, and pull your first real containment and cost-per-resolution baseline out of your own traffic instead of someone else's benchmark table.