When there has been a deliberate change though—one that is important for future development and that almost certainly won’t be changing back—then that sort of apology can be counter productive. If you know that a feature has been removed and is gone for good, it’s unhelpful to offer false hope to a customer of “recording your feedback” and “voting for that to be returned”. It will probably never happen.

Stop apologising to customers and start leading them – Mathew Patterson.

I’ve always believed that the key to creating great software is to talk with those who use it, to understand what they need and want from your product.  If you step away from support, your software will suffer.

You can, however, step away from bad customers.

Some Customers Suck – Nick Bradbury. via Sheri

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.

Customer service is difficult, expensive and unpredictable. But it’s a mistake to assume that any particular example is automatically either good or bad. A company might spend almost nothing on customer service but still succeed in reaching its goals.

Customer service succeeds when it accomplishes what the organization sets out to accomplish.

What is customer service for? – Seth Godin.

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.

Live Chat and Lean Manufacturing. My co-worker Simon ponders the similarities between live chat support and continuous-flow manufacturing. Beyond number of questions answered the piece which intrigues me is completed problem sets. In other words, define a complete customer problem set as ABCD. What percentage of live chats work through that complete set versus what percentage have the customer bail midway through? And, how does that compare to email support?

I told Doc we had arrived at the Holy Moment in debugging — reproducibility. I told him “reproducible” is the programmer’s favorite word. If you can tell me the steps to reproduce the problem, then I can find it and fix it. Until it’s reproducible all I can do is share your frustration.

Dave Winer – Reproducible.

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.

But the greatest wild card of all in all the data, and the most precious piece of information for any happiness engineer hoping to solve any ticket, is the customer’s own perception of what is wrong. And the gap between what people think is wrong and what is actually wrong can be quite far indeed.

Scott Berkun – The Year Without Pants.