Writing messages for unexpected downtime
Total service stops are rare but happen to every system at some point – it’s just not possible to control every variable in the universe. What is possible though, is handling such situations in ways that leave a somewhat better impression by responding to the rapid change in information needs. That’s why we use failures not only to develop even better systems but also to improve our communication. The following guidelines and examples are intended to help relieve customer support and make customers as happy as they can be, considering the circumstances.
Guidelines
Write as much as you want
Then edit and rewrite. Good communication isn’t necessarily short, but concise. Don’t start off with too many limitations. But aim to end up with only the amount of words that is really needed. A status message is the most important thing when it appears, make it count.
The right information
Honest information is more about writing what the user would want to know, than including all the details you want. It might help to think of reasons the user might have to call support. If there are a lot of necessary details, a “read more” section can be useful.
Speak like a human being
Use simple words in plain sentences. Try using the kind of language customer support would use. You are not talking to colleagues. Don’t use abbreviations and jargon, it doesn’t make you sound more convincing or on top of the situation, only confusing.
Actions and effects
You are informing the users about how issues affect them and what they can do next. You are not writing an incident report or making a statement. Lead with action by putting the most important things first, like what the user can do to proceed. You can safely skip “please” and other pleasantries.
Causes and excuses
Causes are secondary, including it can provide context, but explanations should be reserved for a possible “read me” section. You don’t need to round off your messages with apologies either. No one calls support to get an apology. The users want updates and information, don’t waste their space and time further.
Time and updates
Users want to be kept in the loop. It provides a sense of progress during serious incidents, and the users don’t feel like they have been forgotten. Updates let you tell users about the problem at an earlier stage, you don’t need to know everything before you start informing. A timestamp makes the message more believable, and the users don’t have to guess when and what. It shows that you are working on something right now and that there will be more updates
A “read more” section can hold all events, while only a couple of the latest and most important ones are present on the relevant page.
Consider the context
Know where the message ends up. Know if there are other messages nearby. Know if the interface provides information that can be omitted from the text. And use words that match those of the interface. You don’t support anyone by repeating what’s already known or explaining what’s self-evident.
Linking
Put links on words that indicate what or where they lead to. “Read more” is absolutely OK, adding what it’s about, makes it even better.
Avoid putting a link on a text that says “this page”. “This page” refers only to the current page. Never say “click here”. The link styling already indicates that it’s a link and that it can be clicked. A link is not a button, use only regular link styling. The attention drawn by the message styling is sufficient, making any call to action style superfluous.
Errors are golden opportunities
But only if you let the users know when the issue is fixed. After keeping the users in the loop with crystal clear messages, don’t just vanish. Only removing the error message is as confusing as a traffic light with only a red light. You end up telling only bad news, missing opportunities to show how good you are at handling errors and fixing things.
Examples
Bad
Because of rainy weather, the equipment needs to be transported back inside. If not, the aforementioned equipment will get hit by the rain, get wet and might not work as intended.
Better
We need to get the equipment inside because it’s raining.
What to do and a reason. No need to explain what people can deduce or is self-evident – and becomes more so by the second – and certainly not in using a backwards sentence construction.
Bad
It’s that time of the year again! Christmas is here and that means the thing that usually takes 2-4 business days and the thing that take 3-5 business days might take 4-6 business days and 5-7 business days, depending on location and distance.
Better
Between 12th December and 4th January things take up to two extra business days.
The user needs to know what to do, but can probably understand that from the text. It’s probably not a surprise that Christmas happens in that time period. Mentioning a self-evident cause isn’t necessarily wrong, but try avoiding brand tone of voice or holiday greeting language. You’re not giving the gift of service delay.
Bad
The TUB and FoamCore are experiencing some hiccups. Please try again later.
Better
The action you are trying to do is not possible because of a stability issue in one of our supporting systems. We are working on it. Try again later.
Longer isn’t necessarily bad. Explaining using words the user knows is always better. And systems don’t experience anything, certainly not hiccups – be careful with personifying. Also, notice the removal of pleasantries.