The FT Word – February 2008
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
Welcome to the February 2008 edition of the FT Word. Please forward it to colleagues who would enjoy it.
Here are the topics for this month
- Goals and objectives for support engineers
- Transitioning customers to new support offerings
Goals and Objectives for Support Engineers
Thank you to Robert Bell for suggesting this topic.
For many of us it’s that wonderful time of the year when performance reviews are due… Yikes! Wouldn’t it be easier if you had defined effective goals and objectives for everyone on your team last year? Let’s start fresh this year. Here we see how to balance subjective and objective goals; how to assign weights to different types of goals, and how to keep the list reasonably short – and I also give some practical examples at the end.
1. Start with clear organizational goals.
You won’t get out of the starting blocks if you cannot spell very clearly the goals of the support organization. (These are typically the goals of the head of the organization.) All support organizations have three types of goals: customer satisfaction, increased revenues or decreased costs, and feedback to the rest of the organization. You can pick all three but surely one is more important that the others.
2. Define goals and objectives for each support staffer.
The worst thing we can do as managers is to fail to define individual goals, then write performance reviews against the non-existent goals. Even if you’re not sure what the perfect mix might be for your team, take a stab at writing goals. You can always improve them for the next review period.
3. Balance the various tasks and responsibilities.
For instance, if your support staffers are expected to contribute knowledge base articles there should be some mention of that in their goals. If they routinely teach customer classes that should be noted as well. Ensure that the weights match the duties. If support staffers spend 80% of their time working cases and 20% teaching about 80% of the objectives should focus on case management and customer satisfaction.
4. Balance volume with quality.
Support staffers’ goals tend to be heavy on volumes (of cases taken, cases closed, knowledge base articles written) volumes are easy to measure. The problem with that approach is that more cases does not a better support staffer make (and a requirement to close more cases make for unhealthy behaviors including cherry-picking and high escalation rates.) A good rule of thumb is to have a quality goal for each volume goal.
5. Quantify, quantify.
It’s always better to use quantifiable goals simply because there’s no discussion about whether they are met. Case volumes are easy to measure, but what about squishier things like quality? You can measure customer satisfaction with a case-based survey and use individual average ratings. Or if customer surveys are impractical you can have a monitoring program and use the ratings from the structured checklist as your quality measurement. Or you can ask senior staff to audit case notes after the fact and determine whether appropriate procedures were followed, including creating knowledge base documents. (And you can use more than one strategy.) Make sure you use reasonable sampling size: you can’t draw significant conclusions from 10 surveys so shoot for 30 or even 50 if you can.
6. Reward cooperation.
Most support staffers have goals that are strictly individual but most support managers wax lyrical about teamwork. What gives? Well – teamwork, of course. While I’m a great fan of individual measurements such as customer ratings for those cases closed by the particular support engineer, other areas such as response time lend themselves to group measurements. And even with an individual measurement like customer satisfaction you can add a group metric with a small weight to remind everyone to look out for each other’s customers.
7. More goals is not better.
When you’re driving your car, I bet you pay attention to your speed, most of the time, and occasionally your gas and temperature gauges (unless, like some people I know, you drive a Prius and are obsessed about the mileage number! If that’s the case try driving barefoot; it really helps. End of digression.) If there were dozens of dials and gauges, you would probably focus on just a few. Same with objectives: limit them to no more than 5, 7 at the most so they can be remembered – and so you can assign a non-negligible weight to them.
8. Focus on productive tasks.
I often see development goals in performance reviews, a la, “Attend xyz class.” I’m all in favor of training but training by itself is hardly an achievement. Better to spell out the ability to handle cases that include that particular topic, or passing a particular certification. Generally speaking, measure results rather than activities.
9. Deconstruct gaming.
Ask yourself: how could I cheat to hit the targets? A great deal of energy is expanded to figure out how to hit targets with a minimum of effort. For instance, the easiest way to hit volume targets on cases is to systematically log multiple cases for each customer. Make sure that such gaming opportunities have a clear counter-measurement. In the situation where multiple cases are logged, a simple random audit of cases should detect the problem.
10. Check fairness.
A support organization I worked with recently had the same case volume goal for all three shifts, but unavoidably the graveyard shift received many fewer new cases than other shifts and was typically unable to close cases opened during the day since the customers were unavailable at night. That’s not fair. It would be better to use different volume targets for the different shifts. In the same vein, senior support staffers who work with escalated calls may naturally hit lower numbers. If no one in a particular subgroup is hitting target you are either overstaffed (rare, but possible) or pushing the target unfairly across the groups.
Putting it all together, here are some examples to get inspired.
For an individual Frontline support staffer (note the teamwork goal under team customer satisfaction)
- 30% – case volume: at least X cases closed per month on average
- 25% – customer satisfaction ratings on cases closed by the individual (target 8/10)
- 5% – customer satisfaction ratings on cases closed by the team (target 8/10)
- 20% – case quality as measured by a random audit of cases by a Backline Engineer (target 8/10)
- 20% – knowledge base contributions: at least 4 per quarter passing technical review
For an individual Backline support staffer who advises a team of Frontline support (note the large weight of knowledge management work)
- 30% – case volume: at least X cases closed per month per person on average
- 30% – customer satisfaction ratings on cases closed by the team the individual advises (target 8/10)
- 20% – knowledge base contributions: at least 4 per quarter passing technical review
- 20% – knowledge base reviews: at least 80% of submissions reviewed within 1 business day
For the first-level manager of the team above
- 25% – maintain productivity of at least X cases closed per month per person
- 50% – customer satisfaction ratings on cases closed by the team (target 8/10)
- 25% – customer usage of the knowledge base: at least 1:50 ratio KB sessions vs. cases
For a support staffer who has significant projects outside the support organization
- 25% – case volume: at least X cases closed per month on average
- 20% – customer satisfaction ratings on cases closed by the individual (target 8/10)
- 5% – customer satisfaction ratings on cases closed by the team (target 8/10)
- 15% – case quality as measured by a random audit of cases by a Backline Engineer (target 8/10)
- 15% – knowledge base contributions: at least 4 per quarter passing technical review
- 20% – participation in outside projects (training, documentation, consulting)
Transitioning Customers to New Support Offerings
Thank you to Grace Taiana for suggesting this topic.
You are rolling out new support offerings and want to sunset some older ones that no longer fit in the portfolio for whatever reason. How can you proceed to gently, but firmly guide your customers towards the new offerings?
1. Check the fine print
Some proportion of your customers may have written contracts that promise a particular set of support commitments. Check the contracts. Contrary to popular perception it’s always possible to change contracts after the fact but you should know what you’re up against. Actually you should perform that exercise before you design your new offerings: planning the transition is part of creating new offerings.
2. Define migration paths
It’s very useful to have a standard set of migration paths even if you intend to let customers choose their paths, and even if you will have to make some exceptions to accommodate specific requests. The migration paths should show recommended mappings from the current offerings to the new offerings, ideally to equally good or better offerings (at least better overall, if not feature by feature.) For instance your mapping could be:
- Basic Support â Bronze Support
- Advanced Support â Silver Support
where the SLAs for Bronze and Silver are equivalent or better to the SLAs for Basic and Advanced. For instance, if Advanced had a 2-hour response target Silver could offer 1 hour for emergencies and 4 hours for other – not better across the board but presumably perceived to be equivalent and perhaps better. (And note that you could introduce a new offering, Gold Support, that’s above and beyond existing offerings and would be a possible migration for high-end Advanced Support customers.)
3. Analyze pricing scenarios
Customers are surprisingly amenable to moving to new support offerings but not if it hurts their wallets! After you define the migration paths get to work with a spreadsheet. Identify typical customers and calculate their support bills before and after the switchover. If the bills are similar (within 10%) your task will be easy.
If the new offerings require a significantly price increase for specific classes of customers, I would strongly recommend defining a reasonable step-up strategy in advance. For instance, keep the yearly price increase to no more than 15% until the customer is caught up with the new pricing. But even with that strategy you obviously have a vulnerable customer.
4. Phase the change over the renewal window
If most or all your customers are on one-year support contract, allowing a one-year overlap between the old and the new offering resolves lots of issues. Starting today all new contracts are written against the new offerings and all contracts up for renewals are also written against the new offerings; within a year you’re done (minus any customers on longer-term contracts.)
It’s a pain to keep track of two sets of contracts for a year but much easier than trying to renegotiate contracts across the board.
5. Renegotiate the contracts
For those customers who cannot be phased into the new offerings in a reasonable period of time, you’ll have to renegotiate the support contracts. Renegotiating is always a delicate exercise since it puts the customer in the mindset to reconsider the entire relationship, but it’s better than having to continue to support an outdated contract that is different from anyone else’s. Define in advance who will be in charge of contract negotiations: is it the individual who handles renewals, the sales rep, or someone else (perhaps a team you create to handle the transition)? As always, try to negotiate directly with the support contacts, who have a vested interest in the quality of the outcome. And don’t try to squeeze every last penny out of the customer: your interest is to bring all customers to the new programs without losing them.
FT Works in the News
SSPA News published an article I wrote called The Motivation Game that echoes this newsletter article about goals and objectives. You can read it at http://www.thesspa.com/sspanews/January08/article2.asp
Customer Management Insight published an article I co-wrote with Ravi Ravishankhar of Cisco called Creating a Unified Framework for Multiple Sites. that echoes this newsletter article about goals and objectives. You can read it at http://www.nxtbook.com/nxtbooks/cmp/cmi_200801/ (it’s on page 16.)
There’s still time to sign up for ASP’s Best Support Web Sites of 2008. A great, inexpensive way to get an expert evaluation of your site by several judges (including yours truly.) To learn more, visit http://www.asponline.com/whyenter.html
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.