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 December 2010 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
- Moving to Touch and Hold – how to lead, motivate, and seduce support engineers into a new case resolution model
- What’s a successful knowledge base? In search of the perfect knowledge management metric (hint: it’s a little more complicated than that)
Moving to Touch and Hold
Many thanks to Diego Clachar for suggesting this topic.
There are essentially two models for case resolution: the classic tiered model, in which issues are moved to a senior team when they become too old or too complex for the first tier to handle, and the Touch and Hold model, in which the case owner remains the same until resolution, said case owner seeking help from others when needed. The Touch and Hold model is well adapted to complex support for which most issues are complex and require investigation – and it avoids awkward handoffs during which information can get lost.
If you decide to switch to Touch and Hold, you will likely realize that your team may be less than enthused about switching. So what can you do to ease the transition?
1. Make sure Touch and Hold is the right model for you. I am a fan of Touch and Hold, but it’s not always the right model, and if it’s not you will have an especially terrible time convincing the team to move to it. Touch and Hold is not the right model to use if you have lots of easy (already known) issues and only a few complex ones, since it would be a waste of your support talent. And Touch and Hold may not be the right model if you have a large number of junior staff, who will have to request help on most issues. (Sure, they will learn over time, but on the customers’ dime – not a good idea.)
2. Educate the team on Touch and Hold. Most support engineers, even with years of experience, has experienced only the tiered model. No wonder they are a bit skeptical of the newfangled, seemingly crazy concept of Touch and Hold. Take time to describe the approach and its benefits, both for customers (work with just one contact, no waiting in successive queues, no need to rehash the same story again and again) and for the support staff itself (more freedom to explore and learn, more variety). Be careful not to oversell the model and create unrealistic expectations. No model will magically resolve customer issues!
3. Line up a solid Backline. The trick to getting Touch and Hold to work is that case owners should be able to very quickly locate and receive technical help if they need it. The usual mechanism, at least with not-tiny support teams, is to create a Backline group whose function is to serve as a help desk to others. Backline is not simply tier 2 with a different name. Backline engineers don’t own cases, for one: they simply help with cases. Backliners offer a high-interrupt help desk function, so their temperament is quite different from a standard tier 2 engineer. And Backliners must be proactive as well as reactive, conducting group and individual case reviews to expedite resolution. So you are looking for special individuals, and not every tier 2 engineer will fit the bill (and sometimes you will find a great candidate in tier 1!)
4. Beef up training for Frontline. Tier 1 engineers have a relatively circumscribed task. Some are curious and will work to learn more, but not all do. In the Touch and Hold world, all Frontline engineers need to have solid technical skills, so additional training will likely be needed. Line that up.
5. Combat Frontliners’ worries about handling issues they don’t know. Some tier 1 engineers will be thrilled, thrilled, to see their horizons expand with Touch and Hold. But others will be quite frightened at the prospect of becoming responsible for resolving each case they grab. Offering additional training and a solid Backline is a good start to alleviating the concerns, but it’s important to identify who is really scared, and work with that group.
6. Work with the higher tier staff being reassigned to Frontline. This may be the toughest challenge of all. A typical ratio of Backline to Frontline is 1:10, which means that not every tier 2 engineer will become a Backline engineer. And in any case, not every tier 2 engineer is a good candidate for Backline, whether they recognize it or not. So you will have to work with individuals who will feel demoted – even if you don’t change their job grade or they pay, which you should not do! It is sad that in many support organizations the idea of dealing directly with customers has become a badge of dishonor, isn’t it? Identify individuals who will transfer to Frontline but whom you want to retain on the team, and lavish attention on them. They are particularly vulnerable to turnover.
7. Leverage the tracking tool. Most tracking tools support the concept of a subcase, which nicely matches the requests from a Frontline engineer to Backline. You can queue subcases on a special Backline queue, or direct them to specific individuals. And subcases offer a handy mechanism to track Backliners’ activities. Make it very easy to request Backline help.
8. Fight backlog. While I love Touch and Hold, I also realize that a common pitfall for it is an elevated backlog, caused by Frontline engineers being shy about asking for help. Therefore it is essential that managers (and Backliners) conduct regular and aggressive backlog management efforts, scouring individual queues to ensure that no case is ignored. With time you will quickly identify individuals who have a challenge in this area and you can concentrate the oversight on them.
9. Adjust individual objectives. If everyone (in Frontline) is responsible for solving cases it makes sense that resolution time is an important objective for everyone. If you want Backliners to proactively offer assistance they should probably be goaled on customer satisfaction for the teams they oversee rather than just the number of assists they provide. Make the objectives match the new goals.
10. Create a message for customers. Customers don’t need to understand the details of how cases are resolved, but they will quickly realize that tier 2 seems to have disappeared. Equip the entire support team with a simple, consistent message for customers. Yes, we are switching to a Touch and Hold model. Yes, this will ensure that you can work with the same individual through resolution. Yes, we can leverage a world of expertise on your behalf.
In my experience, it can take a good six months for Touch and Hold transitions to settle down, and it’s likely that you will lose a (small) number of engineers in the process, both tier 2 engineers who cannot accept a perceived demotion to Frontline and tier 1 engineers who can’t cope with the pressure of owning cases to resolution.
For more information about the Touch and Hold model, see The Art of Software Support, in which Richard Farrell and I first described it in 1996.
What’s a Successful Knowledge Base?
Many thanks to Kiran Kaur for suggesting this topic.
How can we gauge whether our knowledge management efforts are successful? Good question. Is there a single number to gauge success? Nope! There is no single metric, but the good news is that it’s a lot more interesting than staring at a single metric. Here are some guidelines for knowledge management metrics.
1. Don’t look for one number. Knowledge management is a complex enterprise that simply cannot be boiled down to a single metric.
2. Remember your strategic goals. Why are you engaged in knowledge management? To build up internal efficiency? To increase self-service? Tie the metrics to your goals.
3. Measure outcomes. It’s very easy to measure activities, for instance how many new documents (solutions) were created last month. Are more documents “better”? Of course: a completely static knowledge base would be a strange development, surely. But it’s also very easy to create loads of low-quality documents that will simply gum up the works. In the same vein, it’s a good sign when the support staff performs lots of searches in the knowledge base, but if the searches don’t yield anything, it’s not success you are looking at but frustration. So feel free to count the number of new documents or the number of searches but also capture more meaningful business outcomes. For instance, is the incident rate (average number of cases logged by customer) going down – presumably because customers are using more self-service? Are the support engineers able to resolve cases faster because they can reuse knowledge? Are support costs decreasing? Those would all be examples of business outcomes.
4. Beware of quotas. It’s bad enough to measure activities and it’s especially bad to assign quotas to them. Why? Because it creates a perfect opportunity to game the system. If you tell me to create 4 new solutions per month, I will create 4 new solutions per month (heck, maybe even 5, just to show how hard-working I am). There’s no telling what the quality of the solutions will be. If you tell me to search on every case and you tally the number of my searches I will be sure to search a lot – using random searches if needed. So beware of single quotas on specific activities – although a mild quota for creation may be just fine, as long as it’s not too high and you have a way to check quality.
5. Look at knowledge management in the larger support context. It’s fine to measure new documents (a pure knowledge management metric) but it’s hard to imagine how you could evaluate the success of KM without looking at customer management, not to mention case management.
6. Consider your tool limitations. If your tool won’t let you distinguish links between documents and cases from citations (links created by someone else than the author), recast your wishes toward what you can measure – but don’t give up the ultimate goals of measuring balanced outcomes.
7. Leverage internal benchmarks. I often get asked how many documents a single support engineer should be expected to create. I have no idea! (Well, if you know me you know I have opinions on everything, but I don’t know the exact number you specifically should be shooting for.) The best strategy is to compare behaviors from month to month and amongst your pool of support engineers. If everyone’s creating three solid documents a month and Bob has created none for the past quarter something’s going on that you should investigate.
With that, here are some interesting metrics to measure and ponder for knowledge management:
- Creation/edit volume. Yes, this is an activity metric and yes, it is silly to only look at volumes, but still, volumes are important. Consider the editing and deletion volumes, not just creation, after the initial rampup time.
- Case quality. This metric has become a favorite of mine, although it requires some work, because it captures in one fell swoop the quality of the case resolution as well as knowledge management behavior. Two for the price of one! The idea is that managers or senior engineers review (audit) a small portion of individual cases and rate them in terms of appropriate troubleshooting, use of tools, and case notes, which include correct reuse, updating, or creation of knowledge base documents. This is a much better way to ensure document creation than the simple and easily-gamed quota – and the benefits on the case resolution side are great, too. You could instead use a measure of the quality of the documents created, but that only gives you part of the picture.
- Quick closes. Whether you consider FCR, First Call Resolution, or 24-hour closes, a strong knowledge base should enable fast resolution of repeat issues. Note that if you are also doing a great job of self-service you may see a decrease in quick closes. Fun, huh?
- Productivity. Here I mean case productivity (cases closed per head). If the emphasis is on self-service you may experience productivity decreases since the easier issues are deflected. So seek to also measure customer productivity (customers per head). That should go down with a good knowledge management system – barring new products, buggy releases, and other frequent events outside the control of the support organization!
- Customer satisfaction with the knowledge base. While case quality will do much to capture internal satisfaction, there’s no substitute to asking customers for their opinion. Note that this must be a survey focused on the knowledge base, not the standard case survey.
- Links and citations. Reuse is a big deal for the knowledge base so you should measure how often documents are linked to cases, especially by someone else than the original author (citation). If balanced by a case quality survey this is a great metric. If used by itself, it may create a thicket of irrelevant links to useless documents. You have been warned.
- Time to publication. There’s nothing more disheartening to a support engineer than to see a lovingly-created document languish in the review cycle. Measure time to publication the same way you measure time to resolution for cases.
So there’s no simple answer to evaluation a knowledge management initiative, but by creating a combination of metrics that match your business goals you can create both an assessment of where you are and a map to improvements.
For more detailed thoughts about knowledge management metrics, see Collective Wisdom: Transforming Support with Knowledge.
FT Works in the News
Eric Eidson and I are collecting case studies and facilitating dialog amongst vendors who are using channel support. If you want to participate in the discussion, join our LinkedIn group for Channel Support.
Third Tuesday Forum
Are you based in the San Francisco area (or will you be there on Tuesday January 18th)? 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. The presenter is being confirmed – and it should be a great session. If you’d like to be kept informed, sign up for the mailing list. You will be the first to know about new events. You can also join the Third Tuesday Forum groups on LinkedIn and Facebook.
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