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 September 2008 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription by clicking here.)

This month’s topics:

Strategic priorities for support – the first installment in a series of articles about strategic planning
Can we require support contacts to be certified? (Don’t say you’ve never thought of it!)

Support Strategic Priorities

For many of us back-to-school means getting ready for the budget process for next year. Joy!

We will delve in budget minutiae next month. For now, let’s concentrate on defining strategic priorities for the support group. Here’s a checklist to get you started. Very important: it’s in priority order so start at the top. Don’t bother fiddling with metrics (#8) if you don’t have a good handle on support revenue (#2).

1. What are the company’s priorities? Don’t be an island. If your company is targeting a new type of customers next year, you’d better be ready to support them. Ditto with a new product line, or a new geography. Job 1 is to keep your boss happy.

2. Is money coming in? If you charge for support you won’t get very far with any other initiatives if you can’t finance them. This means your top concern should be to protect and enhance your revenue stream. This is true whether or not you own support sales. For most of my customers the initial support sale is done with the product sale, outside the support organization, and renewals are done from the support organization. In this situation support needs to work with the sales team on ensuring a reasonable level of discipline around discounts and special terms, while tightening the renewals process.

3. Are you supporting broken products? The #1 predictor of customers’ satisfaction with support is product quality. That’s right: product quality is a better predictor than support quality. Are you supporting duds? You are if your defects to cases ratio is above 15%. For a mature product line (think version 4 and after) you want to shoot for 5% and below. If the defect ratio is high you would be well advised to work with the Engineering team on reducing it.

4. Is proactive a dirty word? You’re here to serve customers so it’s rude to suggest they help themselves, right? Wrong! Customers love to help themselves, especially if they can do it around the clock and find answers quickly. As important as it is to have a good way to help customers on a personal level, you will get a much better result with self-service.

5. Are your processes messy? I like to think of support organizations as giant machines where each turn of the crank produces a predictably, repeatedly good result. What’s behind the crank? Because we turn it so often it better be a nice, streamlined process. Pursue and eradicate too many handoffs, uncertain timeframes, black holes, unnecessary bottlenecks, and naturally inadequate metrics.

6. Is your organization messy? Typical inefficiencies include disconnected distributed organizations (there’s only one right way to organize support in my mind: with a global organization); too many chiefs; too many helpers and not enough direct delivery staff; high turnover; incompetent staff allowed to remain on the team.

7. Are your tools duct-taped to death? It’s rare these days to run into a support organization that is not equipped with at least a rudimentary case-tracking system, but I do see a lot of older, tired tools that could be easily replaced with newer technology. I also see a lot of poor implementations that need a serious refresh. Ask the support reps: they have to use the tools everyday and they know where the flash points are.

8. Are you flying blind? Superior support organizations have good metrics. By good metrics I mean correct, comprehensive, and few. I’m putting metrics near the end because you cannot expect to fix your metrics if you have terrible tools (since they either won’t track the right stuff, or people won’t use them so you won’t be capturing the data) but clearly there are many circumstances where you need to start with metrics: how else will you convince your Engineering friends to fix a few bugs (point #3)?

9. Are you too ambitious? If your list of initiatives for next year exceed five or seven large project it’s probably too big. Focus on a few key projects and there’s always next year…

For more information, check out the Managing Support Strategically booklet that introduces the Five Layers of Support Architecture^SM, the basis of the FT Works methodology from which the checklist above is constructed. If you’re ready for the next step, you can take a peek at the new Budget Magic booklet that will be introduced in next month’s strategic discussion.

Can we require support contacts to be certified?

Thanks to David Winston for suggesting this topic.

What proportion of incoming support cases are really about educating customers? I’m not talking about the customer asking about an obscure functionality, perhaps poorly documented or rarely used. I’m talking about customers who simply don’t know the basics about using your products. How can we cut down on the usually lengthy education cases?

1. You can require that contacts be certified if you have a certification program (or can rely on an industry standard) or you can simply require that the support contacts have a certain level of training. Some of my clients do it and their customers go along with it.

2. Write the requirements into the support contract so it is crystal-clear from the start. You may need to update the specific requirements from time to time as the curriculum or the certification program change, but the principle of the education requirement should be right in the support contract.

3. Allow some wiggle room. A general statement around a certain level of mastery is fine. For instance, you may want to word the contract to read that the support contacts should “master the materials in XYZ class.” This gives you wiggle room to accept a contact who did not attend the training but is clearly knowledgeable but require that a clueless contact actually take the class.

4. Allow a grace period. Think of a new customer: there’s no way that its contacts will instantly get trained or certified. Typically training requirements allow for a 90-day grace period to obtain the necessary qualifications.

5. Plan for contact changes. If a trained contact moves on, the replacement may need some time to get trained or certified.

6. Plan for new releases. A contact who is certified on version 2 may not be able to cope with version 8 (or even version 3.) At the same time it may be difficult to justify paying for a whole new round of training and certification for a new release. Do what you can to facilitate upgrading the contacts’ certifications.

7. Be firm but realistic. Even with a requirement written in the contract there will still be exceptions: the classes were full; the contact could not travel; there’s been a large reorg. Think of the requirement as a basis for negotiation, not an absolute rule.

8. Certification does not imply competence – and training certainly does not. Even individuals who duly completed the training requirements, or even passed the certification, may still have gaps in knowledge or weaknesses in their understanding. If you notice obvious gaps work to improve the training or the certification.

9. Don’t be too greedy. It would be wonderful if all contacts had the highest level of certification but requiring it may be a deal-breaker. Consider requiring a basic level of knowledge only, and recommend higher levels rather than requiring them.

10. Don’t be too quick to dismiss education cases. A customer with a question should be helped first, questioned later. The support engineer can certainly push back and ask the customer to read up on the topic before scheduling a discussion, but don’t just dismiss anything that feels like education.

11. Require certification for partners. If it makes sense to ask customers to be trained it’s even more important to request that partners, distributors, and resellers adhere to training guidelines. For that crowd the certification requirements are often baked into not only the contract but also the discounts that are afforded to the partners. So a “Platinum” partner with a certain level of sales and a certain number of certified employees will get a higher discount than others with lesser credentials.

12. You don’t need a full certification program to require certification. Many vendors use an informal certification program, especially with partners, through which they certify individuals after a successful implementation, for instance. Don’t think you must have a large, formal certification program to do any of this.

Bottom line: it makes sense to require a certain level of training for contacts but expect to exercise flexibility in applying the rules.

FT Works in the News

Customer Management Insight published an article I wrote entitled Outsourcing – A Reasoned Approach in their August issue. You can read it at http://cmisight.com/index.php?option=com_content&task=view&id=719&Itemid=38

Watch for the formal introduction of Budget Magic, the easy way to create support budgets, in next month’s issue of The FT Word. You can order it today here.

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

Back to Newsletter Archive