Probably the most important key to providing top-notch customer support is empathy. What better way to empathize than to acknowledge and to accept responsibility when your customer has been let down? You guessed it: apologizing.

1) Validation

Make sure to apply this empathy during the act of apologizing by showing that you really understand how and why this is affecting them. Validate and acknowledge that something is a real problem. Probably the worst example of an apology is “I’m sorry that you feel that way” or “I’m sorry that you think I’m not being clear.” Simply put, there is no “you” in apology. A far better way to phrase would be “I’m sorry WE caused this frustration,” or simply “I’m sorry for the trouble.” Take responsibility.

2) Explanation

Just as important is to explain what happened. This not only shows that you truly understand how and why something is a problem, but it also builds trust and transparency. The cherry on top is then to be equally forthcoming about what is being done to resolve the issue. As a customer, when I’m the one having a problem, empathy only goes so far – I want to know if there is a solution, and I want to be connected to that solution. You can even take the extra step of mentioning the names of the people working to fix the issue, which will further humanize the support experience and help the customer feel especially connected. (Thanks to Daniel Slater of GuildLaunch for this tip!)

3) Appreciation

Another way to show that you care is to thank them for using the product. In fact, I will often do this first – showing appreciation for not only the customer’s problem, but also for the person herself, might diffuse the negative feelings by mixing in some positive ones.

4) Reparation

An important part of an apology is making reparations, but maybe not in the way you’d normally think. Throwing money at the problem can at times be appropriate, but can also cheapen the gesture (getting money for your birthday is great but also somewhat impersonal – wouldn’t it be better if you got a gift that someone took the time to pick out?). This might be an offer for some personalized attention (a demo, a consult, a phone call) or perhaps simply an overture to “let me know if there’s ever anything I can do to help.”

5) Verification

The apology should invite a response, such as “let me know if you have any questions about what happened here” or perhaps “let me know if this was solved to your satisfaction, and if not, what more can we do?” This makes the customer feel involved and respected – and possibly even part of the solution – and assures him that we’ll here for him and are not going anywhere, even after it’s resolved.

Lastly, a word on style. If you’re trying to humanize the interaction, then sound like a human! A cliched sentence like “sorry for the inconvenience” will likely just add fuel to the fire (forgive the cliche). Personalizing your response will go a long way towards establishing a connection. But avoid being too cute – you want to empathize, not trivialize.

Follow most of these steps, and you might find that your relationship with your customer has actually strengthened as a result. We all make mistakes – maybe you will even look forward to the next problem, and see it as an opportunity to show how supportive you can be!

---

“I’m sorry” photo courtesy of The Master Shake Signal.
Sign photo courtesy of Craig Murphy.

I was skeptical of Mathew Patterson when he first showed up at UserConf 2012. What kind of man has one “t” in his first name and two in his last?

Turns out, it’s the sort of man who’s very good at customer service and very likable. He could have easily spent his timeslot speaking about how great he is at customer service, but instead he spoke about outages, major issues, and one particular traumatizing experience he had.

Basically, Mathew covers the entirety of what we’re discussing this month. This is a must-watch.

Liked this video? Join us at the next UserConf!

Carter already told you that it’s crucial to communicate about your issues. But where do you communicate? This is something you need to figure out in advance because emotions will be high when your crisis is occurring, and you don’t want to be debating the merits of tweeting outages.

0. Support Tickets

I would hope this goes without saying, but respond to any support tickets you have gotten about an issue!

1. Social Media

The first place many folks are going to go during an issue is social media. If you’re lucky, they’ll check your profile first (many will just start complaining). If you don’t have anything posted they’re going to see you as unaware of the issue and incompetent.

Don’t freak out about a bunch of people seeing your failure. 71% of tweets aren’t responded to. Only a few folks will see that you’re having an issue, but what’s important is that those looking for it (those who have spotted the issue) see that you’re on top of it.

Sorry for the unannounced downtime, One of our servers decided to give us trouble. We have moved some things around for the time being.

— Artician (@Artician) April 28, 2013

(We don’t generally post issues on Facebook. Facebook posts can have a longer half-life than Twitter and that can actually be misleading if the issue is already resolved. That said, we’re a business-to-business company and most of our customers are on Twitter. For a consumer brand, Facebook might make sense.)

Sidebar: Main account or secondary account?

There’s a lot of debate about whether outages (and support in general) should be handled on a brand’s main social media account (@uservoice) or a support-focused account (@blackberryhelp). I personally think the damage of splitting outweighs the risk, and Chase Clemons of SupportOps agrees.

“I’d definitely recommend doing support on your main Twitter account. I use an app (who shall go nameless for now) that has three different Twitter handles – a main one, a support one, and an ops one. Which one do I interact with? Where do I go when I need to find out why their app is down? Why does one answer sometimes but the other rarely does? It’s a horrible, segmented experience.

