On Monday morning, a support manager should be able to read one screen and answer three questions: What changed last week? Which conversations explain it? Who will do what next?
The template below is built for that job. It keeps workload, responsiveness, CSAT, QA, customer evidence, and the next action together. Copy it into Slack, Notion, or a recurring email, then replace the bracketed fields.
Supportman builds this weekly report for you — CSAT, volume, and quality trends delivered to Slack every week without a dashboard login.
Copy this weekly support report template
Report header
Support week: [Monday date]–[Sunday date] | Owner: [name] | Compared with: [previous week or trailing four-week baseline]
1. Scorecard
| Measure | This week | Comparison | Status |
|---|---|---|---|
| Conversations received | [count] | [change] | [normal / watch / act] |
| Median first reply | [time] | [change] | [normal / watch / act] |
| 90th-percentile first reply | [time] | [change] | [normal / watch / act] |
| Median resolution time | [time] | [change] | [normal / watch / act] |
| Surveyed CSAT | [percent] ([positive]/[total ratings]) | [change] | [normal / watch / act] |
| Survey response rate | [ratings/surveys sent] | [change] | [context] |
| QA score | [score] from [reviewed conversations] | [change] | [normal / watch / act] |
Keep first reply and resolution separate. Add a tail measure such as the 90th percentile because a healthy median can conceal a queue of customers who waited much longer. If the team works Monday to Friday, compare five complete workdays with five complete workdays.
2. Material changes
- [Metric or queue]: [change], from [previous value] to [current value].
- [QA attribute or DSAT theme]: [change], based on [sample size].
- No change worth acting on: say so when the week is within normal variation.
3. Customer evidence
- Repeated friction: [theme], found in [count] of [count] reviewed conversations. [Links]
- DSAT or recovery: [one-sentence summary]. [Link]
- Practice to repeat: [specific agent behaviour and why it worked]. [Link]
Choose conversations because they test an explanation, not because they are unusually dramatic. Remove customer-sensitive details when the report has a broad audience.
4. Decision and owner
Because [evidence], [owner] will [observable action] by [date]. We will check [metric or conversation sample] in the report for [week].
One committed action is enough. Put other questions in a backlog instead of disguising them as five simultaneous priorities.
A fully filled-in sample week
Imagine a 12-person SaaS support team reviewing 7–13 July. These values are illustrative, but the level of detail is what a useful report should contain.
Support week: 7–13 July
Owner: Priya, Support Operations | Comparison: previous complete week
| Measure | This week | Previous week | Status |
|---|---|---|---|
| Conversations received | 684 | 598 (+14%) | Watch |
| Median first reply | 6m 12s | 5m 48s (+24s) | Normal |
| 90th-percentile first reply | 1h 46m | 58m (+48m) | Act |
| Median resolution time | 3h 18m | 3h 25m (-7m) | Normal |
| Surveyed CSAT | 89% (56/63 positive) | 93% (52/56 positive) | Watch |
| Survey response rate | 15% (63/420) | 14% (56/400) | Context |
| QA score | 86/100 from 137 reviews | 88/100 from 120 reviews | Watch |
What changed
- The slowest replies deteriorated: the median moved only 24 seconds, but the 90th percentile rose by 48 minutes. The delay was concentrated between 10:00 and 13:00 on Tuesday and Wednesday.
- Billing contacts increased: 104 conversations used the billing/refund tag, up from 61. Forty-six mentioned the new annual-plan renewal email.
- QA lost two points: accuracy and tone held steady; expectation-setting fell from 84 to 76 in the reviewed billing conversations.
What the conversations showed
- Repeated friction: in 8 of 12 reviewed renewal-email conversations, the customer believed the charge had already occurred when it was actually scheduled. Link the eight conversations here.
- DSAT: one customer contacted support twice because the first reply explained refund policy but did not confirm whether their renewal had been cancelled. Link the conversation here.
- Practice to repeat: an agent led with the account status, named the renewal date, and then explained the policy. The customer replied that the situation was clear. Link the conversation here.
Decision for this week
Priya will add an account-status check and a required “renewal date / cancellation confirmed” line to the billing reply guide by Wednesday. On Friday, the QA lead will review 20 new renewal-email conversations for expectation-setting and report how many include both details.
The sample does not claim the email caused every movement. It records a plausible explanation, the evidence reviewed, and a check that can confirm or weaken that explanation next week.
Set thresholds before the week starts
Do not decide what counts as “bad” after seeing the number. Set a normal range and an action threshold for each metric using your SLA, staffing model, and recent baseline. A simple starting rule might look like this:
| Signal | Watch | Act |
|---|---|---|
| Volume | 10% above the trailing four-week average | 20% above average or backlog exceeds one day of capacity |
| 90th-percentile first reply | Misses the internal target on one day | Misses it on two workdays or breaches a customer SLA |
| Surveyed CSAT | Falls 3 points with at least 30 ratings | Falls 5 points with at least 30 ratings, or a high-risk DSAT appears |
| QA attribute | Falls 4 points across at least 20 reviewed conversations | Falls 8 points, or a critical compliance failure occurs |
Those numbers are illustrative, not universal benchmarks. A team with 12 ratings a week should use a longer comparison window; a regulated team may act on one critical failure. Always override a statistical threshold for security, safety, legal, or high-value customer risk.
Build the report in 30 minutes
- Freeze the window. Export the same complete days, queues, channels, business hours, and timezone every week. Note holidays, incidents, launches, and staffing gaps.
- Populate the scorecard. Pull volume, median and tail response time, resolution time, rating counts, response rate, CSAT, and QA coverage. Do not compare a partial week with a full week.
- Flag only threshold breaches. Show all core measures, but investigate the two or three that crossed a pre-agreed line.
- Segment the movement. Check queue, tag, channel, day, and customer plan. Stop when the segment becomes too small to interpret responsibly.
- Read conversations. Review a small purposeful sample from the affected segment, plus one counterexample. Record the count reviewed so readers know the strength of the evidence.
- Name one action. Give it an owner, deadline, and next-week check. Publish the report where the team already reviews work.
If extraction takes the full 30 minutes, automate the scorecard first. A manager’s time is better spent checking definitions and reading conversations than copying values between tabs.
Read CSAT and QA without fooling yourself
Write “Surveyed CSAT: 89% from 63 ratings; 15% response rate”, not merely “CSAT: 89%.” The denominator tells readers how fragile the percentage is, while the response rate warns that respondents may not represent every customer.
If you include predicted CSAT, label it AI-inferred, state its conversation coverage, and keep it separate from customer-submitted ratings. For QA, show the overall score with the reviewed count and the attribute that moved. Record rubric, reviewer, or scoring-model changes as a break in the trend.
A dashboard can hold more diagnostic detail; the weekly report should retain only the measures needed to make this week’s decision. See the broader guide to customer support dashboard metrics for metric selection and interpretation.
Turn the report into one owned action
“Improve billing CSAT” cannot be checked. “Priya adds the renewal date and cancellation status to the billing guide by Wednesday; QA reviews 20 matching conversations on Friday” can.
End the review by reading the action aloud and confirming the owner has the authority and time to complete it. At the start of next week’s report, mark the previous action done, not done, or superseded, then show the follow-up measure. This small line prevents weekly reporting from becoming a record of recurring observations.
Recognition belongs here too: name the behaviour the team should repeat and link the conversation. Avoid public rankings based on ticket count or raw CSAT, which are heavily affected by queue mix and rating volume.
Frequently asked questions
How long should a weekly customer support report be?
A support leader should be able to scan the scorecard, evidence, and action in about five minutes. Put queue-level tables and larger conversation samples behind links rather than expanding the main report.
What if our team has too few CSAT ratings?
Show the weekly count, but interpret CSAT over a rolling four- or eight-week window. Do not hide a serious individual complaint; route it for recovery while avoiding a broad process change based on one rating alone.
Should the report show individual agent scores?
Use the team report for capacity, routing, product friction, and shared practices. Deliver individual QA and coaching privately, with enough conversation context to make the feedback fair. Publicly recognize a specific useful behaviour without publishing a league table.
Should we compare with last week or a longer baseline?
Use the previous complete week for operational recency and a trailing four- or eight-week range for perspective. If seasonality is strong, compare with the equivalent period as well. Label every comparison so readers never have to guess.
Deliver the report automatically
Supportman assembles weekly support reporting in Slack, including daily volume, response metrics, rating denominators, CSAT trends, and quality signals. Your review can begin with the unusual movement and the conversations behind it instead of a spreadsheet merge.