The typical situation
Hostel fees, deadlines, eligibility, scholarships: the same few hundred questions, asked thousands of times a season, by phone, email and WhatsApp.
Institutions in this position worry about two things: the assistant saying something untrue, and the assistant saying something unflattering about a competing institution.
What the data looked like
Brochures, fee schedules, FAQ pages, policy documents and a season of past queries used only to test coverage. No student personal data is used to train anything.
What we built
- A retrieval-grounded assistant that answers only from approved documents and declines everything else, including comparisons with other institutions.
- A guardrail test suite of adversarial questions, run before every content update, with the report shared with the institution.
- Cost routing: a small model for routine answers, a larger one for the few complex cases, and caching for repeats.
- WhatsApp and web deployment with a review log sampled weekly by the admissions office.
Typical outcome
| Measure | Before | After | Period |
|---|---|---|---|
| Routine queries resolved without staff | 0% | ~70% | typical, first season |
| Cost per conversation | staff time | a few rupees | typical, first season |
What usually trips these projects up
This pattern works only when a named person on the institution's side owns the document set. Where that owner is missing, the assistant drifts out of date within a term.