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!

Outages, critical issues, and crises are unavoidable. In the immortal words of Forrest Gump: “shit happens.”

So if you take a deep breath and accept that crises happen…how can you at least make them less painful?

That’s what we’ll be exploring all this month. Specifically, we’ll be tackling:

Spotting critical issues

• Creating a clear method for determining what IS a critical issue
• Learning to spot a critical issue (trickier than you might think)
• Building a clear process for addressing critical issues with your team
• Determining what part(s) of the organization handles critical issues

Communicating during critical issues

• Telling your customers about your issues (no matter how painful)
• Choosing venues for communicating critical issues
• Knowing when to quit your job (really)
• Saying sorry

After the storm

• Banning your founders from going surfing (and other lessons)
• Figuring out how you could have better communicated with customers
• Avoiding overreaction and rule accretion
• The worst crises of 2013 and what we can learn from them

Are you ready to explore the big, scary world of crises with us? Stick with us throughout this month! Check back in on this page for new posts or subscribe!

---

Photo courtesy of reegmo.