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 August 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)

This month’s topics are “back to basics” topics – with special twists

Can we do support without a tiered model? Routing and escalation models pros and cons
Defining realistic Engineering SLAs in complex support environments
And don’t forget the contest for naming the upcoming support marketing book.

Can we do support without a tiered model?

Thanks to Aileen Allkins for suggesting this topic.

So many support organizations use a tiered support model that some support professionals think the only way to resolve customer issues is to drag them through level 1, more junior support engineers, on to level 2 engineers for harder cases and all the way to Engineering if needed. But is it the best way to approach support?

Let’s start by acknowledging the wisdom and benefits of the tiered model:

If most of your cases are routine and only a few are truly complex, the vast majority of cases can be solved at level 1 so most customers will get a quick resolution while only a few will need to navigate to the second level.
It’s an efficient way to filter out only the truly complex issues to the level 2 staff. Why waste their time on easy stuff?
It’s a good way to leverage minimally trained support engineers by having them work on easier issues, with the senior staff ready to assist when needed.
Allowing level 1 staff to hand off complex, time-consuming issues makes it easier to respond promptly to new requests.

But the tiered approach also has some drawbacks:

Customers dislike having to explain the issue again to a new person, and even with a great tracking process they will have to do it with a tiered model.
If many cases are complex, they will either bog down level 1’s ability to quickly attend to new issues or linger before they can be attended to at level 2.
The tiered model fosters a caste system between the various levels, leading to sometimes unpleasant relationships between levels.
If level 1 staff never touches harder cases how can it be trained to move up to level 2?

Are there alternatives to the standard tiered model? Yes! And they are worth exploring.

One is the so-called Touch and Hold model, described by Richard Farrell and me in our 1996 book The Art of Software Support. In a Touch and Hold model the support engineers are responsible for resolving all the issues that come their way. If they need help, they can get it from a team we call Backline, which is composed of senior support engineers whose mission it is to help others resolve cases, but without taking on ownership of the cases. Touch and Hold works well in high-complexity support environments where most cases are complex and unique because:

Customers almost always interact with just one support engineer to resolve their issues.
Support engineers learn on the job every day by tackling new issues and interacting with the Backline team.
New support engineers can be mentored on the job (and protected from taking on issues beyond their capabilities.)

At the same time, there are issues with Touch and Hold:

It does not work well if you have to hire massive numbers of new support engineers at once, as they overwhelm the capacity of the Backline team to mentor them. (Hint: temporarily beef up the Backline team to get through the training period – and remember that massive numbers of new hires can create havoc regardless of the support model.)
It means that every issue, no matter how trivial, will get the attention of a well-trained support engineer rather than a cheap level 1 resource. Touch and Hold is not a good model to use in a support center than handles lots of known issues.
It requires active and vigorous management of backlog. In the tiered model level 1 staff is usually required to escalate cases after a set amount of time so backlog never builds up (although it does at level 2!) but with Touch and Hold not only can cases never be handed off but support engineers can be reluctant to ask for help on harder issues, hence hang on to cases on which they are not making progress.

Another common model, I’ll call it elite routing, is to route more valuable customers to a dedicated group (or sometimes to a specific individual assigned to a handful of accounts.) This approach plays well for those customers who will be receiving the special handling – well enough to encourage them to pay extra for it, if the service is fee-based. Since the elite group is composed of more senior individuals they tend to resolve issues faster, although the small size of the elite support team creates issues with scheduling and specialization. Indeed in most support organizations the elite support team feeds into the same level 3 team as the non-elite support team for the more complex issues, albeit with a higher priority level. So while customers are generally happy with elite routing because they get individual attention, it does little to address the issue of accurately routing cases to the individual best equipped to solve them.

So what else could we explore?

Customer tagging. Support organizations know a lot about their customers, but they bizarrely ignore most of what they know. In particular after a particular individual has contacted support a few times the support team has a very clear idea of the technical ability of that individual. What not capture that in the profile and route cases appropriately, perhaps bypassing level 1 (in a tiered model) for a customer who was rated as highly skilled? In the same way you could route customers who hold certification for the product, or customers who have proved themselves as moderators in the community differently than others. I think the main obstacle here is how to integrate the various forms of eligibility input into the CRM.
Manual routing. Especially for complex support organizations it’s difficult to determine whether a case requires a highly-skilled support engineer at first glance, that is at the time of the initial routing. However, after a short review of the case it often becomes clear to the support engineer that the issue is indeed very complex and/or requires a specific skill set. At that point, it should be possible for the support engineer to do an immediate handoff to the specific individual who can help, without necessarily going through the normal step-by-step escalation process. The problem here is misroutes: what if a case gets routed to Jane Wonderful, mistress of the gnarly cases, only to find out that it’s actually a very easy case and we just wasted Jane’s time? Manual routing works well if (1) you can define clear criteria to greenlight the handoff and (2) mistaken handoffs cause handoff privileges to be temporarily revoked. That sound a bit complicated but it can work well if there are a very few special situations that can be defined to require special handoffs. Another useful process is for the gurus to proactively review open cases, looking for profiles that sound promising (and such reviews can be extremely fast with a good search engine.)
Here are my suggestions for selecting support models. Let me know what you chose to do, and how it’s working for you.
If most cases are routine and only a few are complex, choose tiered
If most cases are complex and require troubleshooting, choose Touch and Hold
If your organization is large enough, offer elite routing (for an additional fee, or to customers who are paying the most in support fees) to generate additional loyalty from the most valuable customers even if it does little to solve routing issues.
Consider ways to integrate customer tagging into your routing logic, giving more knowledgeable customers a fast track to specialists.
Regardless of the basic support model you choose, consider adopting flexible hand-off processes so that support engineers can direct special cases to specific individuals or group – and at the same time put in place a feedback loop so you can spot and stop poorly thought-out handoffs.
If many routing errors occur, revisit your routing scheme.

