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 June 2003 issue of the FT Word. Please forward it to colleagues you think may enjoy it.
In this month’s issue
· Process definition: a complete roadmap
· 21 Dog Years: a book review about an insider’s view to how Amazon.com handles service
· Summer reading program
It’s a good idea to document support processes, and not only when the ISO inspector or the support certification team is coming… If you want consistency, accuracy, and a quick rampup for new hires, you simply must document. And it doesn’t need to take six months and three full-time resources either. Here are 12 very easy steps to get it done this month (really!)
1. Don’t go overboard
If you have a small support center, you probably don’t need more than a handful of processes. Start with
Responding to electronic cases
Handling off-hours requests
Larger groups have more complex processes, and more of them, but a couple dozens should be plenty. More is not better. And you don’t have to document all the processes at once. Start with the most common ones above and add others as you find time.
2. Think reference and training tool
Who uses process documents? Individuals who don’t know how to do the work, right? Target the documents to new hires and to people who need to check up on something, not to experts.
Process documents shouldn’t be built like training materials, which would make them unhelpful as references, but they should be readily understandable to beginners. If you have the means to create a full-fledged training program, great! Otherwise, create a roadmap to the process document to be used by new hires to self-train, to or train with a buddy. Specify a good learning sequence, especially if you have lots of processes.
3. Be brief
Long, wordy documents don’t get read and can be misunderstood. Even for complex processes, stay within a page or two. Whenever appropriate, break down long, complex tasks into shorter processes that can be documented separately. For instance, the case creation process can be separate from the customer entitlement process, or at least from that part of the entitlement checks that is performed only on an exception basis.
Cross-reference related documents, which helps learners navigate to other, similar tasks. Also, cross-references make it easier to update related processes without forgetting one.
4. Use steps
One of the best ways to meet the needs for both training and reference is to describe processes in steps. For instance, a case creation process could read as follows.
Log into the case-tracking system
Enter the customer’s last name and click Find
If the record is in the database, click New Case
Note how different this approach is from most user’s guides: everything is organized in terms of tasks, not features of the tools. Task-based organization makes it easy to learn, easy to refer to.
5. Document tasks, not soft skills
Don’t try to codify soft skills, such as how to handle an irate customer. You can define what types of remedies a rep can offer a customer who is complaining, and you can suggest the wording for difficult situations, but don’t try to script everything: it will irritate the staff and the end results sound fake to customers anyway. Stick to facts.
6. Interview the experts
If the experts can’t or won’t write down how they perform tasks, the process documenter needs to interview them. I’ve found that the best way is to actually observe the experts while they perform the task and record what they do. You should not be shy about asking them to slow down: their fingers can fly on that keyboard!
Once the processes are written down and approved by the experts, go test them with the new hires. They are the ones who will find that crucial steps are missing.
7. Think hard about screen shots
Many of my clients have process documentation that’s beautifully illustrated with screen shots. It makes the processes easy to learn, right? Well, perhaps for the first couple of months, until the next tool upgrade changes the screen. My experience is that most process documents are out of date, hence the screens no longer match reality.
Unless you have a strong commitment to careful maintenance, skip the screens. The menu items change much less often so your documents will have more staying power.
8. Question authority
Think critically when you document processes. Do you have a 21-step process to check customer entitlement? Is the response time for urgent licensing issues a full 48 hours? Don’t just write it down: question it. Often it’s only when processes are documented that the absurdities pop up. Do you need six full pages to describe how to route new cases? This is a not-so-subtle sign that routing should be simplified, not documented as is.
9. Date the documents
Many people like to use version numbers, which is fine. Do not allow publishing process documents without either a date or a version number. Hint: put the date or version number in the body of the document, not the header or footer. It’s easy to forget updating headers and footers. Body text is harder to ignore.
10. Store the documents centrally
Don’t allow the staff to keep their own copies in email, folders, or hard copies, as it makes it impossible to maintain version control. An ideal place for process documents is the knowledge base. Create a separate “Process” category, which should be inaccessible to customers. Placing the process documents in the knowledge base allow you to take advantage of the document maintenance facilities of the knowledge base tool.
11. Designate an owner
Whether it’s an owner for all the processes, or an owner for each process or type of process, there must be an individual whose responsibility it is to keep it updated. It’s often difficult to foresee how a new tool or process may impact existing processes. The owner can quickly ascertain whether changes are required. The owner should also be the focal point for questions and suggestions by the users of the processes.
12. Define a process to change the processes
Add one more process to the set of processes: how is a new or updated process agreed to? How are impacted individuals told about it? Trained on it?
If you are storing process definition in the knowledge base, you may be able to leverage the existing document review facilities to get the necessary approvals. In any case, the business managers whose groups use the processes must be at the center of the implementation.
Ideally, you should review all processes yearly just to make sure that they are still correct, and that newer documents do not contradict or overlap older documents. Revise, discard, and consolidate as needed.
Note that many of the features we discussed earlier, in particular having a date and an owner on each process, make it much easier to handle updates.
Guilty Pleasure: “21 Dog Years”
Doctors watch ER, even as they bemoan the unrealistic story lines. We in Support read customer service stories… Here’s one.
21 Dog Years, by Mike Daisey, tells of his brief stint with Amazon.com, starting in the decidedly unglamorous Customer Service group. Daisey describes the selection process (“freaks” were thought of being the best fit for what was a frantic and surreal job), the training (cultish and strangely long at four full weeks), the working conditions (the dungeon, enough said), the meager office supplies and the unusual coworkers (Daisey accurately notes that service reps, interacting with customers only by phone or email, can look and act rather differently from their friendly voices).
My favorite part is on page 114 when he describes how silly metrics make for silly results. Faced with metrics that were based strictly on calls and emails handled, with the most important number being phone handle time, Daisey says he resorted to simply hanging up on customers. That did wonders for his numbers. I imagine customers were less pleased.
Beyond the obviously overdone characters and situations, Daisey manages to convey the true seduction of the internet years and the power of strong personalities in running “crazy” business schemes. It should bring back memories to anyone who was involved in e-business ventures in the ’99 timeframe. A fun, quick read.
FT Works in the News
SSPAnews published an article I wrote entitled Knowledge Base Maintenance: Can Outsourcing help? You can read it at http://www.thesspa.com/sspanews/060303/article1.asp
On June 25th, I will be 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/. It’s not too late to sign up!
The Association for Support Professionals asked me to be a judge for their upcoming “Ten Best Web Support Sites” contest. The entries were very interesting, so I’m looking forward to the final outcome.
SearchCRM has asked me to present a web cast on defining CRM requirements in late July. Watch for details and logistics in next month’s newsletter.
The Association for Support Professionals published an article I wrote about auditing CRM tools. You can read it at http://www.asponline.com/audit_tools.html
What are you going to read this summer? After you’re done with the latest Harry Potter, why don’t you learn something new about support? An FT Works book or booklet is an easy read and will inspire and guide you to change things for the better. Here’s the complete lineup so you can find something suitable whether you are worried about revenue, processes, people, or tools.
The 10 Commandments of Support Pricing
20+ Ways to Cut Support Costs
The Art of Software Support
Best Practices for Quality Monitoring
Best Practices in Self Service Support
Best Practices in Support Metrics
The Complete Guide to Hiring Great Support Reps
The Complete Guide to Hiring Great Support Managers
Just Enough CRM
Complete descriptions can be found 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.
650 559 9826