Most support scorecards measure activity. This one was designed to change it — with weighted components, industry benchmarks, and a scoring scale specific enough that agents knew exactly where they stood and exactly what to do about it.
The typical support team scorecard tracks calls handled, average handle time, and CSAT. It reports these numbers monthly. Agents see the report, note where they rank, and then continue doing what they were already doing — because the scorecard doesn’t tell them specifically what to change or give them a precise enough target to aim at.
The Tyco/JCI scorecard was designed differently. The goal wasn’t to measure performance — it was to create a shared language between agents and managers that made performance conversations precise, evidence-based, and actionable. An agent scoring a 2 on First Case Resolution knew exactly what that meant: they were below the 88% threshold. They knew what a 3 was (88–90%) and what it would take to get there. The path from a 2 to a 3 was a defined improvement, not a vague aspiration.
The scorecard weighted four distinct areas of performance. The weighting itself was a deliberate statement about what the organisation valued. At 35% — the single largest component — quality outweighed quantity. This was not obvious to agents who had come from environments where calls-per-hour was the primary metric.
Each metric used a 0–4 or 0–5 point scale with specific thresholds for each score, not vague labels like “exceeds / meets / below expectations.” This specificity was the difference between a scorecard that changed behaviour and one that just generated arguments.
For First Case Resolution: 99%+ = 5, 90–98% = 4, 88–90% = 3, 86–88% = 2, 85–86% = 1, below 85% = 0. Every agent could calculate their own score before the manager ran the numbers. That self-scoring was not accidental — managers who present scores as conclusions tend to get defensiveness. Agents who arrive at their own score through data they can verify own it differently.
The scorecard included an industry comparison column for each metric. Where benchmark data was available, agents could see not just how they performed against team averages but how those team averages compared to industry standards.
This served two purposes: it gave context to team performance conversations, and it gave individual agents a reference point beyond their immediate team. Agents who scored above team average but below industry benchmark had a different development conversation than agents who scored below team average. The benchmark column made that distinction visible without the manager having to manufacture it.