## TL;DR
Most support dashboards are unread because they track everything. Six metrics cover nearly every decision: first-contact resolution, CSAT, resolution time by severity, reopen rate, top ticket drivers, and deflection rate. Ignore raw ticket count and average handle time on their own; they measure activity, not outcomes. Review weekly with one owner and one action per metric.

## The query

```text
support analytics: which metrics actually matter
```

## Use this when

- You are building or rebuilding a support dashboard
- Leadership asks what support should report
- You have metrics but no decisions coming out of them
- You need to cut a bloated metrics list down

## Not for

- Data pipeline or warehouse engineering
- Advanced statistics or predictive modeling
- Marketing or product analytics
- Individual agent performance reviews

## Steps

### 1. Start from outcomes, not activity

Ask what decisions the metrics should drive: staffing, product fixes, content investment. Then pick metrics that move those decisions. If a number wouldnt change anyone's behavior, it doesnt belong on the dashboard.

Expected output: a short list of decisions, each with the metric that informs it.

### 2. Track the core six

First-contact resolution (did we solve it in one go), CSAT (did the customer feel solved), resolution time by severity (are urgencies actually urgent), reopen rate (did the fix stick), top ticket drivers (what keeps breaking), and deflection rate (is self-serve working). These six explain nearly all of support performance.

Expected output: six metrics defined consistently and tracked over time.

### 3. Demote the vanity metrics

Raw ticket count, average handle time alone, and messages-per-ticket measure busyness, not goodness. AHT is useful only paired with quality: fast and wrong is not a win. Keep them as context, never as goals.

Expected output: activity metrics labeled as context, not targets.

### 4. Segment before you conclude

Averages lie across mixed populations. Cut every core metric by severity, channel, and plan tier at minimum. "Resolution time is up" means nothing until you know whether it is P1s, chat, or enterprise tickets driving it.

Expected output: each metric broken out by at least severity and channel.

### 5. Run a weekly review with owners and actions

Thirty minutes, same time weekly: each metric gets an owner, a trend, and one action or an explicit "no action." Metrics without owners drift; reviews without actions are theater. Write the actions down where the team can see them.

Expected output: a weekly review with named owners and recorded actions.

## Variant phrasings

### most important customer support kpis

Step 2. The core six, with definitions.

### support dashboard metrics that matter

Steps 2 and 4. Core metrics, segmented.

### how to measure support team performance

Steps 2, 3, and 5. Outcomes over activity, reviewed weekly.

## Why it happens

Support generates endless countable things, and tools happily chart all of them, so teams end up watching the numbers that are easy instead of the numbers that matter. Activity metrics feel productive and are easy to game, which is why ticket-count goals produce ticket-count behavior. The discipline is picking a few outcome metrics and letting the activity numbers stay in the background where they belong.

## Edge cases

- Small teams and noisy data - weekly CSAT on 20 responses swings wildly. Use rolling averages and dont overreact to one week.
- Survey bias: only the delighted and the furious reply. Treat CSAT as directional and pair it with reopen rate.
- Deflection done badly: high deflection with rising tickets means the help center is failing, not succeeding. Read deflection alongside contact rate.
- Gaming: any metric tied to compensation gets gamed. Keep targets team-level and pair speed metrics with quality ones.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_V_zL-AuLthn2LcNYjV62Mg