Maharshi Nahar

A WhatsApp bot that answers the questions the office was getting dozens of times a day, mostly from parents. When it needs a real person it hands the conversation over with the earlier messages attached, so the parent isn’t asked to explain again.

Once an admin resolves a conversation, the system drafts an answer for that kind of question and sends it back to the admin for approval before it uses it. Something like “here is how I would answer this next time, is that right?” Nothing gets into its knowledge base without someone saying yes, which was the only way I was comfortable letting it learn on its own.

• Human in the loop: every escalation becomes training data, but an admin approves each learned answer over WhatsApp before it goes live.
• Answers come from a fixed knowledge base. If there is no source for something, it escalates rather than making an answer up.
• Certain questions always go to a human no matter how confident the model is. Some answers are not the bot’s to give.
• Tested against real questions: I built a test set from actual parent messages and re-ran it whenever the knowledge base changed.
• Failures logged in production and used to fix the knowledge base and the routing rules.
• Rate limiting per sender, so one number cannot flood the bot or run up the API bill.
• Conversation state is stored, so a thread survives hours of silence.

The college uses this to send notices, announcements and automated reports to staff, parents and students. Messages are addressed by department and by role, so something meant for one group does not land in everyone’s inbox. Attendance for 1,000+ students a day feeds into it directly instead of being typed in again.

• Sends run in the background rather than on the request, and the page polls for progress.
• Queued dispatch with backoff, so a bulk run survives the gateway’s rate limits.
• Delivery state per recipient, so failures can be retried without resending to everyone.
• Phone numbers are read from the stored record, never from the submitted form.

Tracking for college equipment and supplies: what exists, where it is, who has it and what condition it is in. Products, purchase lots, bills and issue records, with an audit trail so the history is still there after the staff who entered it have moved on.

• Bills store the scanned image along with paid and verified state, and the dashboard flags anything unpaid or unverified. Only admins can mark something verified.
• Images are compressed in the browser before upload and served view only.
• Pooled stock for consumables adjusts by the difference when a record is edited, and cannot go negative.
• Uploads are stored outside the deploy folder. The auto deploy rebuilds that directory and had already wiped uploaded files once before I moved them.

Smaller modules that take care of the repetitive office tasks eating up people’s afternoons, plus the shared pieces the rest of the system sits on.

• Role based access control with grants per module, per template and per database, rather than one admin flag that either opens everything or nothing.
• Sessions limited to one device at a time, with an idle timeout.
• CSRF protection on every request that changes data, including multipart uploads, where the parsing order means the token has to travel somewhere else.
• Schema migrations that can be run repeatedly, checked against the catalog before a table is altered.