Escalations: What to do when product issues are critically affecting a customer

What do you do when you have an important customer who is experiencing serious issues with your software -- issues so serious that they can't successfully use the product?

I'm not talking about customers who need a little hand-holding and training. Customer Support can handle them. I'm talking about situations where your product has serious bugs or is missing the functionality required to achieve the business benefits your company promised.

Your Options

Most companies will try the following approaches in order. If one won't suffice, move on to the next.

  1. Professional Services Hacks. Most software companies first try to throw professional services at the issue. The goal is to find a workaround or "custom configuration" that will allow the customer to proceed. Sometimes the customer pays for these professional services, sometimes not.

  2. Try to convince the customer to wait until an upcoming release where the fix or required new feature will be delivered as usual to all customers.

  3. Create a "Customer Escalation." This is where Engineering makes fixing the issue its highest priority, pausing the ongoing development work for the next release, in order to deliver an emergency fix as soon as humanly possible.

Escalations in Action

Here's how escalations worked at my former employer:

Sales or Support would usually be the first to learn of critical customer issues. They would try to solve the issue, work around it, or get the customer to wait (#1 & #2 above). If that didn't work, Sales/Support would raise an Escalation Request.

Engineering and Product Management would hold regular Escalation Meeting (usually 3x per week if any Escalations were pending) to consider new Escalation Requests and monitor progress on approved Escalations.

At the Escalation Meeting, we would:

  1. Review any new Escalation requests from Sales and Support - what was wrong, why workarounds didn't address it, the difficulty of fixing and any downstream dependencies of fixing it.

  2. Make a decision, yes or no, about whether to actually escalate it or not. And by escalate, we meant drop everything and work on it. Factors we considered:

    • Bug or enhancement/new feature
    • Paying customer vs pending big deal vs a doubtful prospect
    • Severity of the problem
    • Confirmation that our fixing the issue would definitely increase the customer's happiness
    • Broad applicability of the fix to future customers
    • What other stuff would fixing this delay
  3. If we decided NOT to escalate, we would either schedule it for a future release or leave it in a “Backlog” JIRA to be considered for future releases.

  4. Support / Sales would be notified of yes/no decisions and asked to communicate the decision back to customers.

  5. We’d then review the status of in-progress Escalations. There would be an ETA assigned for each issue, and compare the progress versus this ETA.

Sue Raisty

Product management geek, born-again engineer, adoptive mother of boys, coach & mentor, mountain trail runner, tinkerer, no-bull communicator, wannabe writer, room mother & compulsive researcher.

Silicon Valley, California http://blog.sueraisty.com