The FT Word – September 2004

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 2004 issue of the FT Word.

In this month’s issue:

  • “magic numbers” – what are reasonable targets for metrics in complex support centers?
  • implementing VoIP solutions in the support center

Magic Numbers

Thank you to Bill Heilman, Neil Baron, and countless others who have challenged me over the years to give best practices targets in all areas of support.

Creating a solid support dashboard is a fantastic idea. But what should we expect or shoot for in terms of targets? It’s one of the most popular questions I get (right behind “what’s the perfect organizational structure for support?”) and one of the most difficult ones to answer since, after all, it all depends — on your support model, your audience, the maturity of your organization, and so on.

Therefore, with all proper caveats, here’s what I look for in organizations I review.

Response Time

Most complex support centers handle many electronic requests so simply using the ACD average speed of answer is misleading. Instead measure how long it takes to respond to customer queries from the time they are made to the time a qualified technical person handles them. You should meet SLAs at least 90% of the time to be happy. 95% is extra-good. 80% or lower forecasts a customer riot.

Case Productivity

The main factor that determines case productivity is product complexity. Most of my clients support complex products that may require a few hours to resolve an issue. Therefore, anything from 2 to 5 cases per staffer per day is good. If you use a tiered organization numbers should be significantly higher for level 1 staff, lower for levels 2 and above.

Note that this is a long-term average. There are days when not a single case gets resolved, either because the staffer was out or in training, or simply had a bunch of hard cases that did not close. Other days may see a performance double or triple that. In complex support environments it makes little sense to obsess about daily outcomes since one tough case can ruin your whole day.

Case Aging

Here again product complexity is a key driver, but I notice an interesting phenomenon even in highly-complex support centers: those that establish resolution time targets and reward staff based on achievement do much better than the ones that do not, and they do not experience customer satisfaction problems. Does that mean you should target to close 90% of cases within a day? Probably not, at least not if you support highly complex problems. Try 80% of cases within a week.

Customer Satisfaction

Did you know that the main driver for customer satisfaction *with support* is product quality? It’s a bit frustrating for us on the support side, but that’s true. The #2 driver is quality of support, so we can certainly influence that.

Assuming that you are using a transactional (per case) survey with a reasonable return rate of at least 10% (20% is best), shoot for 8/10 or better average ratings. Great organizations make it all the way to 9/10: here’s a stretch goal for you over-achievers.

Handoff Rate

It’s very hard to predict handoff rates since they are intimately related with the model and staffing you are using. However, in keeping with the idea that customers would like their problem resolved by just one person, the lower the percentage the better. I find better (i.e. more successful) support groups keep it around 10%. If you are using a dispatch model in which each customer talks to an administrative person first, you’re all wet on this one!

If your handoff rate is high, you need to train your lower-level staff better. Exception: if your bug rate is also high (see the next point) you have a product quality problem, not necessarily a support problem.

Cases due to Bugs

Product quality is the main driver for the percentage of cases due to bugs. Once you’re past the bumpy beta timeframe, look for a bug ratio less than 5% (2% is even better). A large percentage of bugs means that you are spending too much effort on support and not enough on QA

The Power of the Self-Benchmark

We saw that in some areas it’s hard to define a good target. The solution is to use a self-benchmark: simply compare the results of your top 10% performers with that of average performers. If it’s 2 or even 3 times as good, it’s normal: top performers really are 2 or 3 times as good as average! If top performers perform 5 times better than average, however, you have a performance gap and you need to 1) weed out poor performers and 2) figure out what techniques the top performers use that others are not using.

For instance, if your average productivity is 2 cases per day and the top producers resolve 5 cases a day, it’s normal. If they resolve 12 cases a day, you have a performance gap and you should be able to raise your productivity significantly.

Implementing VoIP in Support Centers

There has been a lot of buzz around using VoIP solutions in support centers, with enthusiasts (including vendors) extolling the marvelous simplicity and low cost of the system, while critics point to poor quality and failed initiatives. What should we believe?

There are real benefits

The idea of VoIP is simple: use the same network to carry phone calls and electronic communications. By definition, VoIP

  • simplifies operations since there is only one network to take care of

  • makes it easy to integrate new offices, including offshore and home-based offices

  • greatly reduces the overhead associated with moves

  • and, less obviously, allows easier integration with other applications in the enterprise

But there are risks

It’s hard to compete with an established success: the phone company has over a hundred years’ experience in delivering a reliable, high-quality service. VoIP is just starting out and has not reached the same levels of reliability and quality. Also, there are few skilled implementers for VoIP solutions and indeed many implementations don’t deliver on their promises.

So what should you do?

  • consider VoIP solutions whenever you’re building out a new office. Most VoIP solutions are for new buildings rather than conversions from existing PSTN systems

  • carefully test and improve the network to handle voice traffic. Failed installations most often neglected that important step and tried to shoehorn voice traffic on top of an already burdened network.

  • run simulations of the voice traffic to pinpoint bottlenecks and other problems. Phone traffic in support centers is much higher than in other functions so insist on realistic loads.

  • think through the security requirements. You may not need to encrypt voice behind your firewall, but on the public network encryption is a good idea.

  • plan for reliability issues, especially if you have a 24×7 operation. What if the power goes off? How will routine maintenance be handled?

VoIP is an exciting new technology, well worth exploring when you reach limits with your existing phone equipment.

FT Works in the News

Interested in CRM technology? I will be teaching Selecting and Implementing CRM Systems at San Jose State University on October 11-13. You will leave the workshop with a complete project plan you can use for your support organization. The course description is at http://iesweb.sjsu.edu/searchprofdev/searchCourse.java.jsp?command=1&courseId=19139 (the course is slightly different, don’t worry about it!) You can call the registrar at 408 519 1272 to enroll. Feel free to contact me for more information.

Sbusiness published an article I wrote entitled Classroom or Self-Paced Training: choosing the right delivery mechanism for training support reps. Sbusiness Journal, July-August 2004.

SSPA News published an article I wrote entitled Metrics, metrics everywhere! Sorting out good, bad, and useless. SSPA News 8/17/04 http://www.thesspa.com/sspanews/081704/consultants.asp [ask me for a copy if you are not an SSPA member.]

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