How to strive to be amazing at support (and fail at it every day)

Hi, I’m Kate, Close’s first full-time support hire. So if you’ve ever spent time clicking around Close and not having it do what you wanted it to, you’ve probably contacted me over support chat or email. If you have—I hope I’ve been helpful, but there’s definitely a chance I wasn’t. So, anyways, I got roped into writing a blog post about why that’s the case.

It’s nice when you always have the answers. And supposedly, that’s what support is. People have questions, you have encyclopedic knowledge. Bam. Supported. You are wonderful and amazing.

It shouldn’t be too much of a surprise things usually don’t work out that way.

You have no idea what’s going on

Support over the web is an exercise in asymmetric information. You know things the person seeking help doesn’t (Hopefully. Theoretically, that’s kind of why you’re doing support in the first place). The person on the other side, suffering through whatever problem they’re experiencing has the advantage of seeing things firsthand. The goal is to balance the scales—to be able to quickly grasp what’s happening and how the hell to fix it.

In a lot of cases, without some clever maneuvering, misunderstanding can be the default instead of something rare. You aren’t sitting at the other person’s computer. You’re sitting at your computer, reading someone else’s description of a problem they’re experiencing.

So you have to establish a basic understanding, where you’re sure you are both talking about the same thing. It can be as simple as subtle differences in vocabulary or description. (No, that’s not a new product feature. It’s just a customer’s quirky name for their company workflow.)

After a while, working with the same software (or whatever else), your team will cement a certain vocabulary. For consistency and clearness, you set certain ways to talk about different features or functions. But when it comes to hearing descriptions of your product from outside of that bubble, a lot can get lost in translation and you can get easily confused about what’s being talked about.

So when dealing with new issues, at some level, you have to assume that neither of you know what’s being talked about. Clarifying any differences in vocabulary can sometime be read as patronizing.

You’re not available

But web support has another type of inherent information asymmetry, one that is harder to fix. Maybe it can’t even be fixed. A lot of this imbalance comes from providing support virtually, removing cues that you’d get in a physical environment.

Picture the last time you’ve run the gamut of a real world customer service desk at a big box store, clutching some box of crap on its way back to its maker. After ten minutes of shuffling across industrial carpet on the way to hand in your receipt, you might’ve been frustrated, but you weren’t surprised. That soul crushing line you endured at least let you know there was a wait.

Providing support over the web, you present the idea of a virtual help desk: a line of zero. There are no more lines, but the waiting hasn’t dropped to null. To customers with questions, it might seem like you have one of those deli counter number dispensers that only produce ‘1’s, but that’s almost never the case.

This multiplies when you provide support over multiple channels. You can’t be constantly available if you are trying to juggle incoming emails, maybe some live chat, and the odd incoming call. All of that has to balanced against a continuing need to improve FAQs, analyze feedback, and expand your own knowledge of the product. Don’t forget to carve out some time to work on those.

No matter what you’re working on, there’s (almost) always a line for the help desk, it’s just invisible. Which sucks. It makes you look inattentive and just plain negligent. And it’s frustrating to those looking for some help. Why make yourself seem constantly available when you know that’s never going to be the case?

You don’t like numbers

Answer: You’d also suck at making the lines. That waiting queue over at Big Box Land is only a rough estimate, anyways. You have no idea if the person in front of you is going to take five minutes or fifty. It’s totally possible that the next hour of your life is going to be dominated by casually eavesdropping on the return policy drama five feet in front of you. What? You didn’t want to hear someone’s life story, bookended by receipts?

It’s true, in the real world, you have an idea if a help desk is busy or not. But you don’t always have reliable indicators of how busy. And it turns out those estimates are hard to make.

The time and effort it takes to resolve an issue aren’t predictable. Sometimes, it’s easy to make an assessment on how long it’ll take to get to the bottom of things. Other times, it takes a couple minutes of digging into a routine problem to find...that it’s a not a very routine problem and needs an entirely different approach.

You can have issues that require more information or follow-up from the customer. They may get back to you the next day (freeing you up to work on other things in the meantime) or provide an immediate response (taking up more of your current time, but also saving you from having to waste five minutes reacquainting yourself with the issue’s background later on).

So you’re left abandoning the idea of predicting waiting times, since it’s near impossible. It often doesn’t pay to make low-level predictions of support volume. There’s too many variables. The constant volume and difficulty make it a waste of your time. Your time would be better spent playing catch up with the stack of tickets you already have (and writing that blog post you’ve been putting off).

Numbers don’t like you either

Predictions are useful at the higher-level as they let you look at averages over time. Just be sure to regard the numbers as rough indicators instead of absolute truths. There’s a degree of natural variation and unaccounted variables. Small changes in numbers week-by-week likely aren’t significant.

Don’t let yourself be blinded by a very definitive-looking metrics page. It’s very easy to let the graphs and charts do the analyzing for you. Make sure to look at the the available numbers critically. Ask whether any changes are significant—and what exactly that means in the context of your work level and performance.

Plus, there’s no way that the metrics can capture all the dimensions of support. Hanging your performance entirely on them isn’t a well-balanced strategy. Basing everything off the stats would lead to spastic overcorrection. This kind of numerically-driven myopia would have you optimizing your workflow for your help desk software, not for the customers you’re helping.

Constantly tweaking workflow without real evaluation won’t really let you grasp the advantages and disadvantages of each iteration. You’ll abandon everything before you can determine if anything’s worth keeping.

It’s better to try to piece together a larger idea of your current performance from about as many sources as possible and then try to make evaluations from a distance. Don’t forget to include aspects of your support that aren’t captured by automatic statistics.

You’re not everyone

Sometimes, a large part of support is learning to convey your relative uselessness in the most even-handed way possible. You’re not going to be able to do everything. That’s why you’re working as part of a larger team.

A large part of some tickets is figuring out if you can’t figure it out and need to take it to someone in a different area. Good support is able to effectively screen issues beyond their scope and divert them to the people who can help. Doing that well requires an amount of collaboration between different specialities.

Support problems can easily reveal themselves to be engineering problems. Or sales problems. Or customer success problems. Rather than try to cut out any overlap, coordinate different areas so transitions from support to another area work smoothly.

Adding Engineering/Sales/Success perspectives aren’t just useful for support—it works the other way round, too. Understanding the volume and content of support can help inform development or update product demos.

Everything is terrible and that’s okay

And then there are time when you don’t have a good answer—and neither does anyone else. Sometimes shit hits the fan and all you can do is manage expectations and provide people with a sounding board to vent their frustration. If things fall apart, it’s important to keep everyone updated—but the scope of these updates is typically pretty limited. And typically pretty unsatisfying. No one’s happy and the best you can do at this point is assure them that you’re unhappy that they’re unhappy. (Easier said than done.)

Striving to suck less

Theoretically, the job of support is to be right, always. You’d like to be a specialized encyclopedia and an occasional help desk MacGyver. But a never ending to-do list and your own limitations turn that idea sour pretty quickly.

It’s a lot more helpful to adjust your approach. Change the focus to managing expectations (both for the customer and for yourself) and coordinating with other parts of your team (so the questions directed to support become fewer. Or better. Or tougher. Or at least different.). Support isolated from everything else is like being stuck in an infinite loop of questions. It’s completely okay to suck at keeping pace with the question treadmill. Now you can be motivated to work on improving the product, not the line for the help desk.