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 May 2010 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
- Case trends and root cause analysis – how to get the entire support team to support the effort
- Tech support titles – why they matter and how best to transform a chore into a recruiting and retention tool.
- And, as always, an invitation to attend the Third Tuesday Forum, which will welcome Christophe Bodin of Oracle on May 18th to discuss support communities. Sign up now.
Case Trends and Root Cause Analysis – Winning the Team Over
Many thanks to Yaron Wilf for suggesting this topic.
Behind the busy façade of case resolution, we know that much of the work in support organization is to forecast, anticipate, and deflect customer demand. To do that we need metrics and analysis of historical trends. How can we convey to the Engineering that a particular bug needs fixing if we cannot grasp and communicate its impact on customers? How can we function as the Voice of the Customer and push functionality improvements if we cannot quantify the number of customers who are asking for them? And, closer to home, how can we properly staff the support team if we don’t track the distribution of cases over time?
But often the quality of the case records is poor. Garbage in, garbage out: the quality of the analysis suffers. How can we ensure that each support staffer takes the time to record enough information in the case-tracking system to create reliable and detailed records?
1. Educate the team on the power of root cause analysis. I facilitate support skills workshops on a regular basis and I always ask the question of why good case notes are important. I always hear about time management. I always hear about creating a good record for the customer. And I’m happy to say I always hear about creating fodder for the knowledge base! But I very rarely hear about metrics or root cause analysis. So we have a way to go in educating the entire team. Make sure the reps are aware of the benefits. Perhaps have them read this and this.
2. Deemphasize quantity measurements and insist on quality. If the support staffers are mostly measured on productivity it makes sense for them to race through bureaucracy. On the other hand, if they are held to quality standards that include categorizing cases properly, chances are they will pay more attention. I like to see about 25% of each support dedicated to internal quality (above and beyond customer satisfaction ratings). Internal quality can be measured through audits of a small percentage of cases: are the notes complete? Were proper tools and techniques used? Was the case properly linked to knowledge base documents and properly categorized?
3. Make it easy to categorize cases. The basic building block for root cause analysis is case categorization, typically done upon closing the case. Keep it simple! I once worked with a customer who maintained 50 (50!) category choices. And another who had 4 levels of dropdowns. Sure, that would get the support staffers to a minute level of details but who has time to wade through all these choices? (And indeed, in both cases the staffers often picked the first item on the list rather than reading through.) Keep the categories simple: no more than 2 levels, no more than 10 choices at each level (7 is better). Test the categories: if the categories are not clear, picking the first item is a reasonable strategy.
4. Make it easy to link cases. Links to knowledge base documents, bugs, and enhancement requests are another great way to gather root cause analysis information. It should be easy to do for the person working the case.
5. Supplement the categories with some targeted sleuthing. If you limit yourself to a handful to categories you will need to dig a little deeper for fine-grain root cause analysis. An effective technique is to simply review a sample of cases in the categories of interest. It’s work, but at least the (correct) categories will give you something to shoot for.
6. Advertise successes. If Engineering is fixing bugs that were identified thanks to the efforts of the support team let everyone know about it. The lowly job of keeping accurate records is not exactly fun so show how it adds up to building a grander whole.
For more ideas about support metrics, see Best Practices for Support Metrics.
Technical Support Titles
Many thanks to James La Rheir for suggesting this topic.
Job titles may seem to be mere bureaucratic hassles but they can figure prominently decisions to join a team or pursue a promotion – so they have a direct impact on your ability to hire and retain good staff, therefore it’s smart to get involved in the selection of job titles, along with the helpful HR team. Here is how.
1. Assign different titles to different functions
Generally speaking, if you have staff members doing different tasks they should have different titles. I find that a good way to start thinking about job titles is to start with the processes you use. Take the case resolution process. If you have staff dedicated to answering the phone and logging cases and staff dedicated to resolving technical issues, you should have a job category for answering the phone and another one for resolving customer issues. If you have staff dedicated to creating knowledge base documents and a different group handling customer issues you need a knowledge management category and an issue resolution category. (I don’t think separating knowledge management and issue resolution is a particularly great idea, but if you do it then you need separate job titles.)
2. Pick a title style
There are many different kinds of job titles used in support organizations for what is essentially the same job, resolving customer issues. Here are some sample titles I find when working with technology vendors:
- Technical support engineer
- Support engineer
- Product support specialist
- Support technician
- Support analyst
- Support consultant
- Support representative
- Service representative
- Customer care specialist
- Customer support specialist
- Security specialist
Which one is right for you? It depends on the level of technical skills required (organizations that support highly-complex people go for “engineer” more often than for “rep”, for obvious reasons), tradition in your industry, and the not-so-subtle pecking order with the rest of the company. My first job was as a “training engineer” rather than “technical instructor” or “trainer” simply because, in the engineering-driven company where I worked, it would have been unthinkable not to bestow anything less than an engineer’s title to a professional worker.
Make a carefully thought-out decision here. In particular, think about the implications for recruiting, both from outside the company and from within. Use the keywords that resonate within your industry. There is often considerable leeway in selecting a particular label so you should be able to shape the final decision.
3. Ladder up
Since not all support engineers (or support technicians, or whatever title you choose) are created equal, the next step is to create a ladder. The idea is that you can employ people to do the same job that have a range of technical and customer skills, and their specific title can reflect that.
The simplest approach is to use numbers. So a “support engineer 1” is more junior than a “support engineer 2”, and on up. Simple, yes, but not necessarily a great move because the numbers sound, well, skimpy. If you are not bound to use numbers by HR tradition (and you can certainly challenge the tradition!), it is better to use names, for instance:
- Associate support engineer
- Support engineer
- Senior support engineer
- Principal support engineer
Can you hear how much nicer it is to be promoted to “senior support engineer” than “support engineer 3”?
When you create your ladder do consider what other departments are doing. If the Professional Services group has three levels of “senior consultants” perhaps you should model after it – or perhaps not, but make a reasoned decision about it.
Remember that for each step of the ladder you need to maintain an underlying job description, and you need to be able to define what it takes to move up, ideally in one sentence. For instance, the difference between a support engineer and a senior support engineer may be the ability to handle customer escalations single-handedly. The difference between an associate support engineer and a support engineer could be a technical certification. If you cannot define clearly and succinctly the difference between two adjacent levels you should not maintain those two levels.
The description here is for support engineers but if you had other job families you would also create ladders for them. For instance you may have technical account managers and senior technical account managers.
4. Don’t go crazy with too many titles
In your enthusiasm to create job titles it’s easy to go overboard. Don’t. For one thing, you don’t want to maintain a monstrously long list of job descriptions. When it comes to job ladders, it’s ok to maintain a job description for associate support engineer if you don’t have one on staff at the moment (but you could, and you did, or you will) and it’s ok to maintain a job description for principal support engineer even though it may take another year for the most senior engineers to get there, but don’t create eight levels and use just two.
More importantly, don’t create separate job description and titles for each technical specialty. John may be working on product X and Jane on product Y, so they have different technical skill sets, but they can both be known as “senior support engineers” and use the same job description if the job description is written as a sufficiently high level.
Don’t confuse role and job title. If Raju is working exclusively with P1, system-down cases and Anjali is working the non-emergency cases it’s very doubtful that you need different titles for the two of them. And while you would need a different job title, support planner perhaps, for Carlos, who is 100% focused on coordinating new product rollouts, you probably don’t need one for Anjali if she gets involved in rollouts on a part-time manner – although that may warrant her being promoted to a senior support engineer, whose responsibilities include projects above and beyond working cases.
Don’t confuse role and job title (again!) If you have a tiered-support organization, should you have “tier 1 agent” titles and “tier 2 agent” titles? Perhaps. But you may want to stick with a ladder, with tier 1 agents at the low end and tier 2 agents at the high end. And if you use a Touch and Hold model with Frontline and Backline you can most definitely use a ladder rather than create different job descriptions for Frontline and Backline engineers. Note that in both cases the tier2 agents and the backline engineers would probably refer to themselves as such rather than “senior support engineers”, and that’s ok.
Generally speaking you don’t want to have anywhere near as many titles as you have people. Even very large support organizations do well with a dozen or two titles, with over 70% of the staff being in the “support engineer” ladder or equivalent.
5. Don’t confuse titles and compensation
Titles and job descriptions refer to underlying skills and responsibilities. Naturally compensation levels derive from responsibilities but in general the salary ranges that are associated with each job descriptions are wide enough to permit much leeway . Moreover, with a job ladder there’s typically significant overlap between levels so that it’s entirely possible to have a senior support engineer paid a little less than a support engineer – and it will happen with a long-tenured support engineer vs. a freshly-promoted senior support engineer. If you find yourself adding a level of the ladder strictly for compensation reasons, there’s something wrong. Ditto if you are tempted to promote someone to a higher level just to give a raise.
6. Promote at the right time
It’s sometimes difficult to tell the perfect time to promote someone to a higher grade. In larger organizations, “in-ladder” promotions are often restricted to once a year, at focal review time, further compounding the problem. Should rising stars be promoted slightly ahead of time, when they need a little more maturity to match others’ at the level? If you wait, you may have a frustrating situation when they must wait for several months for another chance.
If you have no restrictions on when to promote people, promote when they reach the level of the new job description. This does not mean that the newly-promoted staff member is at the same level of knowledge, maturity, and contribution as all the other staff members at that particular level, only that he or she meets the requirements of the job description. Newly-promoted staff members usually have a lower compensation that others at the same level, too. It’s normal and over time the compensation levels will match.
If you are restricted as to when to promote people, a good rule of thumb is to accelerate promotions for staff members who are close to the next level of performance and will get there within the next three months or so, given appropriate guidance. Always go back to the job description: if the requirements are met, or will be met in short order, I would consider granting the promotion.
What are job titles for? To provide guidelines and consistency in hiring and promoting, to help other functional groups understand individual responsibilities, and to drive compensation. If you want to add building morale to the list you should get involved in choosing them.
For tips on hiring a great team, see The Complete Guide to Hiring Great Support Staffers at l.
FT Works in the News
TSIA published an article I wrote entitled Selling Support to High-End Customers in their April issue. For more selling tips, you can read my new support marketing book, Selling Value: Designing, Marketing and Selling Support Packages. You can order it here.
Third Tuesday Forum
Are you based in the San Francisco area (or will you be there on Tuesday May 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. Our presenter will be Christophe Bodin from Oracle Support, who will speak about how Oracle is changing its focus toward an integrated approach that includes communities as well as standard assisted support. 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 June.
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.