The best KPI is one that tells you what’s about to happen, not just what already did. Most support dashboards are built from lagging numbers: last month’s resolution time, last quarter’s survey score. A leading indicator gives you a few days or weeks of warning, and the way to find one is to track the same thing the same way, every time, until a pattern shows up before the problem does.
On November 11, Google launched Flu Trends, and it’s the neatest illustration of that idea I’ve seen all year. ABC News reported that the service watches for unusual numbers of flu-related searches and publishes a map of where they’re rising. The claim is that it can spot flu activity up to two weeks faster than the traditional surveillance systems, which depend on doctors reporting cases after the fact. Nobody at Google is examining patients. They’re counting something people do before they see a doctor, and counting it consistently.
I’m not a public health expert and I won’t pretend to evaluate the science. What caught my attention, after my earlier piece on choosing the right KPI, is how directly it maps onto the problem of tracking KPIs in a support operation, which I covered in how to actually track your KPIs last year. Three of the lessons from that piece show up here, and a fourth, the warning label, matters most.
What is a leading indicator in a support team?
It’s a number that moves before the customer-facing outcome does. Ticket volume on a specific topic is the classic one. If contacts about a billing change start climbing on Monday, you can staff for the surge and brief the agents before the complaints and the churn arrive in the next survey. A lagging number like average resolution time would only tell you about it after the damage was done.
The doctors’ reports in the flu example are the lagging measure: accurate, authoritative and late. The search counts are the leading one: noisier and early. A well-run support operation wants both and knows which job each one does. The leading number says “look here today.” The lagging number says “here’s what really happened.”
Which numbers lead in your operation? Start by asking what happens before the thing you’re worried about. Before an outage ticket spike, there’s a rise in “is the service slow?” contacts. Before a renewal is lost, there’s a drop in how often the account contacts you, or a rise in repeat contacts about the same unsolved issue. None of these are in a vendor’s default report. You find them by writing down what came before the last three bad weeks.
Why does consistent capture matter more than the tool?
Because a leading indicator only works if the baseline is stable. Flu Trends can say that search volume is unusual only because it has a long record of what normal looks like, collected the same way. Change how you count, and every comparison to the past breaks.
I made the same point about first call resolution. Two teams can both report 78% and mean different things, because one counts calls with no follow-up inside 24 hours and the other counts anything closed on first contact. Both are valid definitions. Comparing them is not. If you’re going to use a number as an early warning, write the definition down, put it where everyone can see it, and don’t change it without announcing the break in the series.
A spreadsheet is enough to start. I’d rather see a team log the same six fields for every incident for three months than buy a new platform and capture different fields in each of its first three weeks. The habit comes first and the tool second. If you’re not sure how big your problem is, an Erlang C staffing calculation is a decent way to see how much volume your current capacity can actually absorb before service falls off.
What should you check before trusting an early signal?
Compare it against the slower, more reliable number. That’s the warning label, and it’s in the news coverage too. An epidemiologist quoted in the ABC piece cautioned that the system could be skewed by people searching for flu information who aren’t sick, by media coverage, and by the buzz around avian influenza, and said the results need to be compared with actual surveillance data. In other words, a spike in searches isn’t proof of a spike in flu.
That caveat applies to every leading indicator you’ll build. A jump in contacts about the billing change might mean the change is confusing. It might also mean a newsletter went out. Treat the early signal as a reason to look, not as a verdict, and check it against the lagging number as it arrives. If the early number keeps predicting the later one, it earns its place on the dashboard. If it doesn’t, drop it, however good it looked on the chart.
It’s the same discipline as watching the 90th percentile and not just the average. An average resolution time of two hours can hide a group of tickets that took eighteen. One summary number rarely tells you which problem you have, and that’s true of leading indicators as well. Look at the spread, not just the headline.
What does a leading indicator look like on a Monday morning?
Picture a support manager opening one page. It has four numbers: contacts by topic this week against the same week’s usual range, repeat contacts as a share of the total, the oldest unresolved customer-facing issue, and the number of open escalations with no update time. Nothing on it is fancy. Each number has a normal range written beside it, so the manager doesn’t have to remember what good looks like.
Two of those four are leading and two are lagging. The manager reads the leading pair first, because they say where to look, then the lagging pair, because they say whether the looking was justified. It takes five minutes. After a quarter, you’ll know which of the four has been earning its keep and which has been decoration.
I’d keep one more habit from the Flu Trends example: publish the thing. The reason the service is useful is that anybody can look at the map. An early-warning number that lives in one analyst’s spreadsheet protects nobody. Put it where the team leads see it, and ask them what they’d do differently when it moves. The answers are usually better than the model.
How do you build one without a data science team?
Keep it small. Pick one outcome you care about, such as customer-reported outages or contacts that turn into escalations. Look back over the last quarter and list what you can count that happened one to two weeks earlier. Plot the two against each other by hand. If a pattern is visible to the naked eye, you have a candidate. If you need a statistician to find it, it probably isn’t strong enough to run a team on.
Then write down the action it triggers. A leading indicator with no agreed response is just a more interesting chart. “When contacts on this topic pass this level, we brief the team and add cover the next morning” is a decision. “We’ll keep an eye on it” is not.
Review it weekly, in ten minutes, with the same people. A tracker nobody reads until the quarterly business review is data that happened to get saved. A short weekly look is how the patterns show up: the same vendor causing three of your last five outages, or a number that has been quietly slipping for a month. For benchmarks on what a reasonable range looks like, the team at HDI publishes support-centre research you can measure yourself against.
It’s also worth being honest about what you won’t get. A leading indicator buys you days, not certainty. You still need people who can read the number and judge whether it means anything, and you still need to own the decision to act on a signal that might be wrong. That judgment is the part no dashboard supplies.
One last test before you promote a number to leading status: ask whether it would have warned you last time. Take the last incident that hurt, go back two weeks, and see whether the number moved. If it did, and it also moved for the incident before that, you have something. If it moved only once, you have a story, and stories are cheap. The test costs an afternoon and saves you from building a response plan around a coincidence.
Be patient with the first version, too. Expect to revise what you capture as you learn what the number is telling you. That’s the process working as intended, not a sign the idea was wrong. The groups that get real value from this treat their first indicator as a draft, and correct it against what customers actually do.
Counting early is cheap. Knowing what the count means is the job.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
