The FT Word – March 2012
Welcome
Welcome to the March 2012 edition of the FT Word. Feel free to forward it to your colleagues. (They can get their own subscription.)
Topics for this month:
The FT Works indicator – $53.4 million
Why I hate benchmarking – and you should do
Support newsletters – what is the best approach and where to find good topics to cover
FT Works at the TSIA Spring conference in Santa Clara: support website design, metrics fest, and a booth!
The FT Works Indicator: $53.4 million
That’s the latest round of funding for Lithium, the well-known community vendor. Seems that social media is worth betting on, doesn’t it?
Why I Hate Benchmarking – And You Should Too
Let me start with a candid admission that I work on a lot of benchmarking projects and I love them, so perhaps the title should read “why I hate shoddy benchmarking” – but it would not be so tantalizing then, would it? So why do I hate (shoddy) benchmarking? Let me count the ways…
Because it’s not an arms race
The other guy has online diagnostics so you need online diagnostics, too. Maybe. What’s your goal? What’s your strategy? If your strategy is to provide customized support to a handful of highly valuable customers, it could be that the very last thing you need to worry about is to provide online diagnostics. Strategize first, then benchmark.
Because the comparison group is too wide
I very often get asked what a “good” cost per case would be. Well, it depends. I have clients who spends tens of dollars on each case and others hundreds of dollars (and one who estimates spending $2,000 per case!) And most of them have a “good”, normal-for-what-they-are-delivering cost per case.
The word benchmarking comes from cobblers making custom shoes who needed to measure carefully (on the bench). They measured the customer’s foot, not some random person’s who happened to be passing by…
Because the comparison group is too narrow
On the other hand, it’s often very interesting to expand the comparison group to a much wider scope. For instance, many support innovations in the realm of self-service have come from B2C vendors, spurred by their drastic need to reduce costs. If you systematically exclude vendors outside your industry you may never get the inspiration to try new techniques. For instance, the metaphor of the hotel concierge may be a good inspiration for a technical account management program, even if the wisdom dispensed is not about restaurants or airport transportation, but how to maximize user adoption of your tools.
Because common practices are not necessarily best practices
This is where I invoke my father, who used to rage when we would tell him that we had to do this or that because “all our friends were doing it”. Everyone may be wearing skinny jeans but maybe it’s not the right look for you. And everyone may blissfully ignore customer requests for product enhancements but more successful vendors don’t – one of many examples on what “everyone” is doing badly.
Because checklists obscure the interesting details
“Does vendor X have customer communities?” What’s interesting is not yes or no, but rather how the communities are run. Is there an internal owner for the community? What’s the traffic like? Do questions get answered? Is there an internal commitment to provide answers? Are customers using the community? Are communities integrated with the other self-service functions? And on, and on.
Because numbers can be defined in many different ways
Let’s say you are comparing resolution times amongst a carefully defined group of vendors that match your characteristics. One claims to close 80% of cases within a week. The other never closes cases until the customer positively confirms the solution is working. Yet another keeps all cases associated with bugs open until the bug fix is delivered, however minute the bug. And another only considers when a solution has been delivered to customers, never time to closure. Simple question, difficult analysis, and you will never know until you ask how the metric is computed.
Another near-impossible comparison is support expenses, since no two vendors treat expenses such as facilities, IT, or “corporate overhead” quite the same.
Because global does not mean the same everywhere
Moving on to self-benchmark, the kind where you use you compare your own performance against itself. No issues of comparing to too-narrow or too-die group, no number definition issues – but it’s not quite perfect.
For instance, NPS scores are X points lower in Europe than in the US. Should you rush to schedule remedial soft skills training in Europe? Not necessarily. The customer base may be different, the cultural norms certainly are different, and volume may also play a part. Don’t start with the idea that all your teams everywhere must by fiat hit the same numbers, at least unless you understand the differences in process and customer bases.
Because obsessing on small changes is silly
SLA achievement is up (or down) by one tenth of a point this month. Quick, why are we seeing a variation? Because that’s the way things work. The idea that you will have a constant level of performance on any support metric is not realistic. I would certainly be concerned if I saw a big decline, or a sustained decline, but small changes up and down should be simply ignored.
Because the underlying data may be plain bad, or gamed
And finally, benchmarking, the self kind or otherwise, is a waste if the underlying data is bad, and you can be sure it will be bad, or at least tainted, if you place heavy requirements on the team to meet a single target. So yes, measuring the number of interactions with customers to capture the complexity of a case is a good idea, but if you put a target on the number of interactions you can be sure that at least some people will do all they can to hit the target – and in the process destroy any hope that the measurement will be meaningful.
So long live benchmarking – but only the careful kind!
Support Newsletters
Thank you to Aine Shinners for suggesting this topic.
It seems that in the current infatuation for self-service and peer networking we are somehow leaving behind the good old support newsletter – the newsletter that may never have worked, actually, because a good writer in a support team is hard to find, and probably already chained to the desk writing knowledge base documents. In any case, is it time to resurrect the support newsletter? Ten thoughts to get you started.
1. Proactive communication is a great idea
If we want to get out of the pure break/fix business, then you can just sit there and wait for customers to log cases. You have to put the word out there.
2. Think blog
A newsletter is well, so old-fashioned (she says even as she writes one, faithfully, each month). Go with a blog, so much more modern, versatile, and apt to generate discussions.
3. Find writers
This may be quite difficult, as noted above, but writing a short blog post is infinitely easier than putting together a newsletter. Pick someone with a “voice”, not some bland sophomore English paper correctness.
4. Invite guests
Welcome guest posts by development engineers (some are quite good writers!), consultants, marketers, as well as partners and customers.
5. Post at least weekly
It doesn’t have to be a long post but it must be frequent.
6. Include technical and non-technical items
Geeky entries are welcome but don’t be afraid to post non-technical items that would be of interest to the readers – who may not care about the new product pricing (if they only use the product and are not involved with purchases) but may welcome a picture of the brand-new support center, or the newly-minted support engineers fresh from their new-hire training class
7. Be open and transparent
Post good news and bad news on the blog. Crow about your record-high customer satisfaction ratings but also admit to failures and problems. Customers want you to be honest, not slick.
8. Push it
If you’re going to go through the effort of creating a blog put it right there on the support landing page. That will force you to keep it current!
9. Tie in with the knowledge base
Use the blog to announce particularly interesting knowledge base (or communities) information. Many moons ago my team put together a newsletter (no blogs existed then) based mostly on what documents got the highest use during the month. Very little work was required!
10. Encourage customers to contribute ideas
You don’t have to do all the thinking: ask customers to make suggestions, and also track the popularity of the various posts to pinpoint the kinds of topics that are read the most.
11. Bonus point: Don’t sell (directly)
The whole point of a support blog is to highlight the great value that you add to your customers’ use of the products, but don’t use it to sell anything blatantly, whether products or even support. It’s fine to announce a new premium support offering, but don’t repeat the announcement multiple times in an effort to promote it.
FT Works in the News
Mark your Calendar: May 7-9 in Santa Clara, CA (TSW)
FT Works will have three events at the upcoming TSIA conference. Hope you can join us!
1. We will have a booth in the expo hall.
2. I will present a pre-conference workshop on Monday 7th entitled “Winning Support Websites: From Assessment to Customer Love”. If you’ve always wondered why your website doesn’t work as well as you’d like, join me. Registrations will be up shortly online but let me know if you are interested and I’ll save a seat for you. John Ragsdale has a nice write-up about the workshop here http://jragsdale.wordpress.com/?mtcCampaign=-1&mtcEmail=12149681
3. I will have a joint presentation with Scott Sieper of Autodesk on Tuesday 8th entitled “Measure Twice: Cut the Useless Metrics” in which we will present a comprehensive support dashboard. No need to register for that one, just show up!
The details of the schedule are taking shape at http://www.technologyservicesworld.com/schedule/&tab=0&atg=0&ConfID=28&END=END
Third Tuesday Forum Lunch – March 20th
The next Third Tuesday Forum breakfast is on March 20th and will feature David Kay and me. The same people who brought you Collective Wisdom are teaming up for a romp through support measurements and metrics. For variety’s sake and just because, we will meet at lunchtime rather than breakfast, so all you sleepyheads just lost your excuse for not coming.
You can read more here and register. Space is limited so we can bring you an interactive experience – guaranteed to be PowerPoint-free.
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.
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.
