Many of us are in support, whether we’re supporting end users, internal users, a public facing service… our families, friends. You’re supposed to know it all, right? Until that dreaded moment, where you need to escalate to vendor support. At this point, a gnawing pit of anxiety rises from the depths of your gut as you realise the horror that is about to unfold upon you.

As an IT professional, I’ve found fewer experiences more frustrating than dealing with vendor support. Even when dealing with the hallowed ‘Partner Support Channel’ you still inevitably feel like you’re trapped in an IT Crowd script, turning it off and on repeatedly for person after person, only to finally give up in frustration and just do something totally different instead.

So why exactly is it so frustrating? Is it inevitable? Let’s explore some of the key ingredients.

Technical ability

Fundamentally, you need the person you’re dealing with to understand the problem you’re describing and understand the product well enough to add value in the troubleshooting process. If you’re having to describe the issue repeatedly using different words, then chances are the person doesn’t actually understand the issue.

As an IT professional you need the person at the other end to be sufficiently technical to actually improve the situation.

How long is the leash?

You also need the person to be allowed to help you, in the manner that you need. It’s no good having ‘IT Einstein’ on the line if they’re not actually allowed to troubleshoot and dig into the problem.

For example, many vendors won’t allow their support staff to actually ‘touch’ things. They’re allowed to draw red circles around where you should click next, but not click themselves. They can ‘message you’ what to copy/paste into the command line, but can’t type it themselves. They’re under pressure not to escalate the case. Because it’ll make them, and their supervisor, look bad.

The situation gets worse with cloud, because any issue that doesn’t involve PEBKAC is probably a bug. Or a limitation. Either way, there’s no way the frontline support team will have access to the logs necessary to troubleshoot the issue — because anything important that they actually touch now potentially impacts thousands of people. I mean, what could go wrong?

‘Solving’ the problem might also involve admitting that something doesn’t work as advertised, but they’re not allowed to say this. Or it might have financial impact — maybe they should provide a refund because the product or service simply doesn’t work? But if the person at the end of the line isn’t able to make these decisions, then you end up in a frustrating Monty Python sketch starring you.

Ownership

If you can remember a problem to which you didn’t know the answer right away, but where you did get there in the end, chances are it’s because you kept at it. You kept trying things, digging, scratching, researching, testing things. Contacting people you know and asking, “Have you seen this really strange thing?” Or creating an account and replicating the workflow/problem yourself.

In short, you took ownership of the problem, and ownership of seeing it through to the end.

The vendor interpretation of ownership is skewed. The people you’re dealing with will (usually) keep in contact, unhelpfully asking if the issue is now resolved and can they please close the case now? The person you’re interacting with is measured on metrics, such as how many cases did they close, how long to close, customer satisfaction rating, etc.

These all sound great, except that the person you’re interacting with is incapable of fixing the problem and basically they’re trying to very politely make you go away.

If the person actually had ownership of the problem then this would upset them. They’d want to understand why feature(x) doesn’t work as advertised. Or why it is simply missing. Or why it deleted all your important stuff.

Communication

Most of the people I speak with have great English, both written and verbal. The immediate communication problem is that they’re on the other end of a poor-quality VoIP service, and communicating simple messages takes far longer than is reasonable.

Most of the vendors I’m dealing with are large, very large. They’re amongst the largest, most profitable companies the planet has ever seen. And they choose not to provide a telephony service for their support staff that enables them to communicate effectively with the customer.

This I find truly staggering — the incremental cost of a good international VoIP service versus a poor one is tiny. Yet the situation persists.

Another communication evil I frequently come across is that the support person won’t read the carefully summarised troubleshooting/diagnosis/data that’s been provided to them, and instead makes you repeat the process over several sessions/days/weeks/months to ultimately end up with the same information.

So how did we get here?

It’s easy to see the reasons for why we arrived here. Whether you agree with the solutions or the reasoning is up to you, but this is where we are:

Problem: Someone clicked something they shouldn’t have. Solution: No-one can ever click anything ever again.

Problem: People are unhappy with support. Solution: Be super nice and keep asking if the customer is happy and can we close the ticket please.

Problem: Things are complicated. People get things wrong. Solution: Make every problem fit into a small box that you design.

Problem: Support isn’t valued. Solution: Get cheaper resources.

So where do we go from here? I hope that providing better support becomes a priority. Whilst I personally prefer working with an interested, engaged and capable human being at the other end of the line, I would also be happy if an AI system could actually solve my issues.

If you do get good support, make sure you let the person know. And their supervisor. And their supervisor’s manager. Tell them what was good about the experience. Explain how this now makes you more likely to recommend their product/service and be a ‘net promoter’. Take ownership for improving the overall support ecosystem, from the customer side of the bench.

And one last suggestion — hold up a mirror. Make sure that you’re not subjecting your end users and customers to the same.