A training team and a QA team do different jobs, and a support organisation needs both. Training makes people capable. QA checks that the capability shows up in the work. Add a scorecard that tells each person exactly where they stand, and you have the loop that keeps a team improving without anyone having to nag.
Standing up dedicated training and QA teams was the fourth pillar of the plan I laid out in building a three-to-five-year support plan, with scorecards close behind. I’d built versions of all three before, at AudienceView and at Tyco, so I knew what worked and what to avoid. This post explains how they fit together and why I put them in this order.
Why does a support team need dedicated trainers?
Because “learn by shadowing” doesn’t scale. In many support teams, training means pairing a new person with a busy colleague. That works for the first hire and fails for the tenth, because the colleague’s own work suffers, the new person gets whatever that colleague happens to know and nothing is checked. The curriculum lives in people’s heads, and it leaves when they do.
A dedicated training function turns that into a system. Someone owns the curriculum, keeps it current and measures whether it works. I covered the design in the AudienceView University case study: three levels of certification, each with defined content and an assessment, a structured 90-day onboarding track and a link between certification and the knowledge base, so that every senior certification meant contributing articles. There’s no such thing as tribal knowledge that scales.
Training has to continue after onboarding. I made the argument in the ddo piece why one-time training doesn’t work: skills decay, products change and a team that trained once a year is working from an old map. Regular, short, targeted sessions, tied to what’s changing and to what the QA findings show, do far more than a big annual event.
What does a QA team do that managers can’t?
It provides consistent, independent review. Managers are busy and inclined to sample the cases that come to their attention, which are usually the extremes. A QA function reviews a representative sample against agreed criteria, scores it the same way every time and feeds the results back to the individual, to their manager and to training. It’s the difference between an impression of quality and a measurement.
Define quality first. Without a shared definition, QA turns into one person’s opinion. Our criteria covered whether the answer was correct, whether the customer’s deadline was understood, whether communication was clear and whether the case was documented well enough for the next person. Those are things the customer would recognise. I explored the broader balance in quality, productivity and striking the right balance, and the same point applies: don’t let a speed target quietly punish quality.
Calibrate regularly. Have reviewers score the same case independently and compare. If they disagree, the criteria are vague, and that’s the thing to fix. A QA programme the team doesn’t trust is worse than none, because people stop learning from it and start arguing with it.
How do you design a scorecard people can act on?
With weights that say what you value and scales precise enough to show what to do next. At Tyco I built a scorecard with four weighted components, and I describe it in the support scorecard case study. Quality carried 35% of the weight, outweighing quantity at 20%, with customer feedback also at 35% and administrative measures at 10%. That weighting was a statement: quality matters more than speed, and the customer’s view matters as much as ours.
The scales did the rest. Instead of “meets expectations”, each measure had thresholds. For first-case resolution, 99% and above scored a 5, 90 to 98% a 4, and below 85% a 0. An agent scoring a 2 knew what that meant and what a 3 would take. The path from one score to the next was a defined improvement, not a vague aspiration. A scorecard that tells you where you are without telling you how to move isn’t a management tool. It’s a report.
I’d argued the same in why your company needs a tech support scorecard. At Q4 we built employee scorecards to give a rounded view of performance, drawing on that earlier design and adapting it to front-end technical support, where the work is different from phone support but the principle isn’t.
How do the three pieces connect?
As a loop. QA reviews cases and finds patterns. Those patterns go to training, which turns them into short sessions and updates the curriculum. The scorecard shows each person how they’re doing, including their QA results, and where to focus. Managers use it in coaching conversations. As the team improves, QA’s findings change, and the cycle continues. Each part makes the others more useful.
The same loop supports routing. If you’re routing by skill, you need a reliable way of knowing who can do what. Certification and QA results provide it. A person who passes a level and scores well on that kind of case can be routed that kind of work with confidence, and one who struggles gets support first. It’s why I put structure and training ahead of automation in the plan: they supply the information the automation needs.
Keep it human. Scorecards and QA can feel like surveillance if they’re only used to catch mistakes. Use them to recognise good work as often as to correct poor work, share the best examples with the team and let people see their own scores before anyone else does. Done well, people ask for their results. Done badly, they dread them.
What do the first 90 days of a new agent look like?
A structured path with checkpoints, not a hope that they’ll pick things up. In the first days they get access, tools and an introduction to the product and the customers. In the first weeks they work through the foundation level of the curriculum, shadow experienced people and handle simple requests with someone reviewing their work. By the end of the first quarter they should be handling the routine work on their own and should have passed their first assessment. The AudienceView curriculum used a 90-day track like this, and the same thinking applies at Q4.
Pair that with a named mentor. A new person with a question should know exactly who to ask, and that person should know it’s part of their job. Tell the mentor what good looks like, give them time and recognise the work. The best mentors are often the people you’d least expect to have spare capacity, because the work of explaining things makes them better at their own.
Check how it’s going at fixed points, say after two weeks, a month and at the end of the track, with a short conversation about what’s working and what isn’t. Early problems are cheap to fix. By month three they’ve become habits, and the new person may have decided the job isn’t for them without telling anyone.
How do you make training stick for a distributed team?
By keeping the content in one place and the standard the same. A team spread across North America, Europe and Latin America can’t depend on hallway learning, so the curriculum, the assessments and the knowledge base have to carry it. Record short walk-throughs of common tasks, keep written guides current and run live sessions at times that work for more than one region. Rotating the time means nobody is always the one staying up late.
Use the QA findings to decide what to teach. If reviewers keep seeing the same kind of mistake, that’s the next session. If a particular category of request is slow to resolve, build a short guide for it. Training that responds to what’s really happening in the queue earns attention. Training that repeats the same material every quarter doesn’t.
Finally, make certification matter. People work toward something when it changes what they do and what they earn. At Tyco, I tied certification levels to pay, as described in the skills-based compensation case study. Even where that isn’t possible, tying levels to the work someone is trusted with gives certification a reason to exist.
Capable people, honest review and a clear sense of where you stand. That’s most of what a support team needs to get better.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
