Playbooks · 5 min read
The Support Inbox: What Automation Should Actually Take
Support automation is usually sold as deflection — the share of messages a human never has to touch. It is the wrong number to optimise, and optimising it produces the experience everybody complains about: a wall of menus between a person with a problem and a person who could solve it.
The better framing is boring and it holds up. A support inbox is a queue. Some of what is in it is the same question asked repeatedly, in slightly different words, and answering it is transcription rather than judgement. The rest needs a person. Automation's job is to empty the first pile so the second one gets the attention it always deserved.
Count before you build anything
Nobody can tell you what share of your inbox is repetitive. Not a vendor, not a benchmark, not this post. It varies enormously between a clinic and a courier and a coaching class, and the only way to know is to read.
Take a week of inbound messages. For each one write down the thing the person wanted, in your own words, and then group. Almost every business finds a small number of wants covering a large share of the file — and finds at least one they did not know was common, usually something procedural that a broken page on the website is generating.
That grouped list, not a feature comparison, is the specification for what to build.
Three tiers, and the boundary is the product
Tier one: answerable from a fact that does not change. Timings. Address and how to find it. Whether you deliver to a pincode. Fee for a fixed service. Policy on returns. These are strings. They do not require a lookup, they are the same for everyone, and a template answers them correctly every time. Automate all of them, and use fixed text rather than generated text, because there is nothing here worth paraphrasing.
Tier two: answerable from a lookup your system can do. Order status, appointment time, whether a document was received. These require the automation to hold a fact about that specific person, which means the automation is only as truthful as the system behind it — and it must never state something the system did not record. Order status has a whole post on exactly where that line sits.
Tier three: needs a person. Complaints. Exceptions. Anything about money that has already moved. Anything medical or legal. Anything angry. Anything that arrived as a photograph, because nothing reads images on any channel and a photo-only message gives a rule nothing to match on.
The interesting design work is entirely in the boundary between tiers two and three, and the safe default is to push a doubtful case up rather than down.
The two messages nobody writes on purpose
The fallback. When nothing matches, something gets sent, and it is usually the most-sent message in the entire deployment. Most tools default it to an apology that says nothing. Write it yourself. It should say what the automation can do, and how to get a person, in that order, in two sentences.
The out-of-hours reply. A message at 11:40pm gets an automated answer, and the honest one is enormously valuable: here is what I can tell you now, and a person is here from nine. What is not valuable is a cheerful reply that implies somebody is awake and reading.
Say it is a machine. Customers forgive a bot that is useful and remember a bot that pretended to be Priya from support.
Takeover is the check that makes any of this survivable
The single most important behaviour in a support automation is what happens when a colleague opens the thread and types.
The automation must stand down — in that conversation, immediately, without anyone toggling anything. If it does not, the inevitable outcome is a customer receiving a carefully written human apology followed by a template about business hours. That one sequence undoes more goodwill than a hundred correct automated answers earn.
In our Instagram product takeover runs early in the gate, before the window and rate checks, precisely because it must win over everything downstream of it. Whatever tool you evaluate for this channel, ask how it behaves in that moment and do not accept a vague answer.
When more than one person is answering
Two agents replying in the same thread is the classic small-team failure, and it happens within a week of the second person joining. The fixes are procedural rather than technical: one owner per conversation, a visible signal that somebody has it, and a rule about what happens at shift change. Multi-agent inboxes deserve their own read because the mechanics differ by tool.
What to measure instead of deflection
- Time to first useful reply. Not first reply — useful. An instant acknowledgement that answers nothing is not a response time.
- How often the fallback fired. A rising fallback rate means the world changed and your keyword lists did not.
- Handovers per day, and whether they were picked up. A handover into an unwatched queue is a dropped customer with extra steps.
- The new questions. Read the ones nothing matched, every week. This is where next month's automation comes from.
Where this stands today
PostEngage does not ship WhatsApp. It answers Instagram comments and DMs, with an inbox, takeover, and a record of everything sent and everything refused. Templated replies are free and unlimited; a credit is spent only when the AI writes new text. The free tier is 100 credits, no card, and packs start at ₹499.
For the analysis that tells you what to automate first, map the journey from real messages. For always-on expectations and what they actually cost a small team, this is the honest version.
