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 May 2004 issue of the FT Word. Please share the FT Word with colleagues.

In this month’s issue:

· managing backlog

· pricing support for backup licenses

· a new FT Works workshop: selecting and implementing CRM tools

Managing The Backlog

Thanks to Alain Cadorette and Dave Crowther for suggesting this topic.

Is your backlog killing you? Are support staffers “thrashing” from too many cases in their queues? Most people start losing it with 30 cases in the queue, some can’t go much beyond 15, but I’ve seen a few who do fine with as many as 60. Customer escalations also rise with backlog, creating unhealthy amounts of firefighting.

How much backlog is too much?

While lower is always better, the best way to measure backlog is to calculate the ratio of backlog to incoming. So if you open 100 new cases per day and you have 100 cases in the backlog, your backlog is 1 day. If you take 1000 cases a week and you have 1000 cases open, your backlog is 1 week, etc.

If you support simple products, a backlog of a day or two is reasonable. With complex product, a backlog of a week or two is reasonable. Always think about reducing backlog, however. A good backlog is a (very) small backlog.

And by the way, any case that’s not closed must be included in the backlog computation, whether the customer is testing, Engineering is working on it, or whatever else. Do not cheat by creating multiple categories to hide open cases. An open case is part of the backlog and it is the responsibility of the case owner to drive it to resolution.

Backlog Management Techniques

Backlog management principles, like much of support, are very simple. The trick is applying them consistently over the long haul.

Measure the backlog at an individual and group level. What gets measured gets done. If you do nothing else about the backlog, at least know how bad it is.
Establish case resolution targets. They should be along the line of “Resolve 80% of incoming cases within 1 week” for complex support (increase the percentage and decrease the timeframe for low-complexity support). Targets should apply to each individual and be part of their performance objectives
Teach support staff how to drive cases to resolution. Cases can remain open for a long time if: the owner is not sure what the customer is asking for; the owner doesn’t know how to resolve it; the owner is too timid to push the customer to do his part; or the owner is too disorganized to stay on top of the cases. Therefore, support staff must be shown how to create a good problem description, how to troubleshoot or ask for help, how to work with customers to get things done, and how to manage time well. Most support skills workshops cover these important topics.
Perform queue reviews. For some reason, this is a very difficult step to accomplish, although it’s very straightforward: each manager should sweep through the queues of each direct report on a regular basis, weekly for complex support, at least twice weekly for low-complexity support, and ensure that each open case is appropriately active. As needed, the manager can provide coaching on the very issues we discussed above and direct the case owner to take appropriate action.
Review “oldie-moldies” at the executive level. A wonderful way to both encourage queue reviews and avoid being blindsided by long-running issues is to review each case older than a certain threshold at the support staff meeting (it’s better than in 1-1 because of the not-so-subtle peer pressure). Simply list all cases older than, say, two weeks and ask each manager to present a one-liner strategy of where the case is going next. I have personal experience with the exercise and it can be done in less than 15 minutes with a team of 100-150 support staffers once you have a bit of practice. The most important thing with old cases is not their age but rather the existence of a clear strategy to resolve them.

Rescue Missions

If you use the techniques above you should be able to keep your head above water at all times. But what should you do if you have a dire situation?

Check with customers. While I would not equate silence with resolution, it’s likely that customers may no longer be interested in very old cases. Try having an administrative person touch base with the customer and ask if the issue is still of interest. You should be able to close many cases that way.
Take it in steps. Use the same techniques as above but temporarily use higher thresholds. So if you have a grand total of 300 cases older than a week, start with a manageable number of the oldest, say 25, even if that means you’re looking at six weeks and older. Next week, go for 5 weeks and older, and so on.
Prioritize with Engineering. I recently worked with a client who had a huge backlog (2 months’ worth!) and more than half of that backlog were cases waiting for a fix. Based on the current throughput, there was no hope that Engineering would be able to get to all the cases within the next year, not counting all the new issues that were coming in daily. Instead of keeping all the cases open, I would recommend working with customers with less severe issues, having a frank conversation with them on how their issues may take months to be addressed. Whenever possible, get their agreements to close the cases once they have a workaround (the bugs stay open, of course). For the severe issues, prioritize relentlessly and work with Engineering to increase the throughput, at least temporarily. My experience is that you have a better chance for success with a reasonably short, prioritized list, rather than a lengthy, all-inclusive list.
Organize a case blitz. If you’ve let it slide too much, asking the support staff to show up on a Saturday and attack the backlog may be very useful. Concentrate on reproducing issues and testing since communications with customers will be difficult. Pay for the overtime. Keep blitzes an exceptional event or staffers will keep sloppy habits waiting for the next one