Have one handle that does everything. Helping customers, marketing new tools, updating on downtime, etc. Customers want a central place to go for in. Potential customers like seeing that you’re active with your customers. Your team gets one place to keep up with things. It’s neat and clean with everyone winning.”

Keep in mind that it’s not necessarily bad for folks to see you dealing with support issues on Twitter. In fact, it might help generate sales. It shows that you care and pay attention to your customers…wheras Blackberry customers will see @Blackberry tweeting quizzes while they’re experiencing issues.

2. Blog

If an issue is significant (you can see how we define “significant” in our critical issue process), I recommend putting it on your blog. Why? Because that’s another top destination for folks seeking information about issues they’re encountering.

Some folks like to have a separate statusblog. I have similar concerns to the “second Twitter account” concept, but I think it can work if you clearly link to it from your main blog.

3. To your team

This one is often overlooked. You solved the issue and answered customers, so now it’s Miller Time, right?! Unfortunately, not informing your team can have negative consequences. What if a sales rep is talking to a major client and says “we’ve been outage-free for three months”? The client isn’t going to be happy or impressed when that rep follows up with him and says “oops, I was wrong.”

Make sure anyone who interacts with customers is aware of the issue. For companies smaller than one hundred I actually recommend emailing everyone on the staff. It’s useful for customer-facing staff and a good reminder to development staff that they need to check their code.

---

Making these decisions in advance save you from the inevitable debate as to whether you should share an issue. Have a plan, have channels, and when the time comes you won’t have to hesitate.

Just yesterday we posted about how it’s essential to communicate clearly with users about changes, even if you see them as improvements.

MailChimp (who just spoke at UserConf) is doing an amazing job handling change at this very moment.

The email newsletter company is about to launch a major revamp of their product…changes that affect every single page. They’re all improvements, and it sounds like they’re amazing. But MailChimp knows better. People fear change, are creatures of habit, and don’t always see the bright side. So MailChimp’s gone out of their way to communicate about the changes.

Here’s a few of the things they’ve done right:

Early warning

They’re giving customers a head’s up several weeks before they start launching anything. This can be hard for companies, especially when marketing and PR departments want to make a big splash with the launch. But this is exactly how you keep your customers calm. If they wake up one morning and the interface has changed without warning, they will be pissed, no matter how good the changes are.

Deep explanation

Their blog post is LONG. Too long, some might say. I disagree. Some customers will skim it for the pertinent details, appreciative of the depth but finding it unnecessary to read it all. Fans may read every single word (twice, even), and if they do they get a wealth of information about what’s changing and why. People like to KNOW. There’s no reason to hold back.

Changes based on feedback

Sort of a no-brainer for user-centric companies, but their changes are all based on what they’ve heard from customers…a fact that they explain very clearly. This is a great move; you’d be surprised how often frustrated customers assume changes are based on the CEO’s whims or overly-controlling investors.

Previews

Aside from the peeks into the new interface in the initial blog post, MailChimp will be blogging for the next few weeks about the changes. When done thoroughly (sneak peeks just invite speculation) this is a great way to get their users familiar with the new interface (and why they changed) before the interface actually changes.

Slow rollout

The new MailChimp will be an optional upgrade for 4 weeks, “so you have plenty of time to try it out when you’re not under deadline.” I actually might disagree with this last point – I think pulling off the band-aid quick results in fewer tears – but regardless, that’s some fantastic empathy at work.

---

Writing a whole blog series about your interface changes is no small task, but clearly MailChimp knows that a transition like this has to be handled delicately. I have no doubts that they’ll switch things over with very little backlash. Nice work, chimps!

Want more tips on successfully managing change? Check out our post on how to launch a new interface without upsetting your customers.

I all-too-frequently hear: “we don’t need to tell people about these changes to the product, let’s just launch them.”

No. Stop.

People fear change. It’s just part of human nature.

There’s a common misconception, especially amongst creators, that if you are (or think you are) making something better then of course people will gladly accept your changes.

This is wrong.

I used Facebook early in it’s existence, when it was only available to college students. When I first started using it, it was just profile pages. You went to someone’s page to see what they were posting (I think there might have even been a version before that where you didn’t post anything). It was simple and we all liked it, even though it sounds weird and archaic today.

Then Facebook launched the news feed. Yes, the same (though much simpler) news feed that you see when you log into Facebook today. That crucial, engaging, fascinating, primary function of Facebook. So we must have rejoiced when they first launched it, right?

Nope. People freaked out. They rebelled. They said it was the worst thing Facebook had ever done. An invasion of privacy. The death blow for Facebook.

