Skip to content
Illustrative blueprint · AI Chatbot

Illustrative blueprint: How a 11-centre coaching institute auto-resolved 70%+ of WhatsApp queries with an AI chatbot.

An illustrative planning scenario showing the shape and economics of a typical Big Helpers AI chatbot build — RAG over real documents, Hindi + English, with strict guardrails so it never invents discounts.

17+ years building softwarePvt Ltd · CIN U72200MP2008PTC021190Code you own · No vendor lock-inWhatsApp accessibleIndia-first INR pricing

Illustrative blueprint: This page is a planning scenario, not a named client engagement or an independently verified result. Names, figures, timelines and outcomes below are assumptions that show how we would scope and reason about a project of this shape.

Modelled starting situation

An education and coaching institute with 11 centres across two North Indian states was processing roughly 1,400 WhatsApp queries per day across admission enquiries, fee status, batch timing, exam result lookups, and refund questions. A 6-person support team worked split shifts including weekends. Median response time to a parent's WhatsApp message was about 4 hours during the day and 14 hours overnight. Parents complained on Google reviews. The institute had previously bought a no-code WhatsApp chatbot which answered course details correctly but invented a 20% scholarship that didn't exist — leading to about 40 angry parents at one centre demanding the discount they had been promised by the bot.

The business problem

Three problems compounded: (1) volume was rising faster than the institute could hire support staff trained on the institute's specific course catalogue and policies; (2) the previous bot's hallucination had eroded trust to the point where the institute's owner banned chatbots internally — but the support load made some form of automation unavoidable; (3) parents typed in mixed Hindi-English (Hinglish), often as voice notes, and English-only systems failed at the first message. Any new system had to handle Hinglish + voice notes, refuse to discuss anything outside the official course catalogue and fee policy, and hand over cleanly to a human when needed.

Run a support team? Get a free 1-page chatbot scope.

Send us 50 of your typical customer messages and a link to your FAQ or policy doc. We send back a 1-page sketch of what the bot would handle, what it would escalate, and what it would cost. No sales call required.

The system we would design

We built a custom RAG-backed WhatsApp chatbot in 7 weeks. We indexed 380 pages of the institute's official course catalogue, fee structure, refund policy, batch schedules, and exam-pattern documents into a Postgres pgvector index. The bot was built on Anthropic Claude Sonnet via API, with a strict system prompt that limited responses to indexed-document content. Function calls were added for fee-status lookup (against the institute's existing ERP), batch-timing lookup, and exam-result lookup by enrolment number. Voice notes were transcribed via Sarvam-Hi-ASR (better Hindi than Whisper at the time of build). Languages: Hindi + English with full Hinglish handling. Two strict guardrails: (a) any response containing a price, discount, or commitment was passed through a final safety classifier; (b) a one-tap human-handover button was always visible in the conversation. WhatsApp delivery via AiSensy (Meta-approved BSP). DPDP-compliant: explicit opt-in capture for marketing messages, easy unsubscribe, conversation retention capped at 90 days.

Features delivered

  • RAG over 380 pages of official course catalogue, fee policy, refund policy, batch schedule
  • WhatsApp Business API via AiSensy (Meta Cloud-API based)
  • Multilingual: Hindi + English + full Hinglish handling
  • Voice-note transcription via Sarvam-Hi-ASR (Hindi-tuned)
  • Function calling: fee-status lookup, batch-timing lookup, exam-result lookup
  • Strict guardrails: bot refuses to discuss discounts or admissions criteria not in source documents
  • Final safety classifier on any response containing price / discount / commitment
  • One-tap human-handover button always visible
  • Live owner dashboard: volume, top intents, escalation rate, language mix, CSAT
  • DPDP-compliant: explicit opt-in for marketing, 90-day conversation retention, audit log

Expected measurable outcomes

~72%
Of queries auto-resolved end-to-end
<30s
Median response time (vs 4 hr)
7 wk
From kickoff to live
₹2.8L
One-time build cost
₹38K
Monthly LLM + WhatsApp cost
~480
Staff-hours/month freed for outbound counselling

