Tag Archives: customer support

Support Ops Hangout

I joined Chase, Carolyn, and Jeff on the Support Ops podcast yesterday afternoon. We talked about goals for 2016 and how to make the most of the new year.

With the Happiness team at Automattic we set some OKR-like goals for the second half of 2015 and made a lot more progress than we did in prior times. If that interests you I’d highly recommend this Google Ventures video about OKRs.

The audio version is live as well as the video recording. It was a lot of fun to join the podcast and I think it turned out well.

SupConf

I’ve worked in customer support for almost 9 years. When I started it was just something I enjoyed doing. I liked tinkering with technology and figured, why not use my experience to help others? Pretty quickly I realized I would be very happy if I could find a way to do this for a long, long time. Customer support is my career.

That’s why I’m beyond thrilled to help Scott and others plan SupConf, a conference for folks who want to build a career in support.

I’ve written before about how customer support, when done well, is a career. SupConf is about how to make that happen.

The event is May 23rd and 24th. It’s two full days of well-considered talks that will impart lessons for you to take back to your day-to-day work. Plus, we’re designing the event with conversations and opportunities to meet others in mind. Speakers are important, but they aren’t the whole event.

If that sounds interesting, I’d highly recommend signing up for the newsletter. In the meantime, you can read about some of the themes we’re looking to cover.

It’s time we think about support as more than just an entry-level job. Support is a career, a craft, and something to be proud of.

Customer success

Last week I tweeted about separating customer success/support/service teams. Today I read this comment:

This highlights something that is really important and that is the separation of Customer Success and Customer Support. In most ways, they are not related, they are opposites. Reactive vs. proactive, case-oriented vs. success-oriented, cost-center vs. revenue-driver, etc. It’s one of the reasons that Customer Success won’t (can’t?) work if it’s part of Customer Support.

Opposites? Fuck that.

I try to give people the benefit of the doubt. At a certain point, though, enough instances of something becomes a trend. And the trend I’m seeing in conversations about the customer experience is deeply frustrating.

Too many people who lead “Success” teams seek to define all the valuable pieces of the customer relationship as Theirs. They draw a line in the sand and say, “This is my fiefdom. Back off.” In doing that they push all of the labor and time-intensive aspects of the customer experience onto someone else.

Replying to support tickets becomes not about the opportunity to have meaningful conversations with your customers. It pushes support into a box that’s solely a cost-center, case-oriented, and unconcerned with helping customers successfully use your product. As part of this success-advocates elevate their teams as somehow inherently above and better than those mere peons who handle tickets.

That’s crazy! Even the most reactive, labor-intensive ticket represents an opportunity to earn goodwill with your customers. When you nail that experience you can create a ripple effect across revenue, social media, and the broader marketplace. That is customer support. It’s only an opportunity, though, if you choose to seize it. If you chalk support up as just a cost-center, that’s your loss. Good riddance.

This whole trend of customer success is a tired repetition of customer support as an entry-level-dead-end job that people simply seek to move out of. Customer support, when done well, is a career. Every conversation, whether it’s reactive or proactive, is an opportunity to learn from your customers. That is immensely valuable no matter your departmental definition. Every time you try to isolate certain elements into a single department and declare that proactive support won’t, and cannot, work with customer support you do the broader community harm. Every one of us is in this to help people succeed.

Scaling support teams

A couple weeks ago I was talking with other customer support folks about pain points in quickly growing a customer support team. Our team at Automattic has grown quickly since 2012, when we had around 16 Happiness Engineers. We hired close to 40 support people in 2013 and over 25 in 2014. Our job posting is always up and our only constraint on hiring is the pace at which we can find the best Happiness Engineers.

In talking through that experience with other customer support people I shared a few lessons from Automattic’s growth. These are just things I’ve found to be true about a high growth support team so your mileage may vary.

Maintain your hiring standards

As you grow you desperately need to maintain the hiring standards which formed your team. This is particularly the case if the impetus for growing your team is exploding support volume, management pressure, or a growing user base. With that pressure you become inclined to compromise on hiring standards in order to achieve faster growth. Those borderline candidates who you’d reject 6 months ago you’ll now think of as, “But we could train them…” While that may be the case every borderline candidate you hire ultimately slows down the team while they wait to catch up. Our hiring motto at Automattic is that a “Maybe” is a “No.”

The 6-month speed bump

