What is the ROI of our self-service options?
Many thanks to Steve LaRoche and Tony Long for suggesting this topic — and thank you for your patience as I slowly pushed this post to publication!
ROI questions often arise at the start of an initiative, to justify acquisition costs, but they are even more interesting when considered once the initiative is well under way. Now how can we possibly capture the ROI of self-service, be it for knowledge management or social support (forum)?
Idea #1: “Value” is not just monetary.
This may be profoundly unsatisfying to those who believe that hard data is the one and only way to manage a business, but it’s true nevertheless. Can you simply not offer customers any self-service options? I don’t think so: every support website needs some self-service offering. What is the value of monitoring Twitter so as to swoop in when a problem is reported, before it spreads? Priceless, as the old Visa commercial used to say.
Some benefits can and should be quantified in monetary terms, but others cannot. Typical benefits of self-service include: lower case volume, internal productivity improvements (because the support engineers themselves use the knowledge base, or even the forums, to find answers), increased sales, increased customer satisfaction, increased employee satisfaction, and better analytics. Of those, customer and employee satisfaction are essentially unquantifiable in monetary terms, and better analytics may not, either. Don’t try to fit square pegs in round holes: measure what can be measured, and present the rest as important, perhaps essential, but not financially quantifiable.
Idea #2: Measuring what does not happen is an exercise in uncertainty
The main return from an investment in self-service is usually a decrease in traditional, assisted support volume. It makes sense: customer seeks answers on the website; customer finds answer; customer who would have asked for help foregoes expensive 1-1 assistance. But how do we capture that the request for help did not happen?
- Counting each and every website session as a “deflected” case (what a horrid word!) is obviously overkill. Customers may be trawling for information for which they would not log a case.
- Using an arbitrary ratio to establish the number of “useful” sessions makes no sense either. Who is to say that every 7th session replaces a case, or every 6th?
- Try a top-down approach instead. If customers used to log 2 cases, on average, before the new knowledge base, and now log 1.5, you are saving .5 cases per customer per month (which would be high: this is just an example). It could be that the product has gotten much less buggy, or that customers know that service is so bad that they have given up trying! If you can correlate customer usage of the knowledge base and a decrease in case volume, your justification will be stronger.
- A very clean demonstration of deflection would be to present customers promising knowledge base articles when they log a case. If they discontinue case logging, it’s an excellent sign that you just deflected a case — but the approach seriously undercounts other deflection events (and may well annoy customers!).
- An alternative is to ask customers whether they found what they wanted when they visit the website, via a popup for instance. If “yes”, count the visit as a success (deflection). You only need to survey a small percentage of users to calculate your deflection ratio.
Idea #3: It’s easier (but not easy) to measure internal productivity
The support engineers use the knowledge base to provide answers faster (and better answers, to boot) and they may well mine the forums for answers. That would be reflected in their productivity metrics. Even small improvements are notable. Remember that, if the self-service options are taking care of easier questions, the support engineers’ productivity may go down as they work on harder issues (but fewer of them!) so consider productivity in terms of customers, not cases.
Note that measuring links between articles and cases cannot yield a financial justification — and may well lead the support engineers to create nonsensical links. However, you can cross-reference productivity and link percentage to see whether the most productive engineers do use the knowledge base more.
Idea #4: Small benefits are not worth measuring
In most cases, case deflection and increased productivity are the main drivers of savings, by very far, and it does not make sense to invest much time or effort measuring the much smaller benefits such as increased sales. I once worked with a cell phone provider who demonstrated significant incremental sales stemming from forum recommendations, so your mileage can vary, but gnerally speaking focus on the intuitively larger benefits and ignore the others.
And don’t forget to add up costs. They go well beyond the technology costs — but virtually all well-managed self service offerings create large positive returns.
What have you done to compute the ROI of self-service?
