Five ways to ruin the Quality Assurance process in your support organization
The quality assurance process is one of the utmost importance for providing top-notch service to your customers.

QA, when done right, will increase the number of happy clients. And it's easier to retain and sell more to happy customers. And that, in turn, means more revenue for your company. Everyone is happy when the revenue grows, right?
Bonuses, cool corporate events, promotions, fresh smoothies right at your office desk, and whatnot.

Should one do it the wrong way, however, it may ruin the whole support morale and disrupt the service in a bad way. Agents would hate the process, the QA manager, and the company. And there is no way they would make customers happy anymore.

Can you guess what makes such a drastic difference in the result?

Correct! It is the person or people who run the process – Quality Assurance managers – and the way they are motivated. And today we'll share a few tips on how to recognize pitfalls and steer away from the dangerous path to no revenue and no smoothies.

We've learned these pieces of wisdom by making mistakes ourselves, so you can cut your way short and start off the right way from the very beginning.

Fasten your seatbelts, we are ready for takeoff.
Mistake #1 - Promote the best agent
Take the most experienced, technically skilled, and high-achieving agents and make them Quality Assurance managers.

At the first glance, it might look like a good solution: the agent already knows a lot and would be able to recognize good service from a bad one and teach others from their own experience.

In reality, excellence in hard skills is often accompanied by a lack of soft skills and business orientation. In our experience, top performers often focus on the technical part of the problem and tend to overlook the business and emotional side of the ticket.
As a result, the QA process is skewed to the technical side, which may not always be the focus of your support org.

Instead, an agent who demonstrates the most proactive approach, who is not scared of taking additional responsibility – that is the choice that always works best.

Of course, you don't have to discard your candidate just because they have great technical skills – if both sides are present, then you must have been lucky to get one of the true support rock stars unevenly spread across the bottomless skies of LinkedIn.

And that makes the thumb rule #1:
Managerial and soft skills are more important for QA managers than technical or hard skills.
Mistake #2 - Pick the best executor
The next candidate you may have been musingly glazing would be one of the support team leads. That looks like the best next bet – they surely have managerial and soft skills. And knows the support workflow too, Woah!

One more thing to consider just before signing the promotional papers: the person must not only be good at following and enforcing rules but also great at contributing to the process itself.

Sometimes, strict adherence to rules may turn into a habit of blindly following the workflow without engaging what they call "common sense".

This is a vital skill if you operate a nuclear plant, but it might be slowing down an agile IT company.

We, the IT people, love the flexibility that allows our business to cut our ways short, and that's the thing to embrace in the QA manager too. They should be able to drive and facilitate the evolution of the process.

As the result we get rule #2:
QA managers should be drivers of the process, not executors.
Mistake #3 - Ignore the respect
Let's say we've addressed the two issues above.

We have our perfect QA manager with awesome managerial skills, a great level of common sense, and creativity.

Can we sign those promotion papers already? Not just yet.

Besides, it's better to save some trees and use less paper anyway, but that's not the case for this very article.


There is one more thing to keep in mind: a QA person is someone who gives "a penalty" to support agents. And if the team doesn't generally acknowledge the authority of the person, the decisions the QA manager makes would always be questioned. And that means we are in trouble.

The team would not trust the advice the QA manager makes. They would follow the process to the minimally possible degree just to avoid penalties. And always dispute the technicalities, while the quality of the service will be out of their sight forever.

So, what do we do then?

Ideally, we would want to see the QA manager more as a coach, or mentor, who helps to find a better way to do a person's job. Not a heartless machine that issues fines and penalties.
Someone, who agents have seen to be proficient in resolving complex situations.

Here goes rule #3:
A person who is recognized as a coach and mentor would have the necessary authority to be a well-accepted QA manager.
Mistake #4 - Set wrong goals for the QA manager
What KPI should you set for your newly assigned QA manager?

Well, it must never be the number of mistakes a QA person finds in support tickets.
It's been so difficult to find the person, we don't want them to be hated by the team at the end of the day, do we? The number of misdeeds as the KPI would do exactly that.

The next thought would be to set "overall QA score" as the KPI, but in such a case the QA manager would be tempted to set a slightly higher score and ignore mistakes – everyone wants their bonuses.

But we want our customers to have a great support experience, so the company has revenues for our bonuses and smoothies, right?

A goal leading us to success should be a representative sample size of evaluations per agent in the period of time.
In simple words – the more evaluations the QA manager does, the better and more objective picture of the whole team we have.

Rule #4:
QA score and the number of mistakes – are bad KPIs.

The number of evaluations per agent – is a good KPI.
Our sales team asked to put that block in:

Swarmica has a built-in mechanism for generating a representative sample size for Article Quality evaluation, and a dashboard for QA managers where they see the goal they are about to meet:
Article Quality Evaluation in Swarmica
Want to see it in action?
See that? It means we can find the areas for improvement more accurately and let the QA person handle corresponding training on these topics.

So the QA manager gets the respect we talked about in the previous bullet, agents make fewer mistakes, clients get better service, a company acquires more revenue, and smoothies and everyone is happy.

However, the goal of improving these areas as well as the overall QA score is a good KPI for support agent's managers and team leaders.
Mistake #5 - Allow to appeal directly to the QA manager
Everyone loves to debate, especially if it's about the assessment of their job and their bonuses. The ability to debate and review a given QA score is a good practice that should be in place.

However, the final most popular mistake we would be talking about is to let the QA person handle appellations directly. That might work if the team is fairly small, but imagine if it's dozens or even hundreds of agents.

It's simply not feasible to process all such appeals. And that makes agents sad.

Another drawback is that the agent's proficiency becomes a headache for the QA manager, while the agent's manager is not involved in this process and does not keep the responsibility.

The best practice is when agents appeal to their direct manager at first and if and only the manager agrees, then the manager goes to QA and runs the debate.

The profit is that linear managers may resolve a huge portion of appellations and coach their agents right in their teams. Only a small portion of objections gets to be discussed by team leaders and QA managers.

And that makes our final thumb rule:
Agents should appeal to their direct managers, and managers, in turn, should appeal to QA managers.
As a result, all appellations are addressed, QA criteria get changed along with the reality your company lives in, agents are happy, customers receive better service, company gets more revenue – you know the drill, right up to smoothies.

And that's what we've learned about good and bad decisions in running the support QA process from our experience.
Max Sudyin
Co-Founder @ Swarmica

Do you have other thoughts on how to implement the QA process? Have questions about support workflow? Disagree with any statement from above? Drop us a note, we love to make anything about customer service better!