Compliance · 5 min read
Government Services on WhatsApp: The Constraints Come First
We do not ship WhatsApp, and we do not sell to government. This post exists because the question keeps arriving and because the sector inverts almost every assumption in ordinary automation advice.
The inversion is simple. A customer who dislikes your automated reply can go elsewhere. A citizen cannot. That single fact makes convenience a weaker argument and correctness a much stronger one, and it should change what gets built.
What changes when the user has no alternative
Three things, and none of them is a technicality.
A wrong answer is not a lost sale. It is somebody missing a deadline, arriving at the wrong office, or bringing the wrong documents to an appointment they waited weeks for. The cost of a confident error is paid by the person least able to absorb it.
Access is not evenly distributed. Any channel-only service excludes whoever does not have the app, the data, the literacy, or the phone. A messaging channel can be an option; making it the only one is a policy decision with consequences.
Records are subject to rules that marketing tools were not built for. Retention, access requests, audit trails, and who inside the organisation may read a conversation.
Every design question in this sector reduces to the same one: what happens to the person for whom this goes wrong?
The narrow safe band
Safe to automate
Never
The left column is genuinely valuable and enormously repetitive — the same handful of questions arriving thousands of times, each currently costing somebody a phone call or a journey. Answering those instantly is a real public good.
The right column is not a matter of caution. It is that a messaging tool has no access to a case management system, so any answer it gives about an individual is a guess dressed as an official reply.
The record-keeping question
Two obligations that ordinary tools handle badly.
Retention with a defensible reason. A conversation held indefinitely because nobody chose a period is the commonest finding in any review. The period should be written down before the channel opens, not derived afterwards.
Who read what. Named accounts, not a shared login, and a log of which member of staff opened which conversation. This is the requirement that most messaging tools fail outright, and it is worth asking about first rather than last. The privacy inventory post sets out what a channel like this generates, and the DPDP post covers the Indian obligations in more detail.
What good looks like
- Answer facts, route everything else. A short list of automated answers, and an explicit handover for anything outside it — with the handover being to a real queue, not a promise.
- Say what it is in the first message. "This is an automated service that can answer general questions" costs one line and prevents the misunderstanding that causes the harm.
- Publish the alternative in the same breath. A phone number and an address, every time, for the people this channel does not serve.
- Never let it answer at 3am about something urgent. Quiet hours, and an honest "we are closed, here is what to do meanwhile" instead.
Language is not an optional extra here
The requirement that separates a public service from a commercial one.
A business can decide to serve customers who write in English. A public body cannot, and in India that means a citizen may reasonably write in any of several languages, in either script, mixed with English, in a single sentence.
This has a practical consequence for keyword matching that catches people out. Matching on a Devanagari word will miss the same word typed in Latin letters, which is how a large share of people actually type. A rule list built in one script quietly serves a fraction of the population and looks like it is working, because the people it misses do not write back to complain — they give up and telephone, which is the cost the channel was meant to remove.
The fix is unglamorous: every trigger list gets its transliterations, and the handover path has to be good enough that the misses land somewhere useful.
The parallel on the channel we do run
PostEngage answers Instagram comments and DMs for creators and small businesses. It is not a public-sector product and we would not recommend it as one.
The transferable part is the architecture rather than the product: every outbound message passes one gate, ten checks run in a fixed order, and a refusal is recorded with the sentence explaining it rather than as a failure code.
That property — being able to say afterwards exactly what was sent, what was not, and why — is the one a public body should insist on from any vendor, whatever the channel.
Where to read more
For the compliance shape underneath all of this, the DPDP post is the closest fit, and the GDPR post covers the European version. For consent, which is a different question again, start here.
