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 April 2003 issue of the FT Word. In this month’s issue
· Managing escalations
· Running successful beta programs
· Just Enough CRM is speaking in tongues!
Escalations are the bane of a support manager’s existence, right? I don’t agree – and if your goal is to be completely escalation-free, you probably want to find another line of work. All support operations, however well managed, need to be able to handle customer escalations gracefully and effectively, especially if you happen to support complex products. Here’s how to do it.
1. Keep them to a minimum
You cannot successfully manage escalations if they are raining down on you. Make sure that good processes are in place to handle “normal” cases. If you have to set up an escalation process in a very troubled support group, drive improvements to the basic process together with the implementation of the escalation process, otherwise you will drown in the long run.
2. Identify troubled accounts quickly
It’s not rare that escalations arise from cases that support staffers knew were going badly, but kept to themselves, or from situations that were well known by sales reps but went unreported. Go look for trouble: make it easy and painless for all staff members to report escalations, and tell customers how to request escalations too. It will not increase your escalation load (if you do step 3, below, properly) and it will avoid the exasperate feelings that accompany out-of-control escalations.
3. Validate escalations
A customer who complains because the support rep failed to call at the appointed time may not warrant the full-blown escalation process. Take care of all requests, but reserve the formal process to situations that really warrant it.
4. Define clean communication lines
Half of the battle is to get the right people talking together. For formal escalations, get the support staffer to talk to the customer contact (as would be the case for any other issue) and appoint an escalation manager to talk to the business contact at the customer site. Rigidly enforce communications through those two channels. It will save you time and frayed tempers.
5. Create a formal action plan
The formal plan is the other half of the battle (the third half being executing against the plan.) It’s well worth it to have a written plan, formally shared with the customers as progress and changes are made.
6. Communicate often
A real escalation requires daily contact with the customer. If the customer won’t make himself available daily, take him off the escalation list. At the same time, communicate status to the internal stakeholders. Access to fresh status will help you stick with clear communication lines (step #4) while minimizing ad-hoc status requests to the escalation manager.
7. Do a post-mortem
Once it’s all over, get all parties together for an honest, open discussion of what went wrong and what should be done differently next time. After all, your goal is to minimize escalations (step #1).
Note that you can implement the strategy regardless of whether you have a dedicated escalation manager, which only makes sense if you have enough action to occupy someone full-time.
Running Successful Beta Programs
Many support organizations are responsible for running beta programs, and many more participate in the programs, so I thought it would be useful to talk about what makes a beta program successful.
1. Define what you want to accomplish
If you want customers to just “play around” with the system, fine. But chances are you want customers to perform specific tests, or to exercise particular pieces of the product. Create a checklist before you get started.
2. Be picky
It’s fine to bring customers into the beta program just as a favor to them, but don’t expect to get much out of those. For serious feedback, vet the candidates against your checklist, and be clear about the amount of time and resources you expect from them. Many organizations create a formal commitment document. That won’t ensure that the participants actually deliver, but it’s not a bad start.
3. Allow enough time
I’ve seen 3-week beta programs, and by the time the products were installed and the first preliminary tests were done it was already too late to change anything in the final product. If you have to work with very tight deadlines, don’t expect to make any feature changes.
4. Define a support route
You can either:
Use the beta as a way to train the support staffers on the product. It’s usually done by funneling beta support questions to a small, specially trained subgroup.
Have Engineering provide beta support.
I prefer using betas as training vehicles, despite the resource hit. I find betas to be invaluable in planning for resource allocation, above and beyond the insight it gives into the technical issues. Beta support can be limited to business hours only, with no P1s, so the burden is not as bad as it may appear.
5. Be proactive
It’s not enough to wait for questions to come in: you need to encourage customers to run through appropriate testing and to solicit feedback on the product beyond mere bugs. This is usually done through regular conference calls with the participants. The calls allow you to gauge the level of dedication of each participant and to perhaps drop participants that are not pulling their weight.
One last thought: Product Marketing, Engineering, and Support must work closely together to make beta programs work. If you are in charge, be sure to include the other organizations.
Just Enough CRM – Speaking in Tongues
Just Enough CRM, a guide for business managers in Sales, Marketing, and Support functions to select and implement CRM systems, will be translated into Chinese and Italian. Exciting!
You can find the English version in your favorite bookstore or here.
FT Works in the News
The SSPA conference in San Diego last week was a great venue to reconnect with colleagues and hear about fresh ideas. If you’d like a copy of the presentation I gave, Web Support Strategy and Implementation, please drop me an email at mailto:FT@ftworks.com?subject=Web Support presentation request
SSPAnews published an article I wrote entitled Coaching for Quality: A Lost Art?, that outlines a strategy for coaching as part of a quality monitoring program. You can read it at http://www.thesspa.com/sspanews/040803/article1.asp
On June 25th, I will be once again teaching about selecting and implementing CRM tools at San Jose State University as part of their Enterprise Management Boot Camp. Find a description of the program at http://www.ecmtraining.com/sjsu/bootcamp/
Read more about:
quality monitoring in the Best Practices for Quality Monitoring booklet
escalation management in the Managing Escalations booklet
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.