New initiatives are hard to adopt, even when they’re good for us.
Exercise improves our fitness, saving money prepares us for the unknown, and support quality assurance drives better customer service outcomes.
Yet in spite of support QA’s many benefits, many organizations either don’t QA effectively or don’t bother with QA at all.
It’s not that these organizations don’t care about improving their service delivery. It’s that there’s always some seemingly valid reason to avoid getting started.
The truth is, launching your own support QA program is tough, but it’s not impossible.
Here are four common challenges of support QA––and what to do about them.
1. Too much data
Inbound ticket volume can vary depending on industry, the nature of your product or service, and time of year. Still, it’s not uncommon for support teams to field hundreds of customer service requests each week.
One study from JitBit found agents can handle an average of 21 tickets per day. Multiply that by 5 for each agent on your team and the data challenge is obvious:
- How can you possibly review all those tickets?
- How do you know which tickets to choose?
- How can you be fair when choosing and evaluating tickets?
Solution: Choose a random sample of conversations to review
For most teams, reviewing every agent-customer interaction is not only unsustainable, it’s unnecessary.
A survey of more than 300 support organizations found that only 11 percent of those who practice QA review all tickets, while 72 percent use random selection.
To make sure you’re getting a representative sample, use your team’s most popular CRM tags to pull agent-customer interactions across ticket types. This might include:
- Technical support
- Refund request
- Password assistance
- Shipping status
- Product issues (i.e. bugs)
2. Not enough time
Successful QA programs thrive on consistency. They require continued enforcement to remain relevant, and continuous refinement to stay effective.
But most leaders believe they lack the bandwidth for additional responsibilities.
From cross-departmental meetings to weekly one-on-ones, the rigors of managing a team and getting their own work done can make even the most ambitious support leaders shy away from new initiatives.
Especially an ongoing commitment like QA.
Solution: Make time for the work that matters
The biggest threat to getting things done is our attachment to the status quo.
In their study of how knowledge workers can become more productive, Harvard Business Review found that, on average, we devote almost half our work time to discretionary activities “that offer little personal satisfaction and could be handled competently by others.”
They recommend using the “Start, Stop, Continue” method to identify these low-value tasks and decide whether to drop, delegate, or redesign them.
For your QA program, this could take two forms:
- Delegating non-QA responsibilities to other team members and handling all QA-related tasks yourself––initially
- Delegating some QA responsibilities to a support supervisor, team lead, or a few choice agents
If you choose the second option, your teammates might help with:
- Choosing and organizing random customer conversations for review
- Collecting and reviewing any conversations volunteered by agents
- Scoring conversations based on a support QA rubric you provide
If you choose the first, plan to off-load at least some of the burden once you’re comfortable with the first version of your QA process.
3. Negative team perception of QA
No one likes feeling watched, especially when doing their job.
If your support team’s never dabbled with QA methods, the idea of having their conversations reviewed and scored on a regular basis is enough to put agents on edge.
This is especially true for teams who have only experienced QA as the byproduct of a customer complaint or “incident.”
When conversation reviews are associated with trouble, agents are even more likely to become nervous––and possibly resentful––about the prospect of having their performance scrutinized.
Left unchecked, collective mistrust will eventually lead to low morale.
Solution: Explain how QA benefits everyone, especially agents
Being utterly transparent about the goals and purpose of your QA program is the best way to turn skeptical agents into enthusiastic co-owners.
This means explaining how each piece of the QA puzzle fits within larger company goals:
- Reducing churn / driving customer retention
- Building a reputation worth bragging about
- Earning executive support to invest in the team
It also means creating a vision agents can’t help but embrace by defining what’s in it for them:
- More objective appraisals of their performance
- Transferable people skills that enable them to excel during tricky conversations
- Additional promotional paths and opportunities for recognition
Quality assurance shouldn’t feel like blame assurance. Frame QA as both a learning experience and huge opportunity for everyone involved––because it is.
4. Siloed software tools
Most support QA programs start in spreadsheets.
These early-stage initiatives rely on a mix of different tools and documents to track their progress across channels.
As a result, support teams with manual QA programs spend considerable time setting things up––time that would be better spent coaching agents.
This might include:
- Collecting and organizing conversations from each support channel
- Cross-referencing conversations with QA rubrics and online survey tools
- Plugging relevant data into spreadsheets for each agent
As a business grows, this level of upkeep renders QA less efficient––and less effective. When conversation reviews happen weeks after the actual conversation, you can’t address problems in real-time, when it’s most relevant.
Over time, delayed feedback increases the odds of negative customer interactions continuing unnoticed.
Solution: Get the process down first
Purpose-built software can solve for inefficiencies––and should be your ultimate solution––but new technology won’t guarantee success on its own.
Despite being more difficult to manage, the beauty of working within a manual system is that it’s tailored (albeit poorly) to the needs of your support team.
Buying a QA tool without testing the QA process could mean taking on procedures that aren’t optimal for your organization.
But if you can endure the clunky confines of manual QA, you can also sketch a sustainable process that enables you to confidently purchase a tool that supports it.
As for when to make that leap, most teams hit their breaking point once they’re between 10-20 agents.
Taking the next step
Building a quality assurance program for your support team doesn’t need to be an ordeal. Run a simple test to get started. Step 1: Choose one conversation to “review.” Step 2: Make note of what works well about the exchange. What could work better?
Keep these judgments handy––they’ll lay the groundwork for your support QA .
Enjoy this post? You may also like these:
Thank you for subscribing! We'll respect your inbox.