It is Monday morning. Surveyed CSAT is down three points, but only 42 customers responded. First-response time looks healthy at the median, while a small queue has been waiting for hours. QA says resolution quality has slipped. Which signal gets the team’s attention first?
A dashboard earns its place when its composition makes that decision easier. The first screen needs seven distinct views of the same operation: demand, speed, resolution, surveyed satisfaction, satisfaction coverage, quality, and recovery. Each card should show a headline, the denominator or comparison that gives it meaning, and a path to the conversations behind it.
Supportman delivers the support metrics that matter straight to Slack, so the dashboard comes to your team instead of waiting to be opened.
Build the first screen as a scorecard
Do not give every available metric equal space. Use the first screen for orientation and exceptions; put detailed distributions and conversation lists one click deeper.
| Card | Headline | Context beside it | Drill-down |
|---|---|---|---|
| Demand | Eligible conversations | Change and work mix | Queue, channel, issue type |
| Responsiveness | Median first response | 90th percentile and service target | Oldest waiting conversations |
| Resolution | Chosen resolution proxy | Definition, count, and trend | Reopens, repeats, or failed rubric items |
| Surveyed CSAT | Positive-rating percentage | Ratings, eligible surveys, response rate | Rating distribution and comments |
| Coverage | Share of conversations assessed | Surveyed, predicted, and excluded shares | Unrated low-satisfaction predictions |
| QA | Overall quality score | Evaluated count and weakest attributes | Rubric evidence and conversations |
| DSAT | Negative trend | New, unowned, and overdue cases | Recovery queue and root causes |
This layout prevents a common failure: a clean-looking average occupying the largest card while the denominator, tail, and unresolved customer cases are buried elsewhere.
1. Demand and work mix
Use eligible conversations as the volume headline, then place period change and the largest mix shift beside it. A jump in billing contacts, an influx from chat, or a new enterprise queue may explain movement elsewhere without excusing it.
The card should answer three questions: how much work arrived, where it arrived, and whether the mix changed. Agent-level handled counts belong in a diagnostic view because queue complexity, shifts, and reassignment rules make them unreliable as a standalone productivity ranking.
2. Responsiveness: middle and tail
Pair the median first-response time with the 90th percentile. The median describes the middle experience; the 90th percentile exposes customers who waited far longer. Show the same pair for time to close only if closing rules are consistent enough to make the comparison useful.
Put the service target on the chart and link the tail to the oldest affected conversations. Keep acknowledgment and resolution separate: a fast automated reply can improve first-response time while doing nothing for the customer’s problem.
3. Resolution with a declared proxy
“Resolved” is rarely a trustworthy field by itself. A team may use first-contact resolution, reopen rate, repeat contact within a defined window, customer confirmation, or a rubric-based resolution score. Choose the proxy that your system can measure consistently and print its definition in the tooltip or card detail.
For example, if the card uses reopen rate, specify whether agent-created follow-ups count, how long the reopen window lasts, and whether merged conversations are excluded. A ticket closed by inactivity should not silently become evidence of successful resolution.
4. Surveyed CSAT with its denominator
The surveyed-CSAT card needs five values in one view: positive ratings, total ratings, eligible survey requests, response rate, and the positive-neutral-negative distribution. A 95% score from 20 ratings carries different evidence from 95% based on 2,000.
Keep this card explicitly labelled surveyed CSAT. It reports what respondents said; it does not describe every eligible conversation.
5. Satisfaction coverage, split by source
Coverage answers a different question from surveyed CSAT: how much of the support operation has any satisfaction signal? Split the eligible population into customer-rated, predicted, low-confidence, and excluded conversations. Never blend customer ratings and model predictions into one score.
A study of Samsung support chats found that the rated subset could look more positive than the modelled unrated subset; the citation, limits, and implications are covered in Your CSAT Score Is Missing Most of Your Customers. Here, the compositional lesson is simple: show surveyed and predicted coverage side by side so a manager can see which population each signal represents.
The drill-down should surface predicted low-satisfaction conversations, confidence or exclusion reasons, and the score distribution. Predicted CSAT is a triage signal to validate, not a customer statement.
6. QA score with rubric evidence
Place the overall QA score beside the evaluated-conversation count and the two or three attributes driving the movement. Useful attributes might include technical accuracy, problem resolution, communication, and brand voice, but the dashboard should use the rubric your team actually coaches against.
Every material change needs a route to the criterion, supporting excerpt, and full conversation. If AI performs the evaluation, expose the rubric and make review possible. A model score without criteria or evidence is too weak for coaching or performance decisions.
7. DSAT trend and recovery queue
Separate the outcome from the work it creates. The trend shows negative ratings over time; the queue shows new, unowned, acknowledged, overdue, and closed recovery cases. Add recurring root causes only when the classification is consistent enough to act on.
Use zero tolerance for unowned DSAT: every new case should either have an owner or a documented reason no follow-up is appropriate. A closed recovery case means the promised action happened, not merely that someone opened the conversation.
Set triggers before the meeting
There is no universal “bad” CSAT, response time, or QA score. Build triggers from customer promises, recent comparable performance, and a minimum denominator. Write the rules beside the dashboard so red does not mean “the chart moved.”
An illustrative set of rules could be:
- Immediate: any new DSAT without an owner, or a critical QA failure defined by the rubric.
- Daily: the 90th-percentile first response breaches the published service target, with a link to the waiting queue.
- Weekly: a metric leaves its recent operating range and has enough underlying conversations or evaluations for review.
- Watch only: the percentage moved, but the denominator is below the team’s stated minimum.
Review the thresholds after staffing, routing, survey, or rubric changes. A trigger calibrated on the old workflow may create noise or hide a real shift.
Read the cards together
Imagine a 12-person team with stable total volume. Surveyed CSAT falls, but the response count is small. At the same time, predicted low-satisfaction coverage rises in the billing queue, QA’s resolution attribute falls, and reopen rate increases. That combination justifies a billing-workflow investigation; the CSAT movement alone would not.
If surveyed CSAT falls while QA, predicted satisfaction, resolution, and response tails remain stable, start by reading the negative ratings and checking the survey population. The dashboard should help the manager form a testable question, then open the relevant evidence.
Research on balanced-scorecard interpretation found that managers simplify multi-measure displays and may apply their own weights when analysing performance. Read the balanced-scorecard interpretation study. Make the intended order visible: outcomes and active risk first, operational context second, conversation evidence on drill-down.
Evaluate the dashboard by the decisions it supports
A review of 81 papers proposed a task-based dashboard-evaluation framework spanning monitoring, decision support, behaviour change, workflow, engagement, utility, and implementation. Read the 81-paper dashboard-evaluation framework.
Apply that broader standard quarterly. For every first-screen card, ask:
- What decision did this card support?
- Could the manager see its denominator and definition?
- Did an exception reach a named owner?
- Could the team move from the aggregate to conversation evidence?
- Was any card repeatedly ignored or interpreted incorrectly?
Remove or demote cards that produce no decision, workflow, or useful investigation. Add a metric only when its role in the composition is clear.
Frequently asked questions
How many metrics should a support dashboard show?
Use enough first-screen cards to cover demand, responsiveness, resolution, surveyed satisfaction, satisfaction coverage, quality, and recovery. Put secondary cuts and agent-level detail behind those cards instead of extending the headline row indefinitely.
Should predicted CSAT replace surveyed CSAT?
No. Show customer-submitted ratings and predicted scores as separate sources with separate coverage. Predictions can help triage unrated conversations, but they are not customer feedback.
Which segments belong on the dashboard?
Keep the first screen focused on material mix shifts. Offer filters for queue, channel, issue type, product area, language, customer segment, and human or AI handling, but suppress or label cuts that fall below your team’s minimum denominator.
Build one balanced view of support
Supportman brings surveyed ratings, predicted satisfaction coverage, QA signals, operating context, and the underlying conversations into one view. The dashboard points to the exception; the evidence gives the team something concrete to investigate.