This past week I've had some problems with the RSS feed that publishes my articles to readers such as MyYahoo! or Bloglines. While trying to get things back in working order I would ping my site. The ping basically sends a signal from the system that publishes my RSS feed to my site to get the latest data. While doing this I suddenly got an error message:
Your Ping resulted in an Error "Exceeded Access Limits - Try again Later"
Access limits? What access limits? Have I broken something?
I did a search on this error message and found a posting in the support forum where someone else was also wondering what all of this meant. Fortunately, the Director of Network Operations explained:
". . . all it means is that you submitted the ping multiple times (too many in too short of a time) and your request was throttled. It will let you send another ping in about 30 minutes."
That is a very simple and understandable explanation but it begs an obvious question. Why didn't they just say that in the first place?
Unfortunately, IT is infamous for this kind of thing. I'm sure that we've all seen cryptic error messages or instructions and have had difficulty figuring out what they mean and what we should do about it. Just about any software program in use today seems to have them which is very frustrating for users and leaves people angry with IT. Sad to say but the error message above is not nearly as bad as many of the ones we encounter.
The good news is that with a little effort we can improve things significantly. Some tips:
- Avoid all technical jargon and acronyms - remember your users are probably not as technically knowledgeable as you.
- Don't get overly formal. Write it like you would explain it to someone. Just as the explanation above is clearer than the error message, write it in plain simple terms.
- Have someone who is not familiar with the program (and preferably not another "techie")read the error message and then tell you what it means. If they didn't understand it correctly it is a good sign that you need to re-write it.
- If you can, have someone not closely associated with the system write the error message. This can help avoid assuming something is obvious to the reader just because it is obvious to you as a result of your familiarity with the system.
- Make sure that the message contains 3 elements:
- What the problem is.
- What the user should do.
- Where they can get more help or information.
- Treat the writing of error messages as an integral part of the process, not just something to follow-up on later as time permits. As we all know, "later" has a bad habit of never happening.
An excellent article containing more tips on writing error messages is How to Write Error Messages over at klariti.com. The article gives some great examples of a both well written error messages and poorly written ones that will leave you pulling your hair out in frustration.
What tips do you have?
If this topic was of interest, you might also like these:
Recently, my IT department sent an all-staff e-mail explaining that we would now have to follow a new procedure. The e-mail came across all about their needs, not how this new procedure would benefit the organization (and it will).
There are people you've done favors for in the Marcom department. Ask them to return the favor by helping you draft an e-mail that emphasizes the features and benefits to individuals across the organization as well as the organization itself. Emphasizing features and benefits will improve compliance.
Regards,
Glenn
Posted by: Glenn (Customer Service Experience) Ross | February 03, 2007 at 05:32 PM
Mike, came over from Successful-Blog. Great post!
Sometimes we get so steeped in the jargon of our specialty we forget that other folks may have no idea what we are talking about. I get left behind when my former vet tech wife gets around veterinary people and starts talking animals. And her eyes glaze over if I run into someone who was in the Navy and we start talking ships and planes...
Posted by: Chris Cree | February 03, 2007 at 06:07 PM
Glenn,
You've raised an excellent point. In all types of communications we need to address the customer's WIIFM (What's In It For Me) issues rather than our own. For error messages this means explaining what the problem is and how they fix it and/or get assistance. For other communications such as your example addressing the WIIFM issue will make it much more likely that the will follow new policies. Thanks for bringing this up.
By the way, I took a look at your blog. I'm a firm believer in customer service and believe that there is a lot more that IT needs to do in that area. I'm sure I'll be reviewing your blog for tips.
Posted by: Mike | February 03, 2007 at 06:22 PM
Chris,
Thanks for commenting. I know what you mean about the over use of arcane acronyms. One of the things I like to do in these situations is stop the person and ask them what the acronym stands for. You'd be surprised how often they can not come of with the phrase that generated the acronym. It just shows how speaking in "code" has replaced normal conversation in many cases.
I've enjoyed your posts on successful-blog.com. Keep it up.
Posted by: Mike | February 03, 2007 at 06:47 PM
Acronyms! I had too much of that in the military!
Posted by: Chris Cree | February 03, 2007 at 10:54 PM