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.

Survey fallacies

Support teams are frequently tasked with figuring out “what the customer wants” with some sort of pre-defined survey. As if a well-constructured set of questions will miraculously fix latent problems in the product.

My two cents: a survey is only worth doing if the product team is willing to devote non-trivial resources to what the survey illustrates as meaningful improvements to make. Without that commitment you’re just wasting everyone’s time.

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.

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.

Verizon Live Chat

I shared this on Twitter earlier but wanted to log visually here. Verizon’s live chat support has three shockingly poor things wrong with it.

The text is large, blue, and Comic Sans.
The text is large, blue, and Comic Sans.
The form is broken in Safari as you get this big bar over the text field.
The form is broken in Safari as you get this big bar over the text field.
The tab title is "Engagement Window." Eww.
The tab title is “Engagement Window.” Eww.

I reported each issue to them, of course. Unfortunately they said, “we do have issues with the Safari browser” and suggested I use Internet Explorer.

People will read

Last July Ryan Pitts and Sara Schnadt led a session at SRCCON about human-driven design. It wrapped up with a discussion of various maxims that guide design processes. Someone in the room said it was important to remember that, “users won’t read, ever.” That rubbed me the wrong way at the time and I went on a mini-rant in the session. I was thinking back to this recently and wanted to sketch the idea out into a longer post.

The perception that people don’t, and won’t, read documentation is not uncommon. There’s a reason we have the acronym RTFM after all. I think it’s a perception that’s horribly misguided and short-sighted for your product.

People will read. What they won’t do is unquestioningly read on your terms.

Treat docs as product

When you’re developing a product you don’t ship something and passively wait around for it to become popular. If what you shipped isn’t gaining traction you iterate. You tweak and adjust until your product fits its addressable market.

For some reason we don’t approach documentation with the same mindset. Our predominant expectation is that we can ship docs and expect every person to read them. If the docs have up-to-date screenshots, are detailed, and are searchable then that’s enough. If people don’t read, that’s their fault not yours. That’s a fundamentally broken expectation.

Most importantly, if you react to support requests by wondering why people can’t read the docs then you are missing a golden opportunity. You are directly blaming the person using your product instead of blaming your product for requiring documentation in the first place.

Exploratory & Prompt-Driven Users

Part of the RTFM-mindset stems from an assumption that everyone is an exploratory learner. That’s wrong. It’s arguably true for many tech folks. That doesn’t make it true for many people using our products.

Exploratory people will find their own way. They are comfortable with uncertainty. They’ll use a confusing product and feel confident relying upon documentation for answers. To them this is part of the appeal. Each awkward setting or obtuse workflow is an opportunity to master the intricacies of yet another product.

Prompt-driven people will read docs, but it’s not their default. They will first look to your support team for help. You could also think of them as human-reliant people. Interactions with your support team may prompt them to read and reference docs. So it’s not that they won’t read. It’s more that they prefer human interactions to help guide them.

Here’s the thing about prompt-driven people: they are a potential gold mine of qualitative feedback. There is no better source of information to help guide your product teams. Yes, this means your support team has more tickets to respond to in the short-term. That’s a great thing.

Every one of those interactions is an opportunity to learn more about how people use your product. If you choose not to take advantage of that and instead blame people for not reading your docs and leaving you alone in your cave, then that’s your loss. The next time you find yourself blaming a customer for overlooking the “obvious” answer in your docs, ask yourself whether you’re reading enough of what they’re telling you. More often than not I think it’s those building a product that don’t read, not our customers.

Thanks to Simon for helping clarify some of the wording in this post.

The software I use

While answering some “What do you use for…” questions the other night Daniel suggested I write up a recap of what tools I use. He wrote something similar a few days back and it was interesting to read through.

During the day I’m helping organize and lead our various support teams at Automattic so the bulk of my time is spent writing, talking with people, and helping out with projects that come up. All of that requires pretty simple and lightweight tools.

My day-to-day communication all happens through two tools. Much of it happens through various P2s which we have setup for every team, major project, and area of interest within the company. If you’re not familiar with P2s Matt wrote a bit about how we use them. Or, go pick up a copy of Scott’s book. All of our chat then happens through Slack, which we use for both 1-1 and group text chats. There are stats built-in so I know I’ve sent just over 35,000 messages since we started using it about 5 months ago.

The upside to P2 as a core tool for me is that I’m in control of how I follow and receive updates. I follow about 50 internal sites and use email to keep up with posts and comments. Everything is routed in to 3 separate folders that group posts and comments by relative priority. For all this email I use Mail.app. It’s the only mail client that’s ever felt “right” to me. I can’t stand Gmail on the web and get distracted by having email in my browser.

Safari is my primary browser. I had used Firefox for ages but with the release of Yosemite I’ve gone back to Safari. It’s really clean and performance-wise I don’t notice any difference. Plus, the only browser extension I rely upon is 1Password.

Like Daniel I’m a huge fan of Bartender. It keeps things so much more sane up in the menu bar. Up there I have a few things running:

I use Things to keep everything organized. For the last 6 months or so I was using Omnifocus. Along with the Yosemite upgrade I took a chance to re-evaluate my tools and decided Things just fit better for my usage. I’ve used it ever since the initial beta tests and have always found it fits my mental model of tasks pretty naturally.

Outside of tasks I use the native Calendar.app to stay scheduled. iCloud syncs everything over to my phone. For notes I use Simplenote for some things and FoldingText for others.

When I do need to code I use Coda. Any coding is just for personal projects and I find using Coda means I have just one tool to remember. It’s not for everyone but it works wonderfully for me.

Divvy is always running in the background, helping me keep windows organized and arranged. There’s something pleasing about having windows set to a grid.

I make sure to do some direct customer support once a week, too. I usually set aside one afternoon for that. It’s always done with our live chat team, which uses Olark. They’re good folks and the web-based chat client is pretty slick.

In terms of hardware I’m using a mid-2014 MacBook Pro, with the retina display of course. Spec-wise it’s got 16 GB of RAM and a 256 GB SSD. Performance-wise it’s more than I need most of the time, but I like using machines for quite a while. My last machine, an 11″ MacBook Air, lasted 3.5 years. I went with the 13″ model because the weight is pretty darn minimal. It’s the only screen I use, too. I stopped using my Cinema Display after upgrading to this laptop. The biggest benefit here is that my home setup is identical to my travel setup in every way. Consistency is nice.

This all makes me think I should do a mobile-specific version of this post, too. Perhaps later.

The Old Guard

The Old Guard is the cultural bellwether of the company. I believe that culture is a slippery thing to fully define, but I do believe it is the responsibility of the Old Guard to not only take the time to define the key values that are the pillars of that culture, to communicate the nuance of those values over and over again, and, lastly, when it becomes apparent they are no longer serving the company, they must be willing to let those values evolve.

Rands writing about The Old Guard.