The first of every month, before I open my email, I spend about 45 minutes running a support health check. Same routine. Same five numbers. One question I always ask at the end.
It took me longer than I would like to admit to build this habit. Early in my support career I checked metrics when something felt wrong, which meant I was almost always reacting. By the time a number looked bad, the underlying problem had usually been building for weeks. The shift was simple: move from reactive to rhythmic. Same day, same review, every single month.
Here is the full routine.
The Five Numbers I Pull First
Not everything. Five specific numbers, pulled in the same order every time.
First contact resolution (FCR): the percentage of tickets resolved in a single interaction, no follow-up required. For most support teams, a healthy FCR sits somewhere above roughly 70%, though what is healthy depends heavily on product complexity. I am not looking at the absolute number in isolation. I am looking for movement: did it go up or down compared to last month, and do I have an honest reason for the direction?
CSAT score (or equivalent net satisfaction metric): the month's customer satisfaction average from whatever survey tool is in place, whether that is Help Scout's built-in rating, a Zendesk CSAT workflow, or a third-party survey. Again, not the number in isolation, but the trend. A drop of a few points in a single month is noise. The same drop two months in a row is a pattern worth investigating.
Average first response time: how long from ticket creation to the first agent reply. I flag anything that slipped more than roughly 20% from the previous month. Response time is the metric customers notice most immediately, before resolution, before quality, before anything else.
Escalation rate: what percentage of tickets got bumped to a higher tier. A rising escalation rate usually means one of three things: the team is overwhelmed, tier-1 coverage for a specific topic is thin, or something changed in the product that introduced new complexity.
Backlog age at month close: how many open tickets are older than five days, or whatever your SLA window is. Old backlog compounds: tickets age, context goes stale, customers grow frustrated, resolutions get harder. I want this number small and trending toward zero.
That is it for quantitative. Five numbers, roughly 15 minutes to pull if the tooling is reasonable. I have run this review in Help Scout's reports tab, in Zendesk Explore, and in a shared spreadsheet with manually updated columns. The tool matters less than the habit.
The Qualitative Pass (This Is Where the Real Insight Lives)
After the numbers, I read. Not every ticket, but a deliberate sample.
Specifically: tickets that were tagged as escalated, tickets with the lowest customer satisfaction ratings, and any ticket category whose volume grew by more than roughly a quarter compared to the previous month.
What I am looking for in this read is the thing the numbers cannot show. A 10-point drop in CSAT is a fact. The reason for it is a story. Maybe it is a single product change that introduced a confusing step. Maybe it is a triage gap where customers received an automated acknowledgement but the human follow-up they expected never arrived within the expected window. Maybe it is one agent whose tone turned short during a stressful stretch and whose low ratings pulled the team average down.
The qualitative pass usually takes about 20 minutes and almost always surfaces one thing I would have missed looking only at the dashboard.
What to Share With the Team, and How
I do not dump the monthly numbers on the team and move on. That approach kills engagement fast. What I share instead is three things.
One metric that improved, with credit to the person or practice that drove it. If FCR went up because an agent spent time refining the canned response library, I say that explicitly and name them. Public credit for specific contributions is inexpensive and disproportionately effective at reinforcing the behaviours you want to see more of.
One metric that moved in the wrong direction, stated plainly. "Our average first response time crept up by about a third this month" rather than "there were some response time challenges this month." The team can handle honesty. They cannot handle vagueness that makes them suspect things are worse than they are being told.
The one thing we are going to work on this month. Not four things. One.
The One-Fix Rule
In my first couple of years running these reviews, I would identify five problems and commit to fixing all five. By month end we had made partial progress on none of them, because the team's attention was spread too thin.
Now I pick the single highest-impact change and the team puts its weight behind it. By month end it is almost always done. One completed improvement does more for morale and operational health than five things each 40% underway. People leave the review knowing exactly what to do differently this month, not with a list of everything that went wrong.
What Goes to Leadership
The monthly health check is also where I prepare a one-paragraph summary for whoever owns support in leadership. Not a data dump. One paragraph, four sentences.
Where we are (the headline metric this month). What moved and why, one thing up and one thing down, each with a plain-language reason. What we are fixing this month. Any resource or process decision needed to make that fix happen.
Leadership does not need to know everything that happened in support this month. They need to know whether support is a growing problem, a stable one, or an improving one, and whether there is anything that requires their decision. A clean four-sentence summary answers those questions in under a minute, and it builds trust that support is being led with intention.
The Question I Always End With
After pulling numbers, reading tickets, preparing the team share, and choosing the one fix, I ask myself one question: if this team had to handle 50% more ticket volume next month with the same headcount, where would it break first?
That question forces a structural view of the operation rather than a performance review of the past month. The answer is usually one of a handful of things: the escalation path, the tier-1 knowledge base, the onboarding process for new agents, or a manual triage step that nobody has automated yet.
I do not always act on the answer immediately. But I write it down. Over time, the pattern in those notes becomes a roadmap. The things that keep appearing as the structural weak point become the next investment, whether that is tooling, documentation, headcount, or a process redesign.
The Monthly Review Is About Building, Not Catching
How the review is framed matters as much as what is in it. A health check that feels like surveillance will make agents reluctant to handle anything that might look bad on a report. It will surface less honest information and create a culture where people manage to the metric rather than to the customer.
The monthly review I run is not about catching mistakes. It is about catching systemic problems before they compound, and about making sure the team knows what is working as clearly as they know what is not. Done with that intent, most people find the review useful rather than stressful, because it reliably produces one concrete improvement each month and communicates that the operation is being led with intention.
Thirty to 45 minutes. First of the month. Five numbers, a qualitative read, one fix, one leadership paragraph, one structural question.
That is the whole routine.
If you run a support or ops team and want to compare notes on how you approach the monthly review, drop me a line.
Comments