Support request: how to write it and what to avoid

A support request written well gets solved in ten minutes. One written badly costs three rounds of emails and a phone call. It also frays nerves on both sides. Here I explain how the process works and what to write so you get help straight away.

Why a clear support request gets solved sooner

I know, when nothing works the first reaction is to vent: “f%$$ing nothing works!”, “what kind of $%&$ service is this !!!1!”. It happens to everyone and I get it. The problem is that this sentence, on its own, tells me nothing.

What isn’t working? Email, the website, the management system, the connection? Since when? On which device? Without these answers I have to ask you, and every question is another round of waiting. The more details I get in the first message, the less time you spend without the service.

The process: what happens after you write

1. I receive the message and check that it comes from an address registered in my systems.
2. I read your description. Then I work out whether the problem is on my side, on yours or in between.
3. If something is missing, I ask for details. That is why it pays to write them down at once.
4. I step in and tell you what I found and what I did.
5. I ask you to confirm that everything works: only then is the request closed.

Where to send your support request

There are three channels, and each one has a precise rule.

• Email: this is the normal channel. Write from the address registered in the systems. Emails from external addresses are not accepted. It is not rudeness: it is the only way to know who is asking for what.
• WhatsApp: available only if the service has been requested and activated for your contract. It is fine for short urgent matters, but the same rules apply to the text as for email.
• Website form: use it when email is not working and you therefore cannot write to me. Here too the address must be valid and already registered: an unknown address is discarded.

If you are not sure your address is registered, tell me before you need it. You can find more examples of how I work in the CSDN plugin manual. Every step there is documented the same way.

Examples: from a vague sentence to a useful request

The rule is simple: write what you did, what you expected, what actually happened and the text of the error, if there is one. Here is how to rewrite a vague support request.

“Email isn’t working.” Better: “I can’t send emails from Thunderbird (or Outlook): it returns an error. I’ve attached a screenshot.”

“It won’t download my email.” Better: “When I download mail from the client it returns an error. I can still browse the internet, so the connection is up.”

“It says the password is wrong!” Better: “It keeps telling me the password is wrong and I don’t have it with me: would it be possible to do a reset?”

“The website is slow, $%&$!” Better: “Since last night the website takes twenty seconds to load instead of two. It happens on PC and on phone, with more than one browser.”

Do and don’t

Do this:

• Describe one problem per message.
• Say since when it happens and what changed beforehand.
• Quote the exact error text or attach a screenshot.
• Write which device, program or browser you are using.
• Tell me if something still works: it helps narrow down the cause.

Avoid this:

• Writing just “nothing works” or shouting in capitals.
• Opening the same request on three channels at once: it slows everyone down.
• Writing from an address other than the registered one.
• Sending your password in plain text: I will never ask you to.
• Changing things at random in the meantime without telling me.

To learn more about writing a good report, see this reference entry on bug reports. The principle is the same. A precise support request is the fastest way back to work. It usually saves you from repeating yourself three times.