Of course, 99% of those people kept using Facebook and now love the news feed. They’d probably react with the same anger and fear if the news feed disappeared tomorrow.

Even if you’re launching an improvement, you need to communicate with your customers. They fear your change. And they especially fear change they don’t understand. You can’t make them like your changes, but you can calm many of them by explaining why you did it. With explanation, suddenly a change seems more like an intentional, well-meaning action…rather than a malicious, chaotic disruption.

Nobody is going to get mad at you if you communicate changes. They might be mad about the changes but nobody will ever say “STOP TELLING US WHY YOU ARE DOING THINGS!” [Tweet this]

The good news? You tell people how you’ve (hopefully) acted on their feedback and strived to improve your product and you’ll probably get some serious points from people. It’s marketing via product. And it’s honesty at it’s best.

“Accountability and responsibility.” My dad repeated this to me ad nauseum from the time I could speak until, well, still. No matter what I did I had to be accountable for my promises and responsible for my actions and their consequences. Being responsible for those consequences was easy when I did something good, but pretty challenging when I screwed up. In my house it was always understood that missteps happen to everyone, but we had be honest about them when they occurred. I hold companies to the same standard my dad held me to. For instance, if a company webpage goes down, I expect them own it and inform their customers. For instance, last week I was staring at “Internal Server Error” with no explanation….anywhere.

It was pay day and I was very excited to log into Bank of America to transfer my funds around (a favorite activity of many recent grads receiving their first ‘big boy’ paychecks). I logged into the site and then there it was: Internal Server Error. “Weird! WiFi must be down!” To check I went to Google+. Nope. Internet worked. Alright, I’ll try logging in again: Internal Server Error. “Third time’s the charm?” Internal Server Error. A quick review of Bank of America’s Twitter revealed no info. It was business as usual and there had never been a better time to mortgage my new home (apparently)! I tried again: Internal Server Error.

They say that a sign of madness (and idiocy) is doing the same thing over again and over again expecting different results. I didn’t think I was crazy (or an idiot), but Bank of America was telling me that everything was normal. “But….but….it isn’t.” I tweeted Bank of America, confused and frustrated. I wasn’t actually angry until I got this tweet back a few hours later amid many others just like it: “@CarterGee issues have been resolved. Site is back up ^EG”

….Oh. You mean you knew about your issues but you didn’t tweet your outage? You thought that it’s best to not “look bad” to your customers by telling them something’s wrong? Well now I’m about 50 times angrier because I didn’t know about the outage. It would have taken me one minute to check your Twitter account to see that I couldn’t access my account if you let me know you were having trouble. We use a ton of services everyday and an occasional “oopsie daisy” is expected (keyword: occasional). We’re most likely going to understand a hiccup, so tell us that there was one lest we spend far too long driving ourselves crazy thinking the WiFi is down and then redirecting that frustration back at you.

Refusing to acknowledge mistakes like outages isn’t a problem exclusive to Bank of America. There seems to be an attitude of “let’s hope no one notices and retroactively apologize if they do” in the tech industry and it’s pretty unbecoming. Too many companies are afraid that publicly reporting outages would anger their customers. To those companies I suggest that hiding mistakes is a far bigger breach of trust than informing customers something went wrong and that you’re working to fix it. Not letting your customers know something went wrong shows an organization that doesn’t take responsibility for its mishaps. It’s probably best for you to tell your customers you’re down before the press tells them for you. And hey, communicating your outage might actually make you money too.

I don’t expect everything to work perfectly all the time, but I do expect honesty and communication (it’s like dating!). So. Companies and the people who manage them – help me love you. You’re not doing yourself any favors trying to hide your missteps. Us customers are smart! We know when something’s awry. Use all those fancy social media tools to communicate with us – lest we find a competitor who’s more transparent.

And if you’re wondering how we communicate our outages, you can find our Critical Issue Escalation Process here.

Community departments work with customers. Support departments work with customers. When everything breaks, who’s in charge?

In our experience, it’s a team effort. Support is often best positioned to work with development, verify whether issues are resolved, and handle support tickets. But when it comes to communicating your issues to the masses (which we really think you should do), Community knows how to be transparent while keeping people calm…especially in a public setting like Twitter.

Support folks are fantastic at calming individual customers, but it’s surprising how many of them get nervous in a public setting and may use language a seasoned community manager never would. And community managers are definitely not always the best at working an issue through from start to end; we’re a bit more emotional…which is a good thing most of the time, but generally not good when talking to developers!

It’s not about deficiencies, but more about gifts. Team up and use the gifts each group has to successfully resolve an issue. You can see a bit more about how we do this in our critical issue escalation process.

PS: What about PR?

