When it all goes wrong
(because it will)

As presented by Mathew Patterson (@mrpatto) of Campaign Monitor at UserConf, San Francisco. This talk was about creating a plan for customer service that you can deploy when something goes badly wrong.

A crisis plan?

A crisis response plan is a document that you and your team can use when things have gone badly wrong (like a major service outage or a security issue). It will help you make better decisions under pressure, and give better customer service.

Before a crisis

Understand your company

There’s no point writing a plan up about your fanatical customer service if your company doesn’t believe it to be important. Work out realistic options based on the resources and support you have available.

Example: Are you a Ryanair “low costs are more important than any customer” or a Southwest “Customer Service company that happens to fly”

Decide which support channels you will offer

Will you respond on email, on twitter, by phone, on Facebook? Can you realistically do all that in a crisis? Or should you funnel people from those places into one full support channel?

Example: We will monitor and post updates on Facebook and twitter but point people to our email support channel for individual help.

Note the responsible team members

Decide which person (or which role) should be responding on which channel, so in a pinch you can avoid double handling tickets; or worse, not responding at all.

Include a list of escalation points; how and when to contact developers / managers / systems administrators.

Setup detection systems

Catching problems early makes everything easier to handle. Investigate technical options (like Nagios, Pingdom), human options (how easy is it for support staff and customers to report issues) and third party options (can your up-stream providers give you notifications of problems)?

Create a notification system

Create an easily updatable page where your customers can self-serve to see if there are any known issues, but only if you promise to actually keep it up to date.

Build up a library of shared language, tone and structure

Rather than having to come up with the right words on the fly, spend time in advance deciding on what terms to use (the ones your customers will understand!) and share lots of specific examples with your team.

Example of a general response structure:

During a crisis

This is when you put your plan into action. So make sure the plan is readily available and up to date.

How bad is it?

Your early warning systems will help, but the faster you can see the scope of the problem the better your customer service can be.

Who can help?

Determine who you need to get in touch with (developers? Managers? Suppliers?) and bring them in.

Work on a rapid response

You may have many people contacting you in a short period. Work out a shared basic response that accepts the problem and explains what is happening and get your team using that to quickly respond to every person.

Important: Take the time to modify the response to the specifics of each customer’s case. It makes a big difference to them.

Work out the right update frequency

A fast first response is great but if the problem continues with no further details being shared the goodwill evaporates. Work out how often you need to update people depending on the type and severity of the problem. Read the blog post Campaign Monitor made when their service was hacked.

Brave the wrath of developers (if relevant)

Someone in customer service needs to be a little pushy in finding out what is going on, on behalf of the customer.

Keep up internal communication

Don’t leave your support team on their own to guess at what is happening and when it will be fixed. Help them to help your customers by keeping them informed.

Maintain a list of people to follow up with

Some customers will need to know immediately that the problem is resolved. If you don’t keep a list it is hard to do that in a timely way.

Aftermath

Once the immediate issue is resolved, take some time to apologise to the affected people and improve your system for next time.

Make an apology

Avoid the fake “It wasn’t so bad” or “it wasn’t our fault” apologies. A real apology is:

Modify processes and procedures

Review the whole event and see what can be learned for next time. Some good questions to ask:

Maintaining quality when the team grows

A small team (and one in a shared space) will absorb knowledge by osmosis. When you have 10 or 30 or 50 support staff, that process doesn’t work.

Further resources