Home/Blog/Spike alerts
How-to · 6 min read

Call center spike alerts: catch a new problem within a day

A broken promo code or a late carrier shows up in your calls long before it shows up in a report. Here is how to hear it the same day without drowning in false alarms.

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:

  1. Compare to the same weekday and hour, not to the last hour or the weekly average.
  2. Require a minimum count. Going from 1 call to 3 is a tripling and is also meaningless. Set a floor under which nothing fires.
  3. 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”.
  4. 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.
  5. 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.
The unit of an alert is a sentence, not a number“Delivery calls are well above normal” starts an argument. “Delivery calls are well above normal, and here are five customers saying the carrier never came” starts a fix.

What to alert on

You do not need hundreds of watches. A handful of well-chosen ones covers most real incidents:

WatchExampleTypical owner
Keyword or phrase“promo code”, “coupon”, “discount” appearing far more than usualMarketing, e-commerce ops
Topic volumeDelivery-status calls above their weekday baselineLogistics, carrier manager
Call outcomeShare of calls ending unresolved or needing follow-upSupport lead
Customer experienceComplaints or threats to leave rising for one topicCX director
Possible product defectSeveral calls describing the same failure after an updateProduct, 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:

  1. Replay it on past calls, including a week where you know something went wrong. Did it fire, and how early?
  2. 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.
  3. Count the false alarms over a calm stretch. If a watch would have fired five times last month and four were noise, tighten it.
  4. 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.
Daily trends of calls by topic and outcome.
VoiceVeraDaily trends by topic, computed from every call. Data: AppTek Call-Center Dialogues, CC BY-SA 4.0, role-played calls.