A promo code stops working at midnight. A carrier misses a pickup. A website update hides the cancellation button. Each of these creates a wave of calls, and customers are telling you about it from the first hour. In most contact centers, though, the problem reaches the people who can fix it days later, through a weekly report, an escalation from a team lead or a post on social media.
The data to catch it sooner is already in your calls. What is usually missing is a way to tell a real change from the normal ups and downs, and a clear path from an alert to a person who can act. This guide covers both.
Why calls show a problem first
Dashboards for sales, orders and tickets lag behind the customer. A customer who cannot apply a discount code calls right away. A customer whose parcel is late calls when the promised date passes. Calls are also the one place where the customer says what is wrong in their own words, so you learn not just that something changed but what.
That only works if you look at the content of calls, not just their count. A rise in call volume tells you that something happened. A rise in calls about “promo code not working” tells you what, and who to wake up.
Start with a baseline
You cannot call something a spike without knowing what normal looks like. A useful baseline has three parts:
- The unit. Count calls by topic or by phrase, not just by queue. “Delivery status” is a better unit than “all calls”.
- The rhythm. Compare Monday with previous Mondays, not with Sunday. Most contact centers have strong weekly and daily patterns, plus effects from paydays, holidays and campaigns.
- The spread. Even a calm topic varies from day to day. The baseline should include how much it normally varies, so a change is measured against that, not against an average that never moves.
Two or three months of history is enough to start. If you have less, say so and use wider thresholds until the baseline settles.
Spike or noise?
Take an illustration. A topic normally gets about 40 calls on a weekday, give or take 8. Today it has 52. Is that a spike? Probably not: it is within what happens on a busy day. If it has 90, almost certainly yes. The hard cases are in between, and getting them wrong has a cost either way: too many false alarms and people stop reading alerts, too few and you are back to hearing about problems from customers on social media.
Some practical rules that keep alerts honest:
- Compare to the same weekday and hour, not to the last hour or the weekly average.
- Require a minimum count. Going from 1 call to 3 is a tripling and is also meaningless. Set a floor under which nothing fires.
- Account for calendar effects. A campaign launch, a holiday or a price change explains a rise. Keep a shared calendar of business events so an alert can say “this coincides with Tuesday's promotion email”.
- Watch many topics, then correct for it. If you test 60 topics every day, a few will look unusual by chance. Use a method that controls for testing many things at once, or raise the bar as the number of watches grows.
- Look for persistence. Two consecutive periods above the line is stronger than one, at the price of a slower alert. Choose per watch: a checkout failure warrants a fast alert on a single period, a slow-building trend does not.
What to alert on
You do not need hundreds of watches. A handful of well-chosen ones covers most real incidents:
| Watch | Example | Typical owner |
|---|---|---|
| Keyword or phrase | “promo code”, “coupon”, “discount” appearing far more than usual | Marketing, e-commerce ops |
| Topic volume | Delivery-status calls above their weekday baseline | Logistics, carrier manager |
| Call outcome | Share of calls ending unresolved or needing follow-up | Support lead |
| Customer experience | Complaints or threats to leave rising for one topic | CX director |
| Possible product defect | Several calls describing the same failure after an update | Product, engineering |
| A specific question | “Did the customer say they could not complete checkout?” | Web team |
The last row is the most powerful and the one to treat most carefully. A custom question catches things no keyword list anticipates. It also needs checking, which is the subject of a later section.
Avoid watches about how agents feel or behave emotionally. They are unreliable, and an alert system that points at people instead of problems loses the agents' trust quickly.
Who gets the alert
An alert nobody owns is just a notification. Decide before you turn a watch on:
- One owner per watch, with a named backup. “Delivery” goes to the carrier manager, not to a shared mailbox.
- The right channel. Urgent items to email or SMS, or into your own tools through a signed webhook. Routine ones to an in-app list or a daily digest.
- Quiet hours. A spike at 3 a.m. that can wait until 8 should wait until 8.
- A short alert. The topic, the size of the change against baseline, a few example quotes with links to play the moments, and whether it matches a known business event.
- A closing action. Acknowledged, fixed, false alarm. Closed alerts are your best data for tuning thresholds later.
Test a watch before go-live
Every new watch should be tested on history before it can wake anyone up. The test is straightforward:
- Replay it on past calls, including a week where you know something went wrong. Did it fire, and how early?
- Read what it matched. For a keyword, check the hits are the thing you meant. For a question, have two people answer it blind on a sample of calls, then compare with the system's answers.
- Count the false alarms over a calm stretch. If a watch would have fired five times last month and four were noise, tighten it.
- Get a second person to approve before it goes live, especially for watches that notify someone outside the contact center.
VoiceVera builds this into question watches: a watch is tested by blind review and approved by an administrator before it can notify anyone. Whatever tool you use, keep the habit.
Keep it from rotting
Review the watches every month. Retire the ones that never fire. Tighten the ones that fire too often. Add one for each real incident you learned about too late: after the postmortem for a missed problem, ask which watch would have caught it, and create it.
When the data covers every call rather than a sample, rare early signals have a chance to appear, and the same logic works for churn signals: a risk list is a slow alert, a spike alert is a fast one. For e-commerce teams, the e-commerce solution page shows how contact reasons, defects and refunds feed this loop.
A starting checklist
- List your five most expensive past incidents and what customers said during each.
- Turn each into one watch with an owner, a floor and a channel.
- Keep a calendar of campaigns, releases and policy changes where your team can see it.
- Test each watch on history and on a calm week before it goes live.
- Review the false alarms and misses together every month.
Hear about the problem before the report does
In the free pilot we set up a few watches on your own call topics and show you what they would have caught.