Should support commit to resolution times?

Posted on Posted in Customer Success, Technical Support Tagged with

Many thanks to Angus Klein for suggesting this topic.

We’ve all been there: in a hurried call at the end of the quarter, we are told that a prospect won’t sign on unless we agree to resolution time targets for support issues, with penalties if the targets are exceeded. Sigh.

Clearly, resolution times are unpredictable and committing to set targets would be disingenuous. Perhaps a case will involve a bug, and that bug will be difficult to isolate, difficult to fix, or even an architectural limitation (so unfixable). And, on the other hand, the customer may be unwilling or slow to implement a fix or workaround, so it may take a long time to get to a full resolution even if an appropriate solution was proposed. So we can commit to resolution times, but it would be dishonest to commit to meeting targets 100% of the time. My personal experience pushing back with customers about this topic has been very successful: customers respect straight talk, at least  if you can speak with the support contacts rather than to the purchasing team, and will agree to a different approach once they see that their request does not make sense.

Let’s step back a bit: what do customers really want when they ask for set resolution times? They are concerned about issues dragging on too long. So how else can we address the request for resolution time targets?
  • Offer an escalation path. If customers feel that they have a real person they can turn to when needed, the requirement for resolution target may disappear. Again what matters is not that each case is closed in X hours or days, but whether it is actively worked on. I have given my cell phone number to many customers who were pushing for resolution targets as an alternative — and I have not gotten many calls!
  • Offer automatic escalation targets, graduated by severity. So a P1 case that is still open after 1 day gets automatically escalated (i.e., made visible) to the director of support (say) and if it’s open after 2 days it goes to the VP, etc. (This is usually limited to high-severity cases.)
  • If you absolutely cannot get away from resolution targets, at least stay way from financial penalties. Make it clear that the issue is not so much a support issue but more of an Engineering issue: who will fix bugs within a set timeframe?
  • Keep all of the above out of the boilerplate SLA. Offer it as a concession when needed.
  • Do set internal targets for resolution, visible to support engineers and sustaining engineers. Internal targets help focus everyone’s mind on the benefit of resolving cases swiftly. For instance, declare that 80% of cases must be closed within a week. This creates a mindset that a week is a good timeframe to resolve cases, and it also gives you a handy filter to examine “aging” cases — while allowing truly complex cases to get the sustained attention they need.

Are you committing to resolution times? Share your experience.