When you hire a lot of people over a short span of time you also create a lurking iceberg of expectations. New jobs come with a honeymoon-like period. A new hire clearly wanted to join your company, else why would they have applied, and now that they’ve been hired everything smells like roses…for a while. If you hired 6 people in April that also means you’ll have 6 people coming out of that honeymoon period come the fall. Compound that by hiring 6 people a month for 6 months and, boy, is that iceberg massive! Be aware of this. It’s not to discount valid critiques from those team members, but it does need to be taken in to account. Sometimes this week’s fire is merely 6 people simultaneously hitting a given point in learning what works, over the long run, for their productivity.

Here’s one way that collective 6-month speed bump plays out. When people join their first distributed company they love the seemingly boundless freedom. They love their work, love working from home, love the schedule flexibility and dive in whole hog. Pretty soon, though, they realize that they’ve lost all discipline in setting work aside. They find they let pings interrupt them at all hours. They find themselves working 60-hour weeks. They find that they have no quiet time. When you have many people simultaneously hitting this inflection point it can be expressed as an issue with company expectations or with the team itself. You have to take a step back, though, and realize that this is a growth process everyone goes through. You have to help each person realize that, in part, the problem is one of individual expectations, workflows, and discipline. If instead you restructure the entire team in response to this pain point you ultimately withhold from people a learning experience that helps them build sustainable and healthy individual remote work habits.

Teach systems, not information

If your training focuses on simply teaching the information necessary to do the role then you’re creating a burden of technical support debt you’ll eventually need to repay. The most common way I’ve seen this come up in support teams is new hires consistently asking for a list of who owns what features across product teams. If you’re a small, agile, or continual deployment-driven company this type of list is a wild goose chase of sunk costs. The effort required in maintaining that list is crazy, particularly if your product is fairly involved. Instead, focus on teaching new hires the systems they need to learn in order to discover for themselves who owns what feature. How can they leverage the source code repository? How can they lean on the bug tracker? Do they simply need reassurance that it’s ok to ask? When that systemic knowledge becomes second nature then it frankly doesn’t matter how fast the development side of your company is moving. Your support team will be able to keep up and keep pace with where to report bugs, suggest improvements, and ask for help.

Be wary of past experience

This is similar to being mindful of the honeymoon period. Part of why you’ve hired this team is the strength of their past experiences. However, when people start out they see pain points at your company which were solved problems at their past job. While a fresh perspective is valuable, be wary of someone’s desire to solve an issue using the same process their past job did. Your company is your company. It’s not the same marketplace, culture, tools, people, systems, users, or challenges as any other company. Ultimately you want to be wary of new hire-driven solutions which seek to merely transpose past solutions on to new problems.

Thanks to Erica and Simon for helping me edit and compose these ideas.

Three types of support

When you’re working through a queue of support threads it can help to identify what type of question the user is asking. Doing this helps set the tone for how you approach your reply. In my mental model there are three broad types of support questions.

Users typically ask educational, technical, or transactional questions. Knowing which bucket their question falls in to helps guide your actions.

Educational questions boil down to unfamiliarity with the product. Your goal is to help the user connect the dots. You’re teaching them about how your product works and how they can use it to meet their project’s goals. Take these questions as an opportunity to point users to best practices, existing documentation, and ways they can get continued help.

Technical questions happen from a breakdown in expectations. A user knows what they want, but your software is hampering their ability to get there. Your goal is twofold: help the user get around the issue they’re facing and fix the root cause so it doesn’t happen again. These questions represent an opportunity to dig in to bug details. Maybe it’s an edge case. Maybe it’s widespread. In any case don’t just dismiss the question as a one-time error without verifying that it won’t happen again.

Transactional questions happen any time there’s an issue with purchase-related actions. When you accept payments you will get loads of questions in this bucket. Customers will want refunds, their cards won’t process correctly, they’ll want to pay by purchase order, and more. The goal here is to get the money issue sorted out as quickly and smoothly as possible. There’s no faster route to losing a customer’s trust than making payments and refunds difficult.

At its core, support is requests in one of these areas.

Before you reply to someone it can help to find what area they fall in to. The appropriate language, personality, and content all changes based on that. If someone’s question boils down to a transactional issue you’re better off handling the issue directly. They don’t likely want to read documentation about how to get a refund, for example. Next time you’re working through a queue of support threads ask yourself what type of question you’re answering. Doing so can help ensure you match your response to the user’s primary goals and concerns.