A missed WhatsApp message is an inbound chat that reached your business number and never got a human or automated reply. On most Indian WhatsApp Business API accounts they are not rare — they sit in the 3-12% range of all inbound, they are invisible in the chat list once they scroll past the first screen, and every one of them is a lead or a grievance that decided you were not answering.
This is an operations problem with a billing tail. The 24-hour customer service window closes on a missed message the same way it closes on an answered one, so a chat you ignore on Monday cannot be answered for free on Wednesday — it needs an approved template and it costs money. Below is how to find missed messages in your own data, what each recovery route costs, and the structural fixes that stop the leak instead of mopping it.
What actually counts as a missed message
Teams argue about this because the definition decides the number. The workable rule on the WhatsApp Business API is: an inbound message on a conversation where no outbound message followed it before the 24-hour service window expired. Three clarifications matter, and each one changes the count materially.
First, an automated greeting is not an answer. If your bot replies "Thanks, our team will contact you shortly" and no human ever does, the conversation is missed — it just looks answered in a naive query. Second, a blank-body outbound counts as nothing; some auto-reply setups write an empty message row, which satisfies a SQL check and satisfies no customer. Third, a message answered at hour 23 is not missed, but it is close enough to failure that it belongs in the same report.
The honest metric is therefore two numbers, not one: never-answered (no outbound at all) and answered-after-window (outbound exists, but after the free window shut). The first is lost revenue. The second is revenue you paid extra to chase.
Why messages go missed: five failure modes
In practice the causes cluster. Across Indian API accounts the same five patterns account for nearly all of it, and they need different fixes — which is why a single "hire more agents" answer rarely moves the number.
| Failure mode | What it looks like | Typical share | Fix that works |
|---|---|---|---|
| After-hours arrival | Inbound lands 21:00-09:00 IST or on a holiday; nobody is rostered | Largest single bucket on consumer-facing numbers | Away message with a real promise + a morning queue that starts at the oldest unanswered chat |
| Bot dead-end | Flow reaches a step with no fallback path; customer replies into silence | Common wherever a chatbot has more than ~10 nodes | Wire a no-match branch on every decision node and route it to a human |
| Shared-number ambiguity | Several agents see the chat, each assumes another took it | Rises sharply above 3 agents on one number | Explicit assignment, not visibility — see the shared WhatsApp team inbox model |
| Volume spikes | A campaign or an ad burst delivers more inbound in an hour than a day's capacity | Episodic, but produces the worst single-day numbers | Stagger sends; pre-stage a template for overflow instead of silence |
| Wrong-number and spam noise | Genuinely irrelevant inbound buried in the same list | Highly variable; ad-driven numbers see the most | Classify and exclude, so the real missed count is not hidden inside junk |
Note the shape of that list: only one of the five is a staffing problem. The other four are configuration, process and data problems, and all four are cheaper to fix.
Find them: the query that actually works
The mistake almost everyone makes is starting from the messages table. On a multi-tenant WhatsApp platform the message rows usually carry no business identity of their own — they hang off a conversation. Start from the conversation, scoped to your business number, then look at its messages. Starting the other way round either returns another tenant's data or silently returns nothing.
The logic, in plain terms, is:
- Take every conversation on your phone number ID with at least one inbound message in the reporting period.
- For each, find the newest inbound timestamp.
- Check whether any outbound message exists with a later timestamp, and whether its body is non-empty.
- Bucket the result: answered inside 24h, answered after 24h, never answered.
- Subtract classified junk, and report the remainder by arrival hour.
The arrival-hour breakdown is the part people skip and the part that pays. It converts a vague "we miss some chats" into "we miss 61% of what arrives between 22:00 and 07:00", which is a roster decision, not a culture problem. If your platform exposes a conversations export, this is a spreadsheet pivot; if you are on the raw API, it is one query and a script.
The 24-hour window decides your recovery route
Once a message is missed, the age of the last inbound dictates what you are permitted to send and what it costs. This is the single most important table in the article, because the same customer costs different money depending on when you get to them.
| Age of last inbound | What you may send | Cost on Client Pay | Cost on SaaS Pay |
|---|---|---|---|
| Under 24 hours | Free-form reply, any content | ₹0.10 per message + ₹0.20 if the service window opens | ₹0.10 per message + ₹0.20 if the service window opens |
| Over 24 hours, utility intent (order, booking, ticket) | Approved utility template only | ₹0.10 platform + Meta's utility rate (₹0.115 in India) | ₹0.30 all-in |
| Over 24 hours, promotional intent | Approved marketing template only | ₹0.10 platform + Meta's marketing rate (₹0.8631 in India) | ₹1.20 all-in |
| No prior inbound at all | Marketing template, and only with a valid opt-in on record | As above, plus real risk if consent is thin | As above, plus real risk if consent is thin |
Two readings follow. The obvious one: answering inside the window is roughly an order of magnitude cheaper than recovering outside it, which turns response speed into a line item rather than a nicety. The less obvious one: a utility-intent recovery is cheap enough to run at scale, while a marketing-intent recovery is not — so classify your missed messages by intent before you decide how many to chase. Our 24-hour window cost optimisation breakdown goes into the window mechanics in detail. Current rates for both models are on the WhatsApp API pricing page.
Get a 1-minute BSP audit on WhatsApp
Drop your WhatsApp number — we line-item your current invoice against Meta India rates in under 60 seconds. India-hosted, DPDP-compliant.
Recovering a missed lead after the window has closed
The template you use for recovery is not the template you use for marketing. It has one job: reopen a service window by getting a reply, so that the actual conversation happens free-form. That argues for a short, specific, slightly apologetic message that references what the person asked about, and offers a binary next step.
What works, in structure rather than wording: acknowledge the gap without excuses, restate their question so they know it was read, give one concrete piece of information, and ask a question that can be answered with one word. What fails: generic "we missed you" blasts, discount bait unrelated to the original query, and any message that needs a second message to make sense.
Get the template approved before you need it. A recovery template submitted on the morning you discover a 400-message backlog will not be approved in time to be useful, and the natural response — sending an existing marketing template instead — is exactly the behaviour that damages quality rating.
Cap the attempt at one message per person. A second unanswered recovery template is not persistence; it is the pattern that produces blocks, and block rate is what drives WhatsApp quality rating recovery work you would rather not be doing. Nobody can promise that bulk re-pinging avoids restrictions — the safe assumption is that it does not.
After-hours and holiday backlog: the structural fix
If the arrival-hour report says most misses happen when nobody is working, the fix is a sequence, not a person.
Start with an away message that makes a promise you can keep. "We are closed, we will reply by 10:30 AM" outperforms "we will get back to you soon" because it sets a clock the customer can wait against, and it is trivially checkable the next morning. Vague promises produce a second impatient inbound at 2 AM, which inflates your volume without adding information. The mechanics of setting this up are covered in our WhatsApp auto-reply setup walkthrough.
Then make the morning queue start at the oldest unanswered chat rather than the newest inbound. Default chat lists sort by recency, which means the 11 PM enquiry gets answered before the 9 PM one, and the 9 PM one quietly ages past 24 hours. This single ordering change typically recovers more conversations than adding an agent.
For Indian holiday calendars, pre-approve a dated away template a week ahead. Diwali, regional new years and long weekends produce the year's worst backlogs precisely because the volume is high and the roster is thin, and a template submitted during the holiday is a template approved after it.
Measure it: first-response time, honestly
Three numbers are enough, and all three should be reported by arrival hour, not as daily averages. Daily averages hide the exact failure you are hunting.
| Metric | Definition | What a healthy Indian support number looks like |
|---|---|---|
| Never-answered rate | Inbound conversations with no non-empty outbound, ever | Low single digits; above 10% means a structural break, not a busy week |
| Median first-response time | Inbound to first human or meaningful automated reply, business hours only | Minutes, not hours — sales enquiries decay fast and WhatsApp raises the expectation further |
| Post-window recovery share | Answered conversations where the first reply landed after 24 hours | Should trend to near zero; every point of it is template spend you did not need |
Two reporting cautions. Exclude classified junk before computing any of these, or a spam wave will look like an operational improvement when it is cleaned. And reconstruct the numbers from stored message records rather than from a live dashboard, so the figures are auditable months later — the same record set that answers who sent which WhatsApp message also answers who did not reply to which one.
What not to do
Four tempting moves make the problem worse.
Do not bulk-blast every missed contact from the last six months. Old missed messages are cold and the marketing-rate spend is real, but the bigger cost is the block rate a cold blast produces, which follows your number into every future campaign.
Do not manufacture urgency in a recovery template. A fabricated deadline in a message the customer already knows you ignored converts poorly and reports well — as spam.
Do not count the automated greeting as the reply in your own reporting. It is the fastest way to a dashboard that shows 99% answered while your enquiries quietly go elsewhere.
Do not solve it by adding a second number. Splitting inbound across numbers without splitting ownership produces the shared-number ambiguity failure twice over, and now with two quality ratings to maintain.
A 30-day plan that actually closes the gap
Week one: measure only. Produce the never-answered count, the post-window count, and the arrival-hour breakdown, with junk excluded. Resist fixing anything until the shape is on paper — the fix that matters is rarely the one the team assumes.
Week two: submit a recovery utility template and a dated away-message template, and wire a no-match fallback on every bot decision node. These are the two changes with a lead time, so they go first.
Week three: change the queue ordering to oldest-unanswered-first and assign explicit ownership on the shared number. Re-run the measurement at the end of the week against the same definition.
Week four: run one controlled recovery pass over never-answered conversations from the last 30 days only, utility intent first, one message per person, and measure reply rate by age bucket. That reply-rate curve tells you how far back a recovery pass is worth running — for most Indian accounts it falls off a cliff somewhere between 14 and 30 days, and paying marketing rates past that point is not a recovery, it is a donation.
The number worth watching at the end is not the recovery reply rate. It is the never-answered rate on new inbound, because that is the one that compounds.