Within 60 days of launch, the bot was handling roughly 72% of total inbound WhatsApp queries end-to-end. Median response time dropped from about 4 hours to under 30 seconds. The 6-person support team was reassigned to outbound counselling calls — a higher-value activity — without layoffs. Hallucination incidents dropped to zero in the first 90 days because the bot was strictly RAG-bound and the safety classifier blocked any unverified price commitment. Estimated monthly running cost: about ₹38,000 (LLM ₹22K + WhatsApp messaging ₹12K + hosting ₹4K). Estimated saved support hours: roughly 480 staff-hours per month, equivalent to 3 full-time support agents at the institute's local salary scale. Payback on the ₹2.8 lakh build was inside 5 months.

What we learned

  • RAG is non-negotiable for any business chatbot — without it, the model invents prices and policies; with it, the model becomes a documentation interface that customers can ask questions to
  • A safety classifier on price/discount/commitment responses is the single highest-ROI guardrail — it turned a previously banned chatbot category into something the owner now defends internally
  • Hinglish + voice notes are the Indian default, not the edge case — any chatbot that doesn't handle both will fail at the first message in a real customer base
  • Owner of the business has to use the bot themselves before launch — the institute owner spent 90 minutes asking the bot questions like a parent would, which surfaced 11 issues no test script caught
  • Don't try to automate everything — the 28% of queries that go to a human are the high-value ones (refund disputes, complex admission cases, parent escalations); freeing the team to handle those well is the real win
  • DPDP opt-in capture and unsubscribe must be in the bot itself, not a separate page — parents will complain to the consumer forum if marketing messages keep coming after they ask the bot to stop

Frequently asked questions

Is this an actual client?

No. This is an illustrative planning scenario, not a report of one identified client engagement or an independently verified outcome. The workflow, scope, cost ranges and outcome ranges are planning assumptions that show how we would approach a project of this shape.

Can this be done for a smaller business — say a single coaching centre?

Illustrative planning note: Yes. Single-centre or single-product builds drop to ₹80K-1.4L because the document corpus is smaller and there's only one ERP to integrate. The economics still work as long as you have at least 100-200 queries per day; below that, a tuned canned-reply WhatsApp Business app may be cheaper.

What if the bot's answer is wrong — who is liable?

Illustrative planning note: That's exactly why the safety classifier and the hard refusal-to-go-out-of-scope rules matter. The bot is contractually a Data Processor, not a decision maker; it cannot grant discounts, scholarships, or refunds. Any commitment is escalated to a human and logged. We documented this in the institute's terms of use page that parents see at first contact.

Why Claude over GPT-4o or Gemini for this build?

Illustrative planning note: In our internal testing at the time, Claude Sonnet handled Hinglish refusal-with-empathy better than GPT-4o, and was more reliable at staying inside RAG documents. The institute's owner could test both and chose Claude. The architecture is LLM-agnostic — switching to a future model is a config change, not a rebuild.

How do you handle peak load — exam-result release day?

Illustrative planning note: Asynchronous architecture, queued message processing, and pre-warmed connection pool. We load-tested at 5,000 concurrent conversations before go-live. On the actual exam-result day in cycle 1, the bot handled about 11,000 queries in a 4-hour window without any human escalation backlog.

What about DPDP for the parent's data — phone numbers, enrolment IDs?

Illustrative planning note: Explicit opt-in capture before any non-transactional message. Conversations stored on the institute's own AWS account in ap-south-1. 90-day retention by default, configurable. Parents can request deletion via a documented endpoint. We signed a DPDP-aligned data processing agreement with the institute, and the institute did the same with parents in their privacy notice.

Related Big Helpers services

Ready to build your AI support channel?

Talk to a senior engineer in 24 hours — no juniors, no sales reps, no jargon. Just a clear scope, an honest estimate, and a build plan.