Most support teams measure far more than they ever report, and report far more than leadership ever reads. The weekly update goes out as a screenshot of a dashboard — twelve tiles, every one a number with no context — and lands in an inbox where a busy executive glances at it, fails to find the one thing they care about, and quietly stops opening it. The data is all there. The meaning is not. A good support report is not a data dump; it is a short argument, in plain language, about whether the support operation is healthy and what, if anything, needs a decision.

Know who you are writing for

The mistake underneath most bad reports is writing for yourself. You live in the queue, so handle time and reopen rate feel urgent and obvious. Your CEO does not live in the queue. They are holding ten other functions in their head and they need three things from support, fast: is the customer experience getting better or worse, is the cost of delivering it under control, and is anything on fire that I need to act on this week. Everything you put in the report should earn its place against one of those three questions. A metric that does not help an executive answer one of them is a metric for your dashboard, not for their report.

Lead with the answer, not the data

A report that opens with a table makes the reader do your job. Open instead with a single sentence that states the verdict, the way a doctor leads with the diagnosis before the lab values. "Support held steady this week: response times are within target and volume is flat, with one emerging issue around billing emails that we are watching." Now the executive knows the headline in five seconds and can choose how deep to go. The numbers come after the sentence, as evidence for the claim — not before it, as a puzzle the reader has to solve.

Choose a tiny set of numbers, and explain each one

Resist the urge to show everything you track. A leadership report that earns its read usually carries four or five numbers, no more, each tied to a question the executive actually has:

  • Volume and its direction. How many tickets came in, and is that up or down? This is the demand signal, and it frames everything else — rising volume with steady response times is a very different story than the same response times on falling volume.
  • One speed number, against target. Usually first response time or time to resolution, shown as actual-versus-target, not as a raw figure. "4.2 hours against a 6-hour target" tells a story; "4.2 hours" alone does not.
  • One satisfaction number. CSAT or customer effort score — the human read on whether customers are leaving happy, with last week beside it so the trend is visible.
  • One cost or capacity signal. Tickets per customer, or backlog size, or whatever tells leadership whether support is scaling efficiently or quietly drowning. This is where a looming staffing decision first becomes visible.

The discipline is subtraction. Every number you cut makes the ones that remain louder. If you cannot say why a metric belongs in a leadership report, it belongs on your team dashboard instead, alongside the rest of the metrics that matter operationally.

Show the trend, not the snapshot

A single week is noise. A number means almost nothing without its own history beside it, because leadership cannot tell whether 4.2 hours is good news or a slow-motion crisis unless they can see where it came from. Wherever you can, show the last several weeks as a small trend rather than a lone figure. Three months of CSAT drifting down by a point a week is a far more important story than this week being 91 — and it is a story you can only tell with the line, not the dot. The job of the report is to surface direction early, while a gentle slope is still cheap to correct, instead of waiting for the number to become a crisis nobody saw coming.

Translate every metric into a consequence

The single thing that separates a report leadership acts on from one they ignore is translation: turning each number into a sentence about the business. "Reopen rate rose to 14%" is data. "Reopen rate rose to 14%, which means roughly one in seven solved tickets is coming back — customers are getting answers that do not actually fix their problem, and it is inflating our real workload" is a finding a leader can do something with. Do this especially for the worrying numbers. Pair the metric with what it implies and, where you can, what you propose to do about it — a rising reopen rate might point at a knowledge gap, a buggy feature, or a macro that closes too eagerly, and naming the likely cause turns the report from a complaint into a plan.

Name what needs a decision

A report that only describes is a report that drifts. The most valuable section is often the shortest: the one or two things where you need leadership to do something — approve a hire, prioritize an engineering fix that is driving a third of your volume, or accept a temporary dip in response time during a migration. Make these explicit and specific. "We need a decision on X by Friday" gets acted on; "support is busy" gets sympathized with and forgotten. This is also where support quietly earns its seat at the table — by surfacing the product and engineering problems that the rest of the company cannot see from where they sit.

Keep it short enough to be read on a phone

The best support report is one an executive can absorb in the elevator. If it runs to three screens, it will be saved for later and read never. A tight structure — one-sentence verdict, four or five numbers with their trends, the findings that matter, the decisions you need — fits comfortably on a single screen and respects the reader's time. Length is not thoroughness; it is the enemy of getting read. You can always link out to the full dashboard for anyone who wants to dig.

The honest test

Your support report is working when leadership starts quoting it back to you — when the verdict sentence shows up in a board deck, when someone asks about the trend you flagged two weeks ago, when a decision you requested actually gets made. If instead your weekly update vanishes into inboxes without a single reply, the problem is almost never that you measured the wrong things. It is that you reported numbers instead of meaning. Lead with the answer, cut to a handful of metrics, show the direction, translate every figure into a consequence, and name what needs deciding — and the report stops being a chore nobody reads and becomes the way support speaks to the rest of the company.