The FT Word – June 2010
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 June 2010 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
- SaaS support – what’s different and what’s unique?
- Cost per case – how do we compute it in a world of self-service support, and does it matter?
- And, as always, an invitation to attend the upcoming Third Tuesday Forum breakfast, which will welcome Caeli Collins of LSI International to discuss acquisitions. Sign up now.
SaaS Support – What’s Different? What’s Unique?
Many thanks to Jack Yuan for suggesting this topic several weeks ago. Since SaaS support was a major theme at the TSIA conference last month, this is a hot topic! And clearly SaaS offerings are multiplying. Customers love them because they take the IT burden away from them – and most feel that the benefits outweigh the customization limitations of SaaS environments. The question for the support community is whether we are ready to deliver high-quality support in a SaaS environment. How different is SaaS support?
There are some unique aspects
1. How support is packaged and sold
Support is usually packaged and sold as a bundle with the SaaS service itself. This means that, from the customer’s perspective, support can be seen as “free”. And from an internal perspective the support group is more likely to be seen as a cost center – but that’s often the case with packaged software anyway.
However, even in a SaaS model, the premium support offerings, that is all offerings beyond the basic level of support, are usually sold separately from the subscription itself and therefore are sold in a manner similar to non-SaaS support environments. I find that SaaS vendors are often slow to offer premium offerings and miss out on the opportunity to provide better service to high-end customers while shoring up their revenue.
2. End-user support
Some – but no means all – SaaS vendors offer support to end users while for packaged software vendors typically restrict support to a handful of authorized contacts. End-user support is a different beast than so-called level 2 support, with many more “easy” questions and a very different profile of users. If you provide end-user support the profile of the support staffers will be different, less technical.
3. 24×7 support
Because the underlying service is offered around the clock, there is more of a pressure for SaaS vendors to offer 24×7 support to match, although many vendors end up not providing it, at least for the basic level of support. This is one obvious opportunity to convince customers to upgrade to a premium level of support.
4. Version control
No need to plead with customers to upgrade to the latest release with a SaaS environment since typically the vendor does it automatically. This greatly simplifies training and bug fixing.
5. Tool integration is very useful
Tool integration here means integrating the case-tracking tool with the entitlement-tracking system since changes are more frequent. And it also means integrating with the SaaS service.
But much is the same
While there are some unique aspects to SaaS support, many of the practices of packaged support and its discipline can transfer readily to the SaaS environment. Here are four examples.
1. Self-service is a key component of the support mix
This includes the standard FAQs and knowledge base as well as support communities (forums). The potential for support communities may be stronger for SaaS than for packaged offerings since users are working with very similar setups – more similar than would be attained with a packaged solution. If you are supporting end users, self-service is even more important.
2. Support channels are the same
Whether you decide to offer phone, web portals, or chat, you can use the same for SaaS support. (I continue to say “kill email” as a case-logging mechanism. Please join me in this effort.)
3. Handoffs out of the support team are similar
For packaged software vendors, escalations will go to Engineering while for SaaS vendors the first stop is more likely to be the Operations group, but handoffs and escalations are required from time to time, they need careful processes and service-level agreements, and they create bottlenecks.
4. Supportability is key
Again nothing new here: the big job of the support organization is to be the Voice of the Customer. This means that metrics (hence a solid base of data) are essential for successful management of a SaaS support organization.
Have you read the classic book about managing support organizations? Try The Art of Software Support.
Cost per Case
Many thanks to Eric Dreshfield for suggesting this topic.
Cost per case (or cost per call, as old-timers remember it) has been a standard support metric for support organizations for years. But the sad truth is that it’s often badly misstated, used inappropriately, and perhaps not the right measure of support value at all. So let’s explore why and how to properly compute and use cost per case.
1. Perhaps cost per case is not such a great metric
Cost per case (assuming it’s properly computed) tells us how much it costs to resolve an average customer request. This is a very interesting figure in that, for instance, it can tells us that if case load increases so will cost – and vice-versa. But it’s also reductive. Could it be that support is all about cases? Of course not! What about the value of software updates, of self-service, of community forums, of proactive activities such as webinars, blogs, or account management? By focusing solely on cost per case we forget – and make others forget – that support is not all about solving cases.
And even if we focus on assisted support only, cost per case is only a part of the story. if the cost per case for Vendor A is $100 and the cost per case for Vendor B is $200, we have no idea who has the lower cost per customer, since that would depend on the incident rate, that is, the volume of cases per customer. If Vendor A’s customers log an average of 10 cases a year its average assisted support cost is $1000 and if Vendor B’s customers log only 4 cases a year it has a lower cost of $800.
Finally, do customers really value cases that much? If, through the effort of the support organization, customers are “spared” having to contact support because they are alerted to a potential problem or, even better, the product is improved to avoid the problem entirely, will the customer somehow receive less value? Of course not.
So do measure cost per case but remember it’s only a portion of either cost per customer or value to customer. For that reason cost per case is not a key metric, one that would deserve inclusion on an executive dashboard, for instance.
2. Cost per case is a simple division (even today!)
I’m always puzzled when customers tell me that they don’t know their cost per case and that they simply cannot compute it. Hogwash! Since support organizations have a pretty good idea of their overall budget and the case volume, then cost per case has got to be something like: budget / case volume. Pretty simple. (I know I’m avoiding sticky topics such as whether facilities or IT overhead is included in the budget figure. Let’s keep it simple.)
If you have a clear division of labor between staff members who work on non-assisted support and others, by all means exclude the former from the calculation. But don’t worry too much about dividing everyone’s time perfectly between the two types of activity. It’s probably not worth it.
3. Cost per case is not the outsourcer’s price
Vendors who use outsourcing often use the outsourcer’s price as their cost per call. It may be the right figure for those cases that are, in fact, resolved by the outsourcer, but it entirely understates the true cost of the average case, since some percentage (often 15%) will be escalated back to the vendor and cost a great deal more. It’s fine to use the outsourcer’s price to compare against other outsourcers, but seriously misleading to use it as the standard cost for all cases.
4. Cost per case can go up or down
This is a common experience. A vendor implement a great self-service system and cost per case shoots up. Is that a problem? Not really. Chances are that the easier cases are now handled in self-service and the cases that do come in are more complex, hence more costly. It’s a beautiful and desirable outcome – as long as the incident rate decreases, which it should, which means that the cost per customer will go down, as illustrated under point #1.
Another common situation is that product quality improves, hence the incident rate goes down, but since the very same number of support staff remains dedicated to cases, cost per case increases. Same numerator, smaller denominator, hence higher cost per case. The organization is now “overstaffed” compared to the prior time period, hence the variation. It could be a good and normal development if the support reps were previously working nights and weekends to keep up. Or, it could be a time to resize the organization, assuming that no wave of new customers is coming.
5. There’s no such thing as an “industry” cost per case
I have clients who report an average cost per case of $2 (usually it’s the outsourcer’s cost, see point #3) and others who report over $400. Is that normal, doctor? Well, yes, my clients simply support very different products and very different customers. Never try to compare yourself to the industry as a whole: such comparisons are obviously misleading. Always attempt to compare yourself with similar support organizations. And again cost per case may not be the right measure. Cost per customer is a much more important metric, and margin percentage is best if you charge for support.
6. Use cost per case responsibly for calculating ROI
A classic use of cost per case is to compute the ROI for self-service initiatives. To simplify, the idea is that we deflect N cases at $y per case so we save $N*y. Sounds great, huh? It is, indeed, the right computation; the difficulty is in evaluating N and y. At the simplest level, never equate self-service usage with deflection. (Fact: when you use online banking to check whether a payment has cleared, would you call the bank instead? Not 100% of the time. So deflection is never 100%.) And you may not want to use your full-fledged cost per case in this situation, since the more complex cases are less likely to be deflected. This could be the time to use your outsourcer cost per case.
If you’d like to hear more about ROI computations, drop me a note and I will expand on it in a future issue of the FT Word.
And for more on support metrics read Best Practices for Support Metrics.
FT Works in the News
Veterans2Work
US readers: if Memorial Day had you thinking about putting veterans to work, you may want to consider Veterans2Work (V2W) as a partner. V2W’s mission is to improve the employability and job success of special needs veterans. Organized as a non-profit, V2W is run as a business, helping veterans find and keep good jobs by meeting the needs of businesses. Its outsourced customer care services are delivered by special needs U.S. veterans (and their caregivers) working from their homes. Workers are drawn from a growing pool currently numbering 1,500 veterans. For more please visit www.veterans2work.org or call 415-925-1515.
Third Tuesday Forum
Are you based in the San Francisco area (or will you be there on Tuesday June 15th)? That morning, David Kay and I will be hosting The Third Tuesday Forum, a roundtable for support executives to discuss the topics we embrace and wrestle with every day. Our presenter will be Caeli Collins from LSI, who will speak about surviving and thriving during acquisitions, an experience many of us have had and are likely to experience again. It should be fun and informative – and as always, PowerPoint-free! To register or for more details, click here. Space is strictly limited to ensure an interactive session.
If you cannot make it this time but would like to be on the mailing list, sign up. You will be the first to know about new events. You can also join the Third Tuesday Forum groups on LinkedIn and Facebook. And check out our speaker for July.
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