Hahahaha, oh, that’s a good one…

PR should never be involved with communicating with your users. Their job is to make the company look good. That’s often diametrically opposed to the goal of the Community and Support departments: to keep the customer informed.

Yes, sometimes PR needs to be brought into the loop so they can communicate with the press (especially if you have shareholders). But the moment they get their fingers into communication with customers you’re going to lose that authentic transparency that makes your customers love you and give you more money. Keep ‘em out!

PPS: Support = Community?
There’s a bigger discussion to be had (which is happening at companies across the world) about whether these two departments are actually one, if support is a subset of community, etc. We won’t tackle that today…but we’d love to hear your thoughts about that subject on Twitter.

---

Arm wrestling photo courtesy of britl.

The obvious first step to dealing with critical issues (once you’ve defined them) is to spot them.

“But Evan,” you might say. “It’s pretty damn obvious when our site goes down.”

True, often it’s going to be very clear. You get 20 tweets and 50 tickets saying your site is down and you get to work.

But there will be plenty of times when critical issues that are a lot harder to spot…which can lead to very angry customers and/or lasting damage. A great example: if customer data is disappearing gradually, you might not put together that it’s a site-wide phenomenon right away. You might think a customer or two fat-fingered something and accidentally deleted their data. But once you realize a lot of folks are experiencing the issue, a ton of customer data may have been lost forever. Goodbye customers, hello TechCrunch exposé.

Here’s a few tips for catching those less-obvious critical issues…

Regularly communicate with your team

Especially as your supportteam grows, no one person is likely to have awareness of all the support tickets you’re getting. [Tweet this] You have to collaborate in order to catch trends that might be invisible to one person who is answering 25% of tickets.

See something that would be worrisome if it were a trend? Share with your team in a more casual setting. We use HipChat and will frequently share concerns in the Support room:

Most of the time the answer is “no, I haven’t seen anything like that.” But occasionally you discover that everyone’s had one or two tickets about the issue. Uh oh – this might be a widespread critical issue!

Note issues in your bug tracker

If you use a bug-tracking system, make sure that all support agents search for a bug before submitting a new one. If the bug already exists, leave a comment. It’ll become clear what’s trending pretty quick as the comments stack up. (Thanks to UserConf alum Mathew Patterson for that tip!)

Give your users descriptive custom fields

Support ticket submissions are pretty generic (“I have an issue”) unless you prompt your users to provide more info. But if you include descriptive custom fields, many customers will fill them out and give you a good idea of what’s going on. “Installation>Error message” is much clearer than just “It won’t work. (Props to AVG’s Jon Meyer for that nugget!)

Reporting

A good helpdesk will provide you with reporting about trending custom fields, tags, etc. (We’re biased, but we recommend our own UserVoice helpdesk.) A spike in a single field makes it clear that something went wrong.

 

Optional: give users an emergency lever

As I wrote about a few years ago, Rapidbuyr actually lets customers mark something as “urgent”, which will send a text message directly to their Head of Customer Support. Sounds scary, but they claim they didn’t see much abuse, and it immediately gave them a head’s up when something was going very wrong.

Hopefully you’ll find these useful. But there are always more tactics to implement. Which did I miss?

I know, I know. It seems like critical issues are pretty obvious. The site is down: critical. Users are losing all their data: critical. Users get intermittent errors when importing their data: …critical? Non-critical?

Things get especially complicated when you start factoring in other departments. Engineering doesn’t like to be bothered with things they don’t find critical, so you can’t be too liberal with your definition. But PR might think a hacker attack, even if it didn’t do any damage, is something that needs full attention. Going back to the example of the data importing, Sales would be pretty upset if they lost a major customer because the customer couldn’t import data. Everyone’s definition varies.

During the heat of an issue is really not the time to define what’s critical. You need to do so in advance.

Marssy Benitez, former Support Operations Manager at Flickr, is speaking this very week at UserConf NYC on this very topic. Her secret weapon? The Matrix.

No, not the crazy movie with Keanu Reeves that had a weird sequel with a rave scene that didn’t make much sense. A matrix of critical issues:

To build this matrix, Marssy sat down with every department in the company and mapped out which situations were critical for each. The resulting matrix tells you how to determine (and reproduce) a critical issue, what priority it is, and whom to contact about it. The contact links even spawn handy pre-addressed and pre-formatted emails.

Thanks to Marssy we’re sharing a copy of her matrix for your use below. Feel free to download it and make it yours!

• View & Copy in Google Docs
• Download for Excel

(We recommend Google Docs, as it allows you to generate body text when clicking the email links.)

This will take some time, but once it’s done you’ll have an incredibly useful document which will save you a lot of pain and suffering when you really do run into a potential critical issue!