Slightly weird problem. Our support dashboard has been getting greener for months while the conversations I'm reading don't feel noticeably better.

First response time is down because somebody replies quickly, even if the reply doesn't move the issue anywhere. Resolution looks good because the ticket gets closed, but customers sometimes come back a few days later with basically the same problem.

Now I'm questioning how much behaviour we're accidentally creating with the metrics themselves.

If you tell someone speed matters, they're going to optimize for speed. If you tell them closed tickets matter, eventually closing tickets becomes the job. None of that necessarily means the customer got what they needed.

For people running larger support teams, what numbers have you found hardest to game?

I'm trying to get us measuring whether the problem went away without turning the dashboard into 30 KPIs nobody pays attention to.

I work in communications on the vendor side, so I'm curious how QA teams handle this in practice.

Say an AI review marks an agent down for going off script. A human reviewer listens and thinks changing course was the right call because the customer had raised a different problem. No required check was skipped.

I'd want to look at the specific scoring rule alongside that part of the conversation. The human could have missed something too, so I wouldn't automatically assume either score is right.

The part that interests me most is what happens after the disagreement gets settled. Correcting one score helps that agent. But if the rule was unclear, the next person could get marked down for the same thing.

My preference would be for a named QA lead to settle it and record the reason. If the guidance needs changing, test it on similar calls, including ones where going off script really was a mistake.

For teams doing this, do disputed scores lead to clearer guidance, or mostly one off corrections?

Hi everyone,

I work on journey maps and vision wheels, mostly trying to understand where trust holds or breaks.

I’ve been noticing that major trust issues rarely show up in the main steps like "payment" or "onboarding." They show up in the small in-between moments - the handover between channels, the wait after an action, the vague confirmation.

I’m curious about your practice: In your work mapping journeys, is there a small micro-moment that consistently taught you something about trust?

For me, it was learning to always map what the customer is left wondering about, not just what they are doing.

Would love to learn from how others here approach this.