Best Technical Support

Technical support teams today are so evolved, with their tiers, and their specialists. In fact, a multi-tiered support system, instead of one general support group, does provide the best possible service in the most efficient manner.

However, multi-tiered technical support can actually degrade the quality of your service if agents don’t maintain a clear and strong sense of ownership over problems. Using tiers as an excuse to pawn off problems slows resolution times, frustrates customers, and lowers NPS. It also wastes opportunities for engineers to grow and improve their skills.

So, what’s the big threat to ownership, and how do you combat it? Let’s look at the issue in greater depth, and learn from some examples from my experience managing a team of technical support engineers.

Multi-tiered technical support is awesome

In multi-tiered technical support engineers are grouped based on their skill, and tickets are routed to the best engineer for the incident. But, like all such systems, multi-tiered support alone cannot guarantee accelerated ticket resolution.

So the collaboration model was born, which we could call ‘tiered support 2.0.’

Instead of just having three or four layers of engineers, tiered support 2.0 takes the severity of the problem and importance of the customer into account before assigning an engineer or group. This means we may have more than one group within each tier.

It’s not my problem anymore.

The problem occurs when you combine multi-tier tech support with the pressure to solve tickets quickly. Sometimes agents focus on getting rid of issues rather than resolving them.

This type of situation comes up most often when we are troubleshooting different technologies with one product, which is my situation.

A recent incident involved a backup failure on system state. During troubleshooting we found that the volume shadow copy was in a failed state and the VSS error was related to the operating system. Thus, it would have been easy to ask the customer to contact the support desk for the operating system, passing the customer off to them instead of solving their problem ourselves.

But that’s making “It’s not my problem anymore” the goal.

It’s obviously not good for the customer either. Waiting for a resolution and getting passed around from support group to support group because the engineer is not focused on resolving the problem is not a good feeling and will have a negative impact on your Net Promoter Score.

Another way agents and technicians will make an issue “not their problem” is to ask a team member for help, then drop the ticket.

For example, while reviewing one of my engineers’ queue I found one ticket which he had not worked on in three days. He was troubleshooting and found that he couldn’t solve the problem on his own. So he contacted the specialist, explained the problem, and shared the logs and his findings. When I asked him about it, he told me he was waiting on the specialist for the next action.

Simply waiting on other lines of support is a huge source of technical support delays. One group will wait for the next line, or the front line will wait on the advanced line for next actions. Meanwhile, the tickets get old and your average ticket resolution time shoots up and away.

Going back to the first example; if the goal had been to just get rid of the customer, the solution would have been to ask the customer to contact support for the operating system. But the way to actually solve the issue was to debug further and do some research to find if this VSS error itself was caused by our application. Then, if we found out it was, to get in touch with the OS vendor along with the customer and troubleshoot together.

The first way is a “It’s not my problem anymore” approach. The second, better one, is a “It’s not problem anymore” approach.

Trying to offload problems instead of solving them binds and limits our thinking. Passing off a problem doesn’t teach you anything, except how to weasel out of work. Like watching TV instead of working out, it feels good in the moment but over time you’ll get bored and realize your skills are atrophying.

Take ownership

Owning an issue means whether it’s a new issue or one recently transferred, that it’s still your responsibility.

As engineers, we need to be very conscious about owning our issues. When we embody an attitude of ownership over our outcomes, we work with a sense of purpose.

Getting resolution requires focus, passion, and a sense of responsibility. That doesn’t mean we can’t collaborate with others or even escalate to the next level when we don’t know how to resolve an issue.

However, we must learn to collaborate with a team or escalate to the next level while maintaining a sense of ownership of the ultimate outcome. At the end of the day, even if you get help, you are the one taking care of the customer.

The other attitude that leads to success is considering every challenge a learning opportunity. When you work with people on your team, instead of just moving on to other tickets, take time to learn from them. You can also learn from other teams, like with the example of the OS support, above. It’s always good to know how to solve problems, even if they’re not your specialty.

Refuse to wait

If you’re a level-one engineer you may need help from different groups. That’s the point of multi-tiered technical support. And sometimes that means you may have to wait on them. That does not mean you have to stay dormant. Be impatient. Sure, this word might have a negative connotation, but impatience is a virtue when it comes to supporting customers. Think of it more like “an eager desire for relief or change; restlessness” or “intolerance of anything that thwarts, or delays.”