Five lessons, about fifty-five minutes. Every support role eventually gets measured by a handful of numbers. This module is about knowing what those numbers actually capture, what they miss, and how to report an honest bad week — because a founder who only ever hears good numbers stops trusting the numbers at all.
Three numbers show up in nearly every support role, and each measures something narrower than it sounds like it does. Knowing the actual definition, not just the name, is what lets you use them honestly rather than being used by them.
CSAT (customer satisfaction) measures how a customer felt about one specific interaction, rated right after it — not their overall relationship with the brand, and not whether the underlying problem is actually gone. First response time measures how fast someone got any reply at all, including a holding message — not whether that reply helped. Resolution time measures how long a ticket stayed open — which can be gamed by closing a ticket early and letting the customer reopen it, making the metric look better while the actual experience got worse.
First response time of two minutes, CSAT of 5 stars, on a ticket that took four separate messages and eleven minutes total to actually resolve, because the two-minute "response" was just "thanks, looking into this!" A dashboard reading this ticket sees pure success.
Write one scenario where a support metric would look excellent despite the actual customer experience being mediocre.
A metric is meant to be a proxy for good service, not the goal itself. The moment it's treated as the goal, the incentive quietly shifts toward whatever makes the number look good, even when that diverges from what actually helps the customer.
If chasing first response time means sending a low-value holding message instead of taking the extra ninety seconds to actually solve the problem, the metric is now working against the customer. If chasing resolution time means closing a ticket the moment a reply is sent, before confirming it actually worked, the same thing is happening. The tell is always the same: doing something that helps the number but doesn't help the person.
Closes the ticket the instant a reply is sent, without waiting to confirm the fix actually worked — the metric improves, and the customer reopens it two days later, now more frustrated than the first time.
Sends the reply, then follows up once to confirm it worked before closing — resolution time looks slightly worse on paper, and the ticket actually stays resolved.
Write one way each of the three metrics from 8.1 could be gamed, and what actually solving the underlying problem would look like instead.
Every support role has a genuinely bad week eventually — a supplier problem causing a spike in complaints, a personal reason you were slower than usual, a queue that simply outgrew what one person could handle. How that week gets reported matters more, longer-term, than the numbers themselves.
The real numbers, not softened or hidden. The specific reason, named plainly — not excused, just explained. And what's being done about it, if anything is within your control. A founder who gets this once trusts every future report more, including the good ones.
"CSAT dropped to 3.8 this week from our usual 4.6. Cause: the broken-pump batch issue drove a real spike in complaints — 14 this week versus our normal 2–3. I've flagged the batch to the supplier per my note on Tuesday. Expect this to recover once the replacement stock ships."
Write a bad-week report for a made-up dip in one of the three metrics, using the worked example's shape.
Occasionally a target itself is the problem — a first-response-time goal so aggressive it only leaves time for a holding message on every ticket, or a resolution-time target that pressures closing tickets before they're actually fixed. Pushing back on the target itself, with reasoning, is sometimes the right call, not a failure to hit it.
Name the specific tradeoff the target forces, propose an alternative that protects the actual outcome, and frame it around what the founder cares about — retained customers — rather than around your own workload, which reads as self-interested even when it isn't.
"Hitting a 2-minute first-response target on every ticket means I can only send a holding message, not an actual answer, on the harder ones — which means customers get a fast reply and then wait longer overall for the real fix. I'd rather target under 5 minutes for a genuinely useful first reply. I think that serves customers better even though the number looks less impressive."
Write a pushback message for a target you think would hurt service quality, using the worked example's shape.
A report a founder skims in ten seconds and actually retains beats a detailed dashboard export they never open. The skill is compression: the three numbers that matter, what changed and why, and anything worth their attention — nothing else.
Numbers first, with last week's for comparison. One line on what's behind any real change. Anything worth flagging — a pattern, a risk, something good worth noting too, since an honest report includes real wins, not just problems.
"CSAT 4.6 (was 4.5). First response 4 min avg (was 6). Resolution 1.1 days avg (was 1.3). Nothing to flag this week — quietest week in a month. One nice note: a repeat customer mentioned in chat that the new packaging arrived undamaged, first time in a while."
Write a one-page weekly report for a made-up week, using the shape above, including at least one genuine positive note.
A week's worth of raw ticket data is supplied for Bumi Naturals — timestamps, first replies, resolution times, and CSAT scores, unsorted and including a real dip caused by the broken-pump batch issue from earlier modules.
Whether you can turn messy raw data into an honest, compressed report under a real bad-week scenario — not whether you can recite what CSAT stands for.
You should now have: a clear-eyed read on what each metric actually measures and misses, a sense of when chasing one makes service worse, an honest bad-week report shape, a pushback script, and a compressed weekly report template. Module 9 turns to running yourself as an actual business — rates, agreements, and getting paid across borders.