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 February 2002 edition of the FT Works Newsletter, a monthly review of trends in the support management arena. In this month’s issue:
· Creating good support data sheets (finally!)
· Industry turnover rates
· A sneak preview offer for the “Support for non-Support executives” white paper
· A new FT Works booklet, “Best Practices in Self-Service Support” at a special price for newsletters subscribers
Creating Good Support Data Sheets
Much like a product data sheet, a support data sheet describes the features of a particular support service. If you’re selling support, a proper data sheet is essential to
Make the service be more tangible, hence help to sell it
Assist sales reps, who often have minimal knowledge of the support world, in selling support
Reduce the likelihood of “specials”, where custom terms and conditions are created in an ad-hoc manner to make the sale
Clearly define what is included in the service to minimize misunderstandings down the line
If you do not you sell support, including if you run an internal help desk, an up-to-date data sheet is essential to accomplishing the last objective: defining a clear SLA (service-level agreement) with your customers.
Data sheets should be short (a one-page format is ideal) and include the following points
1) A friendly, customer-oriented overview that describes the service. Limit yourself to a few lines, staying away from endless combinations of such empty phrases as “world-class support”, “delivering the highest levels of customer satisfaction”, “tailor-made for your needs”, etc. They are everywhere and no one believes them.
2) Supported products and releases. Clearly define what’s covered and not covered by the service. If you provide support on older releases but bug fixes only for the latest release, say so.
3) Maintenance services. Are patches included? Maintenance (dot) releases? New releases? In high-complexity environments, support typically includes all new releases whereas new (non-maintenance) releases are purchased separately for low-complexity products. Give maintenance features the place of honor they deserve on the data sheet.
4) Hours covered. This is a global world, so make sure the hours are meaningful to all customers. It’s fine to offer and to advertise different hours by geography, say 6am to 6pm Pacific Time for the Americas and 9am to 5pm CET for Europe. If each country has custom hours, you have larger problems: go back and harmonize your hours.
Most around-the-cock contracts limit off-hour support to emergencies only (see point #6 below). That’s fine and should be clearly stated in the data sheet.
5) Technical contacts. Most contracts limit the number of individuals allowed to receive personalized support, with more contacts allowed with higher levels of support. It’s a good idea to require the contacts to be “appropriately trained”, although it’s impossible to enforce that.
6) Priorities and response times. This is the heart of the SLA so make them crystal-clear. The best way is to state priority definitions (say: P1 means that the software is completely inoperable; or P1 means a significant business impact) and let customers set their own priorities when logging cases. Arguing about priorities makes customers mad and takes time away from the resolution of the issue, and “customer-defined priorities” has a nice ring to it, don’t you agree?
Typical response times range from 30 minutes or an hour for P1 to a business day or more for P3s depending on the level of support and customer requirements.
There should be no resolution time commitment: it’s simply not possible to guarantee resolution of issues within a given time frame
7) Channels of communication. Include your phone number and web site URL. If you have a US toll-free number, also publish the toll number since toll-free numbers are not accessible from overseas. Skip advertising the email channel even if it exists and even if email is used liberally during the resolution process, as web access is much better. Some centers require that P1 issues be phoned in (presumably because they don’t feel they can rely on their electronic logging system).
8) Escalation process. Instead of committing to resolution targets (as discussed in point #6), you may want to offer an escalation process that commits to progressively higher-level individuals working on problems as they age. This is not mandatory but definitely a good idea at least for high-priority issues in enterprise environments. Two or three levels of escalations with time-based targets should suffice.
9) Proactive communications. Higher-level packages typically include some proactive communications, ranging from short phone call updates to onsite visits that can last several days. State the target frequency and scope for proactive contacts.
10) Any other special conditions such as limitations on the number of incidents logged, or the length of time free support is available.
If you offer several levels of support, make sure that the data sheets clearly show the differences (it’s hard to get that extra 5% if there is not visible difference between packages!) Speaking about prices, data sheets don’t always include pricing, especially in the high-end where custom quotes — and discounts — abound. I see nothing wrong with including list prices in all environments.
Data sheets are traditionally available in hard copies, however they must be accessible in electronic format from the web site (the famous support portals we discussed last month). Among other benefits, electronic data sheets can be easily updated.
Industry Turnover Rates
How are other support centers doing with turnover? It’s one of the most popular questions I get.
The usual turnover formula is # departing staff/# staff (so if you lost 5 people and you have 50 your turnover rate is 10%).
What’s a good rate?
When it comes to turnover, lower is better (although some people exclude fired-for-cause staff from the formula above to reflect the fact that some departures may be positive). The average for support centers is 30%, although the figures are much higher for low-complexity (and poorly-paid) support and lower for high-complexity support.
As experienced in Silicon Valley in the past months, turnover is very much influenced by the economic conditions in the immediate area. However, even in the hiring frenzy that we saw here in the past years, some centers did not lose many people. What did those centers do differently? They practiced good people management techniques: they recognized individuals, they kept open communication channels, and they were fair in their promotion practices (and no, they did hold more hokey parties or give out more cheap T-shirts).
What’s your turnover rate?
Support for Non-Support Executives
Could you use a tool to educate your boss or other executives in the organization who don’t have support experience? I’ve got just the thing for you: a new, 4-page digest that introduces non-support executives to the realities of support, from why we need good tools to why good support centers still get escalated cases.
If you’re interested, please let me know and I will send you an electronic copy. The paper is in testing mode right now so all I’m asking for is candid feedback on the executives’ reactions to it. Thank you!
A New FT Works Booklet at a Special Price
Best Practices for Self-Service Support is now available at a special introductory price of $25 for all newsletter subscribers. The special price is valid until 3/31/02 only, so don’t delay. To order, visit this page. The special price is available to subscribers only
FT Works in the News
SupportWeek published an article I wrote entitled Cutting Support Costs: Not always Painful?, showing how big, permanent cost savings can be achieved by rethinking support models, and without impacting customer satisfaction. You can read it at. You can read it at http://supportgate.com/supportweek/20020212/article1.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.
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.
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.