The FT Word – September 2009

Posted on Posted in Technical Support Tagged with ,

The FT Word

The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.

Welcome

Welcome to the September 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)

Last month I talked about case resolution models – and who knew that an apparently benign, “back to basics” topic would (1) generate the highest number of comments ever on any newsletter topic and (2) inspire the largest number of new subscriptions to the newsletter? And during what’s supposed to be a quiet summer vacation month! So this month I thought I would revisit case resolution models, discussing more complex and forward-thinking options. With that, this month’s topics are

  • Case handling models revisited
  • Putting supportability on Engineering’s to-do list

Case Handling Models – Revisited

Last month’s discussion contrasted the three most popular case handling models:

  • the classic tiered model (all customers start with level 1 and are handed off to level 2 if needed for difficult issues
  • the Touch and Hold model (cases stay with the original owner even is the owner needs technical assistance from a Backline team)
  • the elite routing model (more valuable customers go to a dedicated team or individual)

Many thanks to all of you who commented on the writeup! Several comments suggested that I also discuss crowd sourcing or swarming as an alternative model for case handling. The idea behind crowd sourcing is that, instead of delivering customers and issues to the support staff following a preordained (and not always successful) routing logic we can instead ask would-be solution providers to grab cases they think they can solve.

What are the benefits of crowd sourcing?

  • When someone is knowledgeable about a topic the case will be grabbed quickly since there’s no sense in letting an issue sit on the queue with the risk that someone else may grab it.
  • Issues are handled by individuals who have a good chance of resolving them, therefore there should be few handoffs.
  • Resolution should also be quick.
  • Customer satisfaction should be high.
  • The support staffers should be satisfied with the degree of control they have on their work.

Now let’s think of the problems with crowd sourcing:

  • If no one feels qualified to handle a case it could sit for a long time.
  • If no one is available to handle a case it could also wait forever.
  • There could be a temptation for the more skilled support staffers to handle large numbers of “easy” cases, at the detriment of the harder cases.
  • It may be difficult for support staffers to develop expertise with new topics if they never get a chance to work on them.
  • Since crowd sourcing is new, support organizations have little experience with it hence are reluctant to use it.

Note that crowd sourcing can be used both within a standard support organization and with a virtual workforce. A good example of a virtual workforce model using crowd sourcing would be SupportSpace, which provides access to hundreds of technical experts for remote services such as virus removal. (And yes, I’m biased: SupportSpace is a client of FT Works.)

In any case the challenge with crowd sourcing is how to guarantee SLA adherence for those potentially orphaned cases (the challenge is eased with a virtual workforce that’s constantly “overstaffed” as experts wait for work.) But it’s a simple matter of appointing a last-resort owner to handle the orphans; the challenge is really more about incentives and scheduling. For instance if the support staff is incented purely on the number of cases handled there could be a temptation to cherry-pick the easiest cases at the detriment of the harder ones. So if you decide to use crowd sourcing you need to be particularly careful about creating incentives for the team that mesh well with SLA compliance.

And a few additional comments about transfers or handoffs between teams when the initial routing is incorrect. These apply regardless of the model you are using.

  • Moving cases between individuals or specialty groups is unavoidable with complex products but there should be few transfers (say fewer than 1-2% of cases.) If there are more than that it’s an indication that you must revisit your routing logic – or perhaps simplify the routing so you have more generalists, fewer gray areas, and fewer transfers! Note that the crowd sourcing model makes for few handoffs.
  • Immediate transfers (without contacting the customer) are fine if made within a few minutes of the case landing into the wrong queue. So if I grab the case, see it’s wrong, and check that it’s really new, I can move it to another queue without penalty. This is helpful because it puts an emphasis on quick processing, which is good for everyone. There should be a strict time limit on such transfers like 15 minutes if your response target is one hour.
  • If a transfer cannot be done very quickly whoever grabs the case needs to do some work before transferring the case. Sure, it’s not their area of expertise but they can (1) contact the customer (2) (re)frame the question into a solid description of the problem and (3) do a knowledge base search in case the solution is easy to find. If that fails, transfer the case with the better-framed description and what has been attempted so far.
  • If you have a problem with inappropriate transfers try tagging improperly-transferred cases in the CRM system and holding a management review of these transfers on a regular basis. I suspect that you will find that a few individuals are acting carelessly and you can counsel them appropriately.

The tiered model is not the only resolution model out there! Tailor the model to your product complexity and the technical ability of your staff. It’s fine to use multiple models at once and it’s always fine to switch to a model that better supports your specific situation.

Putting Supportability on Engineering’s To-do List

Thanks to James Burr for suggesting this topic.

It can be difficult to get bug fixes delivered in a timely manner. It takes dedication and luck to get enhancement requests. But supportability? Good luck! Now why supportability typically comes to the bottom to Product Development’s list?

  • It’s not as exciting as other functionality improvements, including to customers and prospects.
  • It’s usually more difficult and more costly to improve supportability after the fact. If I want to rewire my house it will be much more costly to do it than it would be to wire a brand new house with no pesky walls in the way of the new wires.

So what can we do about supportability in this imperfect world?

  • Create add-on tools designed by the support team. This is a very common strategy and it works to some degree, i.e., it’s better than nothing. But add-ons are often clunky and their performance is not as good as integrated tools. They may also suffer from technical weaknesses if the creators don’t completely understand the product architecture. And they certainly make it clear to customers that supportability is an afterthought.
  • Push for minimal supportability criteria for all new products. What if every product could be installed single-handedly by a customer with only mediocre knowledge of the product? What if every development environment included a debugger? What if every administration tool included events logs? Your Product Development team probably has established criteria for new products that cannot be violated (except by executive fiat.) for instance you may have a rule that no release can go out with known “P1” bug. Supportability criteria can be treated the same way.
  • Document and quantify post-release supportability enhancements to be integrated into the product. This is better, in my mind, than creating add-on tools because the technical accuracy of tools created by the Product Development team should be higher and (more importantly) once the tools are integrated into the product they are likely to be adopted by the Development team for the long haul, and even for new products. The best approach I’ve used for this is to create a financial impact statement: what is it costing you to support products that are not (easily) supportable? (and perhaps what is it costing customers? I’ve had the experience of “suggesting” to a large customer that he asks for a debugger – and amazingly enough that was enough to inspire its inclusion in the next major release.) It’s a good idea to start small: once you have a basic events log it’s a lot easier to get a more sophisticated one for a future release.

Bottom line: while it can be tempting to use a skunkworks approach to supportability enhancements it’s much better in the long run to lobby for integrating supportability into the product, and that discussion is best handled by computing the costs in resources and customer satisfaction of foregoing supportability so-called enhancements.

FT Works in the News

Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.

Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826

Back to Newsletter Archive