Mission Impossible?

Most backlog problems go away with good habits, especially regular queue reviews. If you continue to experience stubborn backlog problems despite your efforts, you need to look at other possibilities.
Change your case resolution process. Are you spending too much time on easy cases that should be offloaded to a self-service system? Are there too many layers in the process (a very common problem)?

Increase your staff’s resolution skills. Look both a technical skills and also support skills (some gifted technical folks have trouble juggling cases and pushing them to closure).
Increase your headcount. Sometimes, you just don’t have enough people! If you’re running a tight ship, you should be able to create a staffing model backed by real experience.
Increase product quality. Backlog problems are common with new products and new releases that suffer from too many bugs. With some luck the problems will abate, and perhaps you can work towards better quality for future releases, or some allowance to help you staff better.

Again, most backlog problems can be fixed with discipline and structure.

Pricing Support for Backup Licenses

Thanks to Syed Asif Ijaz for suggesting this topic.

Many vendors offer special non-production pricing for licenses that are used for testing, backup, failover, etc. The question is: how do you price support for those licenses? They certainly require some amount of support (and certainly maintenance!) but not as much, typically, as production licenses.

Let’s start by reviewing the way support pricing works for regular (production) licenses. They are many models out there, including:

named user pricing: there’s a fee for each user of the system, regardless of how often each individual may use it. Named-user pricing often comes in bands of users to simplify the accounting.
concurrent user pricing: up to X users may use the system at any one time, regardless of how many users access the system over the course of a day or a month. CPU-based: pricing is based on the characteristics of the machine it’s installed on and has nothing to do with users
site license: pricing is based on a negotiated agreement with the vendor (often based on number of users or machines, but without restrictions)

For enterprise systems, support and maintenance is usually priced as a percentage of the license price. Support pricing may allow for discounts if the license price is discounted, which it often is. And it may mandate a minimum price, at least for higher levels of support. Although rare in the enterprise space, per-case pricing is sometimes offered.

Many vendors price non-production licenses differently than production licenses. For instance, failover licenses are typically given a steep discount compared to regular licenses to reflect the fact that they are used very lightly, at least everyone hopes so! Similarly, with a per-user pricing model a non-production license is very inexpensive since it has few users. If you use a pricing model in which non-production licenses are inexpensive and you compute support pricing as a percentage of the license price you should be able to apply your normal support percentage to the (discounted price of) the non-production license and get a fair price, and one that’s simple to compute and to justify. Yeah!

Some cases are tougher. For instance, if you price per CPU with no discount for failover licenses, it’s likely that customers will balk at paying the same support fee for the failover as for the main license. Try a significant discount (80%?) for support fees on failover and other non-production licenses. It’s fair and much easier to administer than having to haggle with each customer. You may also want to coordinate with the pricing committee so they incorporate support’s need into the pricing strategy. Good luck!

Selecting and Implementing CRM Systems – A New Workshop

Is a new support-tracking system (or other tool) in your future? I’m now offering a three-day, hands-on workshop entitled Selecting and Implementing CRM Systems to help you make the right choices. See details here. The workshop can also be delivered as part of a coaching program.

FT Works in the News

Would you like to attend a public Tech Support Skills workshop in the San Francisco area? I have found a great location close to San Jose Airport. If you’re interested, please let me know and I will arrange a date that works for you. Space is limited to 15 attendees.

Sbusiness published an article I wrote entitled Planning and Operating International Support Operations: Is there such a thing as a big, happy family? in their March/April issue. Ask for a copy if you are not a subscriber. Or click here.

SSPA News published an article I wrote entitled Managing an Outsourcer: 6 Steps to Success on 4/20/04. You can read it at http://www.thesspa.com/sspanews/042004/article1.asp [requires SSPA membership ; ask for a copy if you are not a member.] Or click here.

I’m hard at work reviewing and rating web sites for ASP’s annual Best Support Web Sites survey. Lots of creative ideas out there! I’ll share some in the next months

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

About FT Works

FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.

Subscription Information

To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.

Back to Newsletter Archive