Defining realistic Engineering SLAs in complex support environments

Thanks to Steve Kershner for suggesting this topic.

You have support SLAs under control: response time targets have been set, probably right in the support contract, and you have some target for resolution time as well, most probably an internal target (not a promise made to customers) and one that gives you plenty of room to work with the minority of cases that are truly complex (so for instance 80% of cases solved in a week, not 99% of cases solved in a week). You are doing pretty well against the targets, but when you need Engineering assistance it feels like you fall into a black hole: you may have to wait days or weeks for an answer, and while the responsiveness is pretty good for true emergencies it’s impossible to set customers’ expectations as to when they will get an update. What should you do?

Involve Engineering in the solution. Setting targets unilaterally is a great way to raise hackles and get pushback. Look at the Engineering SLAs as a joint exercise.
Remember that SLAs are routine for us in Support, which means we are completely comfortable with setting targets that we know we will not hit 100% of the time. Development engineers are not as comfortable with the idea of SLAs as we are, so keep reinforcing the idea that SLAs are targets that probably won’t be hit 100% of the time.
Start with small steps. If you have nothing in place right now don’t try to get SLAs wrapped around every single interaction. Target just one issue at first.
Define a specific process and metrics for each SLA. This is great discipline in any case and will help communicate with precision-minded engineers.
Separate bug fixing and troubleshooting assistance. While most of the interaction between Support and Engineering is around bug fixing, there’s a certain amount of assistance required for troubleshooting. It’s very helpful to separate out the two (and create separate SLAs for them) as they are truly distinct activities – plus you’ll get bonus points from your Engineering friends if you clearly state you need help outside of a bug situation.
Define response time targets. This is a straightforward step: how long will you wait for an initial acknowledgement of the issue (and assignment of a qualified resource to get to the next step: a fix commitment). For emergencies you could ask for one-hour response time (around the clock to boot, if you offer 24×7 support). For lower-severity issues you should be much more patient. Actually for minor bugs there may be no target at all, which means that you will tell customers that their bugs may or may not be fixed. Small price to pay to get better service for the more significant issues.
Define fix commitment targets. Not all issues can be fixed, and some issues require very complex fixes. Therefore, rather than mandating across-the-board fix targets (as in, fix all sev 1 within a week) it’s best to define targets for a fix commitment. So perhaps for a sev 1 issue you can decide that you want a 24-hour target, which means that within 24 hours you will know, and the customer will know (1) whether a fix can be created at all and (2) when it will be available. The targets for lower severities can be longer or even non-existent, as mentioned above.
Track delivery against commitments. Once you have (custom) fix commitments for each issue you can then track delivery against the commitments.
Report three numbers each month. Response time achievements against the targets, by priority, fix commitment achievement against targets, and timely fixes against the custom commitments. By using custom commitments against targets Engineering itself chooses you should be able to get excellent performance on fix delivery, and it’s up to the team to police that the commitments are reasonable.
Try working with fix commitments rather than uniform fix delivery targets: it should be liberating to everyone involved and result in more predictable turnaround times for customers. Moreover, in the few cases when a fix is simply not possible being able to tell the customer about it very quickly makes the message much easier to convey. Once a customer has waited weeks for a decision on a fix s/he is much more attached to getting the fix, no matter what!

For more information about support metrics see Best Practices for Support Metrics. For more information about working on escalated cases see Managing Escalations.

FT Works in the News

SSPA News published an article I wrote about working with support partners. If you are considering having partner deliver first-line support check out Partner Love? Working Successfully with Support Partners at http://www.thesspa.com/sspanews/July09/article3.asp?mtcCampaign=-1&mtcEmail=12105033
The manuscript of the upcoming support marketing book is complete but now comes the second draft, so it’s last call for title suggestions. The book is a complete guide to support marketing, from creating support packages to pricing, marketing, selling, and renewing and I’m looking for a light-hearted title that’s evocative of the contents. Email me your ideas now and no later than 8/7/09. The winner will get a complimentary copy of the book.
Check out the new posts at Marketing Wise, the FT Works support marketing blog.

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