I’ve spent most of my IT career in various support roles. I started in help desk (answering support calls on a small scale), moved to sysadmin (calling support), to Level 1 technical support (answering the support calls on a much larger scale for basic stuff), to level 3 support (escalations, supporting the support guys), to my current role as technical marketing engineer (where I support our sales/field people, as well as our tech support guys on occasion and even our engineering teams). I have around 15 years of experience doing this, so I figure I’d pass some of the lessons I’ve learned on to others.
Regardless of what you hear or have experienced, know this – every support center has its warts. Every support center also has its rock stars. Some have more of one than the other, but they all employ similar tactics to drive costs down.
Level 1 support
These are the people taking the initial calls in most cases and are the first people you talk to. Unfortunately, they are often the least experienced and/or qualified. They are the first line of defense and act as filters. The reason? It’s a numbers game. Most support calls fall into one of the following areas:
- Questions answered in documentation
- Questions about support accounts/entitlements
In some cases, 80% of calls fall into one of the 3 areas above. These are the issues that require the least amount of expertise and can be solved the quickest by the lowest paid support people available. Naturally, most companies (particularly large ones) want to weed out these questions as much as possible because 30 minutes of an engineer’s time that makes 40k a year is cheaper than 15 minutes of an engineer’s time that makes 100k a year.
However, this creates a problem of “first impressions,” where customers have to deal with engineers that may not be able to handle their issues efficiently, and that sours their over all opinion. Maybe a company sends all of their level 1 calls from the US to a country where English is not the first language. Maybe the company only has all their new hires answer the phone.
We’ve all had to deal with it, from our cable companies to our enterprise IT.
Follow the Script
It’s one of the worst kept secrets in support – the script.
It’s blatantly obvious to customers, and it kind of irks them to hear a recited list of questions. But don’t take it personally. They’re used by so many support organizations for several reasons.
Proven: The scripts are carefully crafted to cover a lot of the most common scenarios support engineers run into in hopes that the problem will be solved before the script is finished. This includes “is it plugged in” type of questions, so be patient.
Consistency: We always get the same data up front, regardless of engineer.
Costs: It saves time and money to get the right data up front. And the most common factor in support is lowering costs of operation.
Rather than fight the scripts, embrace them. Ask for copies of the scripts so you can fill them out ahead of time. Some companies even have their scripts available on their support sites!
And be patient when going through the script. It’s a necessary evil.
Rules of Engagement
Many companies will have a set of rules for opening a support case and keeping it open. Some charge per case opened. Some (mostly startups) will take any and all support cases because they’re small and agile enough to handle the load. But they all have some sort of rule in place, so be sure to know the rules up front. These rules are designed to keep the case load at a manageable level and allows the support centers to scale appropriately. They are also designed to drive specific asks to other parts of the company for more appropriate handling.
Once you know the rules, it’s time to make the call…
Make the Call: Don’t Wait Too Long!
The time it takes you to pick up the phone depends on your own experience and confidence/self-awareness in your own knowledge. If you don’t know a product or simply don’t have time to spend on figuring an issue out, you call support pretty quickly. If you are confident in your abilities and just like tinkering, you might not call support for weeks. That fact is important to keep in mind, as it can affect your overall psyche and perception of how long an issue has been going on and the patience you have with technical support.
For instance, if you work on something for 3 weeks and it’s still not fixed, you might be frustrated (as might your boss). As such, you might take that frustration out on the poor support engineer when it’s really not their fault. It’s a good idea to get support engaged as early as possible in a problem, regardless of how much you might know. That allows more eyes on a problem, and perhaps you might learn something you did not know as you go.
No, Seriously. Call.
Pro tip: If you find yourself emailing with a support engineer repeatedly and it’s generally one or two line conversations, then you need to pick up the phone. You will save SO MUCH TIME and agony. Email is not the best way to solve complex issues. There is an illusion of simplicity with email, that we can multi-task and still fix things effectively. It’s a lie, and this is coming from someone who hates the phone.
The slogan of the Boy Scouts of America also can apply to pretty much anything you do in every day life, including calling tech support. When you call, always have the following information readily available.
- Serial numbers/support contract info
- Contact information for the person on the support contract (hint: it might not be you!)
- Detailed description of the problem (it’s slow is an awful description)
- What you’ve already tried
- Pre-populated script du jour from the support org
- Data collected during the issue occurring
- Documents you’ve read (AKA, RTFM)
Getting the right information up front is essential to a successful and efficient support experience.
You are the Customer!
You paid for the product and/or support. So you are entitled to get what you paid for. Work with the support engineer to get the problem solved, but don’t roll over. A support engineer’s goal should be to fix your issue, but sometimes, their goal is just to close a case. Always make sure that recommendations, especially ones that sound odd or possibly disruptive, are backed by data, explanations and are vetted by a 2nd set of eyes.
For some color, I’ll tell you about an experience I had as a sys admin with a storage company’s support center.
I had 2TB of backup data on a LUN connected to a Windows server. I wanted to expand the LUN because I was running out of space. I called the support org to get help doing this.
Their recommendation? Convert the LUN from MBR to GPT. That sounded… weird to me. This was 10ish years ago, so Google wasn’t nearly as good (and neither was I). But my spider sense was tingling…
ME: “Will that cause me to lose any data?”
SUPPORT PERSON: “No, you’ll be fine.”
ME: “You sure?”
SUPPORT GUY: “Yes!”
ME: “Okayyy…. *converts LUN partition, loses all data* “WTF YOU JUST COST ME ALL MY BACKUPS.”
SUPPORT GUY: “uhhhhh… stammers…”
So yeah. Always assume the following three facts about support:
- They know what they are doing.
- They don’t know what they are doing.
- The customer is not always right, but they’re also not always wrong.
It’s a two-way engagement. While it was ultimately the support person’s fault I lost my backups, it was also my fault for blindly following him.
Question everything. Demand written proof. Be suspicious, especially if the words “best practice” are used without supporting documentation.
What I should have done was….
(1) Escalate, Escalate, Escalate …
When you are having issues with the support engineer you currently have, you need to escalate the case. This is done by requesting to speak to a manager. If you are an enterprise customer, you can get your sales guys to do that for you in most instances. You might not get an escalation resource necessarily, but you might get someone who is more suited for your issue.
Some valid reasons to escalate:
- Not getting timely responses to questions.
- Only getting emails.
- Getting questionable advice and questions that suggest the engineer might not know what they are talking about.
- Being bombarded with documents/links that don’t really relate to your issue.
- Being pressed to close a case before it’s resolved.
It’s important to remember, again, that a support call is a two-way street. You have to be responsive to questions and data requests to keep a case moving. If a case starts to get stale, it might be time to try a new approach.
(2) Avoid assumptions
As I’ve mentioned, support organizations are looking to solve your issues as quickly as possible. This is because it creates happy customers, which makes for return customers. It also saves money to close cases quickly. That’s why you see pre-canned scripts, level 1 engineers, etc. But don’t assume the first person you talk to is clueless. A lot of engineers (I’d say most) are perfectly capable of solving your issue on their own. When I was in support, I’d run into all sorts of people that would call in and assume that I had no idea what I was talking about simply because I had been the one who answered the phone.
Be patient and talk with the engineer. Gauge their knowledge. Make an informed opinion.
A funny side note… when I was in support, we had a customer who would actually quiz the TSEs when they called in. If they could not answer a set of 3-4 questions, the customer would hang up on the TSE and put them on a blacklist and then call back in, hoping to get a new TSE. (I never got put on the blacklist, FWIW)
(3) Support vs The Food Industry
There’s a common notion I’ve heard about how you treat people in food service, and how it’s a direct reflection on who you are as a person. Food service employees are looked down upon, and in some ways, so are support folks. Support is a thankless job – no one calls in to tell you how awesome the product is – and when you add on frustration with the product not working, it can make the job even tougher. Treat the support engineer with the same professionalism you would use with a co-worker.
Remember, we’re all on the same team here. Be excellent to each other!