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 to the March 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
This month’s topics:
- Metrics fest 2: what’s the best way to measure the success of your self-service offerings
- Technical account managers and named support engineers: is there a difference?
- Want to brag about your support portfolio? Be featured in my new book about support marketing – or come learn about creating/improving your support offerings on May 4th in Santa Clara, CA.
Metrics Fest Part 2 – Self-Service Support
Many thanks to Christine Boermeester for suggesting this topic.
Last month we discussed strategies for gathering metrics for assisted support, so it’s time to turn our attention to self-service. Is self-service support working for your customers?
1. Are customers using self-service? The most basic question to ask about self-service is whether it is used at all. If you have 12,000 customers and half of them have never accessed self-service something’s wrong. So one of the basic goals should be to capture overall usage levels. The best metric to use here is simply the number of individual sessions (use the ratio of sessions per customer, to make comparisons easy from month to month or year to year.) Do not count page hits! More page hits are actually a potential sign of trouble for support sites: ideally customers should be able to get to the site, ask a question, and leave having found the answer, so unlike other areas of the web site the support area should receive short visits.
In addition to volume I also like to track (once in a while) the proportion of customers who use the site at all. Let’s say you have 12,000 customers and 12,000 visits this month. Let’s now imagine that each customer paid just one visit to the site. Isn’t that a completely different world from the one of 120 customers each paying 100 visits to the site and the other 11,880 none at all? In the latter situation, I would be curious to know whether the 11,880 customers have ever accessed the site, or even have the credentials (login and password) to do so.
2. What are they using? Some areas of the support web site will get exercised more than others. For instance you may allow customers to update their profiles but it’s not a daily activity while the knowledge base search function may get a hefty workout. If some functionality is not getting used as much as you think it should it could be that it’s hard to use, hard to find, hard on the eye (or all three.) You should see very stable breakdowns of usage by component over time – at least in the absence of any new functionality rollout.
For most support web sites the knowledge base area is the most visited area, sometimes massively more than any others (with ratios of 1:100 or more.) You can see how that would be likely to happen if you restrict access to assisted support (for instance you allow consumers just one call post-purchase.) With high-complexity support when most customers have a support contract the ratio is likely to be much less.
If online case management is used much more than the knowledge base it’s an indication that customers are not trusting the knowledge base to find answers for them. Beef it up! (And remember that, especially in high-complexity support, a customer will likely visit the case management area multiple times during the long resolution of a case.)
3. Are they finding answers? This is really the key question for self-service. Usage is wonderful but you really want customers to be successful finding answers. For one thing, the unsuccessful customer will open a case (and may not be in a great mood about it either) but more importantly the unsuccessful customer is much less likely to use self-service in the future. How can we measure success? There’s no completely foolproof metric here but a great start is to measure the percentage of customers who open a case shortly after visiting the support web site (say, within 24 hours.) Certainly it could be that a customer visits the web site with one issue in mind, finds what’s needed, and then turns around and logs a case on a different issue, but again the metric is reliable enough to be trusted. (And it’s a lot better than asking customers whether they used self-service before logging a case, which (a) annoys them and (b) is notoriously unreliable.) If you have a sophisticated web site you can even measure success for individual components of the web site, as in: knowledge base searches succeed 50% of the time and profile updates succeed 87% of the time. With a sophisticated knowledge management system you should be able to capture success at the individual document level, which would allow you to concentrate your knowledge management efforts appropriately.
Self-service success rates are rarely much better than 50%. That may sound pitiful – after all a 50% success rate also means a 50% failure rate – but that’s the reality, for now. Your goal should be to increase your success rate over time regardless of how low you start.
4. Metrics for interactive web service
If you are offering interactive support via the web you probably want to go a little further than simple measurements of volume and success as discussed above. • For chat or other 1-1 support service use metrics similar to what you are using for cases (i.e. customer satisfaction, productivity, response time.) You may also want to contrast the use of chat with that of other assisted support channels. • For communities, it depends on whether you are treating them as an alternate support channel (customers post questions; you answer) or as a customer-driven exchange (customers post questions; customers answer most questions; you make sure no one gets hurt.) If the former, measure as described for chat and cases. If the latter, you really want to capture the success rate – and you cannot quite use the technique described under #3. Instead, you can ask the customers who post questions to define when they got a good answer (keeping in mind that they may or may not bother, so you will undercount) or you can audit the threads and define success or failure (it’s really not difficult to do, albeit time-consuming, and you can get away with an audit of a small sample of the threads.)
5. Dig in deeper when needed
Clearly there’s much more information that can be gathered about electronic support, but you probably don’t need to gather it every week or even every month. For instance it’s very useful to contrast usage between regions, by customer segment, by product, or by lifecycle stage (new customers versus established customers.)
As mentioned above, detailed information about the usage and apparent success of individual knowledge base documents is extremely useful to the success knowledge management. With some tools you should also be able to capture failed searches (that return nothing); abandoned searches (for which the customer opens no documents); and documents that are retrieved but never read (which indicates a potential mismatch between the search and the result.)
Use these more detailed metrics when you need them. Do not drown the team with an overabundance of metrics. Usage and success rate are the key when it comes to self-service.
For more information about support metrics see Best Practices in Support Metrics.
Technical Account Managers vs. Named Support Engineers
Technical Account Managers or TAMs and named support engineers are common features of higher-level support offerings. What’s the difference between them and does it matter?
Named support engineers are, very simply, support engineers that are the primary contacts for their assigned customers. (Incidentally, I much prefer presenting them to customers are “named” rather than “assigned” engineers, as customers with an “assigned support engineer” have a tendency to believe that they are the only customers for that particular individual…) This means that they handle most support cases for those customers and hence are able to very quickly zero in on solutions since much of the mundane troubleshooting information is already gathered, and even better, in their heads. The benefits of named support engineers, in my experience, are immediately visible to customers and that makes the offerings built around them relatively easy to sell. Named support engineers are senior support engineers who have very strong customer interaction skills. They are not necessarily the most technically knowledgeable support engineers, but they have a solid technical background.
Technical Account Managers or TAMs have less of a technical role and more of a coordination and management role. They are traditionally tasked with delivering proactive support: hold regular meetings with the customer’s management team; review the support relationship, including metrics; provide guidance on new releases; recommend improvements; and also coordinate the resolution of critical issues. To be effective TAMs need to work closely with the sales team and the support team. They need excellent organizational skills and vast reserves of diplomacy and tact. They need to understand the technology well enough to be credible at a management level but they do not need to be able to resolve technical issues themselves.
Q: Can’t one individual serve both as a TAM and a named support engineer?
A: Yes, in theory. However with highly-complex products the supply of technically-knowledgeable individuals is limited, and those individuals that have appropriate technical skills may not possess the coordination skills (or the desire to travel) required for account management so support managers often choose to recruit TAMs that focus on account management. There’s nothing wrong with asking individuals to do both, however, if you can find them!
Q: Is it bad that our named support engineers are performing account management duties?
A: See above. It’s completely fine as long as you have a skilled individual. Note, however, that if one of the support engineers’ accounts is in trouble it becomes very difficult to perform the proactive duties required for other customers.
Q: Can TAMs or named support engineers do other things as well such as perform site audits and provide project management assistance?
A: Yes, as long as you can find individuals with all the skills required – and price the resulting service accordingly.
Bottom line: you can define the deliverables for TAMs or named support engineers any way you want, as long as they are (a) clearly bounded (b) appealing to customers (c) clearly differentiated from other roles such as technical sales engineer or professional services consultant and (d) realistic when it comes to hiring. With that, many high-complexity support centers separate account management duties from case resolution. But you don’t have to!
FT Works in the News
Lots of updates (again!) this month:
- I am looking for a few brave souls to be featured in my new book about support marketing (we need to hold a contest to find a good name, maybe next month?) The idea is to highlight various support portfolios, SLAs, price structures, support contracts, and pieces of support collaterals to inspire best practices. I’d love to publish your name and company name along with the materials but we can do some disguising as needed, so don’t be shy! If you are interested please drop me a note. You will get a complimentary copy of the book if you’re featured in it: famous and well-informed at the same time…
- I will be presenting a one-day course about support marketing right before the SSPA conference in Santa Clara, CA on Monday May 4th. Want to build a better support portfolio? Increase support pricing? Maximize renewals? Find out more here. You can register just for the course or stay on for the entire conference, during which…
- I will be presenting a breakout session about ROI for communities at the conference (Tuesday 11:30) with Tarik Mahmoud of Cisco Consumer Business Group (CBG – Linksys). This is a great opportunity to both learn about creating a community ROI and hear Tarik describe the wonderful use they are making of communities.
- ASP will be once again holding its Ten Best Support Web Sites contest this year – and I will again serve as a judge. Entering the contest is a great and inexpensive way to get some impartial advice on your web site, and naturally the winners get bragging rights. To enter go here . The deadline for entry is March 6th so hurry. (More information here )
- Finally 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.
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.
You may reproduce items in this newsletter as long as you clearly display this entire copyright notice. Contact us if you have questions about republications.