Early warning signals in WhatsApp support metrics: reference table
What an early warning signal is (and what it isn't)
An early warning signal is a movement in a metric that appears before the customer notices the problem. It is not the same as an outcome indicator: an already-high first response time is an outcome, not a signal. The signal is the variation that anticipates that outcome: the queue that grew two days in a row, the proportion of conversations a single agent is handling, the drop in the percentage of suggested replies that are approved without editing.
The difference matters because outcome metrics are looked at when there are already complaints. Signals are looked at beforehand. This page does not replace indicator dashboards: it uses them as a source and adds the anticipation layer. If you don't yet have your base indicators defined, this table won't help you: first establish what you measure and with what formula.
The thresholds in this table are relative to your own business's baseline, not absolute. A business with 30 conversations per day and one with 3,000 don't share numbers: they share the shape of the signal. Each team sets its own trigger after two or three weeks of measuring.
The table: signal, what to check, and in what order
Each row is a signal that can be seen in the data before the customer feels it. The "what to check" column goes in order: you look at the first thing before moving on to the second, because the cause is almost always in the first link. The "evidence" column is what you write down so that the review doesn't depend on the memory of whoever did it.
| Signal (what moves) | What to check first | What to check next | Evidence to save |
|---|---|---|---|
| The queue of unassigned conversations grows two days in a row | How many conversations came in per hour in each time slot, using Meta's timestamp, not the date they were loaded into the system | Whether the growth coincides with an active campaign or a schedule change | Screenshot of the count per time slot, two days before and two days after |
| The proportion of conversations a single agent handles simultaneously goes up | The load distribution per agent during the peak time slot | Whether there are connected agents who aren't receiving assignments (misconfigured distribution rule) | Table of active conversations per agent, hour by hour |
| The percentage of AI suggestions approved without editing goes down | The topics of the conversations where the most editing happens | Whether the change coincides with a new product, price, or promotion the AI hasn't seen yet | List of the 20 most-edited conversations and the topic of each one |
| The proportion of conversations closed without an outbound reply increases | Whether those conversations had any inbound message after the last outbound one | Whether the closure was automatic due to schedule or manual by the agent | Count of closures by type (automatic / manual) and their reason |
| The gap between the first inbound message and the first outbound reply stretches in a specific time slot | What happened in that time slot: drop in connected agents, spike in incoming volume, or both | Whether the spike coincides with a scheduled campaign send | Chart of incoming volume and replies in the same time slot |
| The number of conversations reopened after being closed grows | The declared or inferred reason for the reopening | Whether the previous closure was premature (without resolving the inquiry) | Sample of 10 reopenings with the last message before closure |
| The time between the agent's first and second reply in the same conversation goes up | Whether the agent is alternating between many conversations at once | Whether internal information is missing to reply (price, stock, availability) | Time between successive replies per agent, median and not average |
| Message volume concentrates in a time slot with no assigned coverage | The actual incoming time, measured with Meta's timestamp | Whether the schedule-based auto-reply is active and what it says | Count of incoming messages per hour outside coverage hours |
| The number of conversations left untagged when closed increases | Whether the team is using tags or abandoned them due to friction | Whether the available tags cover the real reasons for inquiries | Count of closed conversations with and without tags, per agent |
| The number of conversations handled per agent per day goes down without incoming volume dropping | Whether there was a shift change, leave, or turnover | Whether the team is resolving longer inquiries (different mix of topics) | Comparison of conversations handled and messages sent per agent |
| The number of messages sent per conversation spikes | Whether the team is repeating information that should be in a template | Whether there are inquiries that require back-and-forth due to missing data in the first message | Median messages per conversation, before and after the change |
| Conversations appear with more than one agent replying to the same thread | Whether automatic assignment is overriding manual assignments | Whether there are agents entering outside the assigned inbox | List of conversations with two or more agents and the timestamp of each intervention |
How to read the table without drowning in data
Twelve signals is too many to look at every day. The table is ordered by severity, not by ease of measurement. The first four are the ones that anticipate a capacity problem: if the team can't keep up, they show up before any complaint. The four in the middle anticipate a process problem: the team can keep up but something in the flow is poorly set up. The last four anticipate a quality or configuration problem.
The operational recommendation is to pick three signals per week, not twelve. You look at those three every day at the same time, write down the value and compare it against the baseline. The following week you rotate. In a month and a half the team already has the full picture without having set up a new dashboard.
- Week 1: unassigned queue, load per agent, edited suggestions.
- Week 2: closures without a reply, delay in a specific time slot, reopenings.
- Week 3: time between replies, inbound outside coverage, conversations without a tag.
- Week 4: conversations per agent, messages per conversation, two agents in one thread.
If the team measures using the date it was loaded into the system instead of the Meta timestamp, the time-based signals (peak slot, inbound outside hours, delay per slot) will give you anything. That data has to be taken from the timestamp that Meta sends, which is the only one that reflects when the message actually happened.
What to do when a signal fires
- 1Confirm that the signal is real and not an artifact: check whether there was a configuration change, a history import or a campaign that explains the movement.
- 2Isolate the scope: is it the whole operation or a time slot, an agent, a topic? Most signals fire in a subset, not in the total.
- 3Look for the cause in the first link of the chain, not the last. If the queue grew, the cause is usually in assignment or in inbound, not in the agent's speed.
- 4Decide whether to fix it now or monitor it. Not every signal requires immediate action: some settle on their own when the campaign or the seasonal peak ends.
- 5Write down what was done and what happened afterward. Without that record, the next time the same signal appears you start from scratch.
- 6If the signal persists after fixing the first link, escalate. Platform or channel configuration problems depend on each case and resolution time varies: there is no guaranteed deadline.
Common mistakes when monitoring signals
The most common mistake is looking at averages. An average first response time of four minutes can hide a two-hour slot where nobody replied and a bunch of instant replies that compensate. Attention signals are read with medians and with breakdowns by time slot, not with the daily average. The median tells you what happened to the typical customer; the average tells you what happened in the system.
The second mistake is looking only at what the customer can see. If the team responds quickly but closes conversations without resolving them, the time metric looks good and the reopen rate spikes. Early signals live at the intersection of two metrics, not in a single one. The table is built this way on purpose: each row crosses a movement with the data point that explains it.
- Looking at the average instead of the median and the breakdown by time slot.
- Confusing a campaign with a capacity problem: a campaign spike is not a signal, it is a planned event.
- Measuring time slots using the date uploaded to the system instead of the Meta timestamp.
- Reviewing a signal on its own instead of crossing it with the metric that explains it.
- Fixing the last link (asking the agent to respond faster) when the cause is in the first one (assignment or intake).
- Not writing down the evidence: without a record, the review cannot be repeated or compared.
How often each signal is reviewed
Not all signals are reviewed with the same frequency. Capacity signals (queue, load, delay) are reviewed daily because they deteriorate quickly. Process signals (reopens, closes without response, double agent) are reviewed twice a week: a single day of anomaly says nothing. Quality signals (edited suggestions, messages per conversation, labels) are reviewed weekly, because they are the ones that take the longest to show a real change.
| Signal group | Review frequency | Comparison window | Who reviews it |
|---|---|---|---|
| Capacity (queue, load, delay, intake outside coverage) | Daily, at the same time | Last 7 days versus the previous 7 | Shift lead or supervisor |
| Process (reopens, closes without response, double agent, time between responses) | Twice a week | Last 2 weeks versus the previous 2 | Support supervisor |
| Quality (edited suggestions, messages per conversation, labels, conversations per agent) | Weekly | Last 4 weeks versus the previous 4 | Supervisor or operations lead |
The frequency is an operational recommendation, not a technical requirement. Adjust it to the volume of the business: with few conversations per day, reviewing daily adds nothing.
How to know that monitoring works
Signal monitoring works when the team detects the problem before the customer does. The concrete test is simple: count how many times in the month the problem was detected by a signal and how many times by a complaint or a claim. If the proportion moves toward signals, the system is working. If everything is detected by complaint, the table is being reviewed too late or the wrong signals are being reviewed.
The second test is repeatability: if two different people review the same signals and reach similar conclusions, the review is well defined. If each one interprets it differently, the threshold and the evidence still need to be set. The evidence column in the table exists for exactly that.
The third test is the workload that monitoring generates. If reviewing the signals takes more time than handling the conversations, the system is oversized. Three signals per week, reviewed at the same time, are enough to start. Add more once the first three are already part of the team's rhythm.
Tools like Wando show message and campaign statistics inside the same inbox where the team replies, which avoids jumping between systems to review signals. It does not replace the criteria for what to look at: that is defined by the team.
Template for logging the review
A review without a log is useless for comparing. This minimal template is enough so that anyone on the team can pick up the review where the previous person left off. One row is filled in per signal reviewed.
| Date | Signal reviewed | Today's value | Baseline | Did it trigger? | What was reviewed | What was decided |
|---|---|---|---|---|---|---|
| (date) | (signal name) | (number) | (number from the last 2 weeks) | Yes / No | (first and second link reviewed) | (fix now / monitor / escalate) |
Four rows are enough for a week of reviewing three signals. The baseline column is filled in once and updated every month.
When to escalate and when not to
Not every triggered signal requires escalation. Capacity signals are almost always resolved within the team: reassigning shifts, adjusting the distribution rule, enabling an auto-reply by schedule. Process signals too: correcting the closing criteria, reviewing the manual assignment. Quality signals may require reviewing the material the AI uses to suggest responses, which means updating the business information.
You escalate when the signal persists after correcting the first link, when it affects the entire operation and not a subset, or when there is a platform or channel configuration that the team cannot touch. In those cases, the resolution time varies depending on the case: there is no deadline that can be promised in advance. What you can do is document what was reviewed, what was ruled out and since when, so that whoever takes the case does not start from scratch.
- Do not escalate for a signal that appears for a single day and resolves on its own.
- Do not escalate without having reviewed the first link in the chain.
- Escalate when the signal affects the entire operation and persists for more than a week.
- Escalate when the cause is in a configuration that the team does not manage.
- Always document what was reviewed before escalating.
Frequently asked questions
How many signals should be monitored at once?+
Three per week. The full table has twelve, but watching all of them every day takes more time than it saves. They rotate week by week until the whole picture is covered in a month and a half.
Are the thresholds in the table fixed?+
No. They are relative to each business's baseline. A business with 30 daily conversations and one with 3,000 do not share numbers: they share the shape of the signal. Each team sets its own trigger after two or three weeks of measuring.
Why does the table ask to measure with the Meta timestamp and not with the date the record was loaded into the system?+
Because the load date reflects when the record was inserted, not when the message happened. If the history was imported all at once, that date concentrates everything at the same moment and any time-of-day analysis gives a false result. The Meta timestamp is the only one that reflects the real moment of the message.
What is the difference between an alert signal and a support indicator?+
The indicator measures a result: how long the team took, how many conversations it closed. The signal is the movement that anticipates that result before the customer notices it. Signals are watched before; indicators, after.
When should a triggered signal be escalated?+
When it persists after fixing the first link, when it affects the whole operation and not a subset, or when the cause is in a configuration the team does not manage. Resolution time varies by case and there is no guaranteed timeframe.
Can this be monitored without a new dashboard?+
Yes. The signals are calculated from data the support inbox already records. What is needed is to log them with a minimal template and review them at the same time, not to set up a new tool.
What happens if the team does not use labels?+
The unlabeled conversations signal cannot be read. In that case it is worth first checking whether the available labels cover the real reasons for contact: if they do not, the team abandons them due to friction and the signal loses meaning.
How often is the baseline updated?+
Once a month, or when something structural in the business changes: hours, number of agents, incoming volume or mix of topics. If the baseline gets old, all the signals appear to be triggered.
Answer WhatsApp with AI
Try Wando free. No credit card required.