{"id":4286,"date":"2016-05-12T12:30:33","date_gmt":"2016-05-12T10:30:33","guid":{"rendered":"https:\/\/chartmogul.com\/blog\/?p=4286"},"modified":"2023-08-10T12:10:37","modified_gmt":"2023-08-10T10:10:37","slug":"salesforce-saas-product-is-down","status":"publish","type":"post","link":"https:\/\/chartmogul.com\/blog\/salesforce-saas-product-is-down\/","title":{"rendered":"What to do when your SaaS product is down"},"content":{"rendered":"

Salesforce was down.<\/p>\n\n

Okay, not all<\/em> of Salesforce \u2014 but enough of it and for long enough that everyone at least heard about the great NA14 failure from friends or newsfeeds, if they hadn’t experienced it directly in their work.<\/p>\n

Do you know what you would do if your SaaS product went down? Do you have any protocol or processes in place if technical disaster hit? Your business may not be so big as to worry about press write-ups<\/a> or internet memes<\/a> about a product failure \u2014 and your failure may not garner its own hashtag<\/a> \u2014 but the situation can be just as much of a crisis for you and your customers.<\/p>\n

Such a scenario affects almost every team at the company, some more than others. And when all various functional teams have to jump into action to address the same problem in different ways, it\u2019s truly a test of organization, communication, and efficiency.<\/p>\n

To help with this, here\u2019s a quick game plan for each arm<\/em> of the business<\/strong>, with some extra tips about how your business can handle failure aftermath and future prevention.<\/p>\n

First things first<\/h1>\n

Ideally your dev team should notice any service disruptions before you hear from your customers. This requires you to have the right monitoring in place, but that\u2019s not always the case, so…<\/p>\n

When customers report a service issue, check your product on various devices, browsers, and connections before doing anything else. See if the issue is isolated, if it\u2019s local rather than global. Then proceed accordingly.<\/p>\n

Tips around communication<\/h1>\n

Proactive. Proactive. Proactive.<\/h3>\n

Communicate early and often with both your customers and your teammates.<\/p>\n

Take ownership.<\/h3>\n

Admit the failure. Don\u2019t try to explain it away or pass off responsibility. Don’t layer your message with glossy jargon or marketing speak.<\/strong> That’s just more irritating to your customers, and this is a crucial moment to maintain\u00a0their trust.<\/p>\n

Honest and transparent.<\/h3>\n

This doesn\u2019t mean give\u00a0every detail. It just means be clear about the situation \u2014 your product is not working<\/strong> \u2014 and share what you can about what you do and don\u2019t know.<\/p>\n

Stay consistent.<\/h3>\n

The best way to retain your customers\u2019 trust throughout the resolution process is to provide a clear, consistent message.<\/strong> What you\u2019re saying on Twitter should align with what Customer Success says on the phone. Otherwise you risk appearing disorganized (or incompetent) in the face of customers who are already questioning your product.<\/p>\n

Don\u2019t give false hopes.<\/h3>\n

It\u2019s best not to provide precise ETAs for fixes to avoid setting false expectations and worsening the customer experience. Instead stick to what you reasonably expect<\/strong>, such as \u201cin the next few hours\u201d or \u201cby the end of the day.\u201d<\/p>\n

Game plans<\/h1>\n

CEO<\/h2>\n

Speak up.<\/h3>\n

A personal apology from the CEO can go a long way with customers. After all, the CEO is the face of the business. Salesforce CEO Marc Benioff responded to countless tweets about the NA14 failure, looping in his cofounder Parker Harris as well.<\/p>\n

\"Salesforce<\/p>\n

Put someone in charge.<\/h3>\n

Assign someone to lead all internal management of the issue.\u00a0Communication and coordination runs through this one person, keeping the resolution process streamlined and less chaotic.<\/p>\n

\n

Side-story:\u00a0The “Incident Commander”<\/h3>\n
\"There
There are more parallels between a server outage and a fire-based emergency than you think. Image source: victorops.com<\/figcaption><\/figure>\n

Hi, Ed here. Let me tell you about Incident Commanders.<\/p>\n

An Incident Commander is traditionally a role which is assigned in an emergency response situation (e.g. fire, natural disaster) to coordinate all aspects of operations.\u00a0See Wikipedia<\/a>
\nAt a company I used to work at, we adapted the role for emergency response to issues with our software platform – a platform that was mission-critical in nature, with any down-time causing significant economic loss to the business and clients.
\nAs soon as a problem had been identified and raised as such, an incident commander was assigned from a pool of volunteers by the CTO. From this point, the person became responsible for:<\/p>\n