How to answer a support request

Lift the outcome to the surface

Think: what does this person most want to hear from me? Normally this is, “we have fixed your problem”. So put that part first.

In the same way a good support request starts with the problem statement or question unburdened by four paragraphs of free-form beat poetry as preamble, a good response should start with the outcome.

It can be tempting to explain the great lengths you undertook to fix an issue, particularly if it took weeks to resolve and you are now feeling very proud of yourself or your team:

Hi Bob

Thank you for your patience with this.

We conducted a thorough investigation, liaised with our development team, and identified an issue with sprocket 14 in the flanging manifold, which had a broken tooth due to malnutrition. Hellcat 27 was deployed to fix this and made a successful repair.

As a result, your ears will no longer explode spontaneously when logging in to your account.

Better is this:

Hi Bob

Your ears will no longer explode when you log in now.

The cause was a hardware defect. We replaced a part and have adjusted our maintenance schedule to prevent this from occurring again. I’m happy to share technical details if you’d like to know more.

I’m so sorry for the distress this caused. We’re providing you with a lifetime of free cake to thank you for your patience while we investigated. Please let me know if I can help further.

Your response to the trickiest problem should be along the lines of, “we have taken care of that for you” without the prepended or appended, “sheesh, this one was really hard to fix — it’s a good job we’re so smart!”

Avoid boilerplate

Many battle-worn support aardvarks use snippet applications such as TextExpander. If you must use them — perhaps because your employer is a victim of Goodhart’s law (“when a metric becomes a target, it becomes a bad metric”) — it’s worth personalising your snippets and dropping any that smell too snippety.

Customers can smell boilerplate in the skeleton of your reply before they’ve even read it; snippets look impersonal if you mostly email people who type all their words by hand. People hate the feeling that you’ve picked your response from a list. Try cutting down.

And, yes, support work can be repetitive and snippets may be a blessing. But if everyone on your team is parroting similar responses to similar questions, it is a sign that your product, documentation, contextual help, or pre-sales and pre-support info could be tweaked.

Avoid boilerplate-ese

Boilerplate-ese is text you wrote by hand that looks like it was auto-generated or copied from a crib sheet or snippet. Text like:

Thanks for your feature request! I recorded your vote in the voting shredder. Thank you for purchasing a Funkotronic 5000. Have a great day!

There is nothing here that acknowledges your customer’s unique request, so it feels canned even if you hand-typed every letter. Better would be:

Thank you for this suggestion. We do not currently have plans to add exploding bees to the Funkotronic, as it would present safety issues for people and for the bees.

If you have other ideas for us in the future, though, please feel free to share them.

Drop “sorry not sorry” phrases

“We apologise for the inconvenience” is not empathetic. It reads like a government-issued notice, devoid of any compassion at all:

To whom it may concern:

Your son is considered defective and has been recalled. We apologise for any inconvenience caused.

The Ministry of Recycling

I like to use other phrases that appear to mean the same thing:

  • I’m sorry for the extra work this caused you…
  • I’m sorry for the time you’ve lost on this…
  • I’m sorry for our mistake here…

These turn the impersonal ‘we’ into ‘I’, accept the blame, or they recognise that the person lost more than the “convenience” of having the product or service they pay for work correctly.

Skip the blame words

“You” and “your” are the most common blame words:

“Your site is broken because of a change you made on line 1234.”

…would be better expressed as:

“The site is broken because of a change on line 1234.”

This is passive on purpose: it absolves your customer of blame and avoids a fight. And, besides, it’s presumptious to say they introduced a change that broke their thing. Keyboards hold an amazing magnetism for cats, kids, and other tiny meddlers.

Also watch for “should not”, “must not” and variants:

“You should never do it that way.”

Better is:

“We recommend doing it this way…”

The job of a support team is to make people feel happy, not guilty.

Easy on the exclamation marks

How do you express that you’re a cheery support person who’s genuinely happy to solve people’s problems? Email makes this tough. It can be tempting to drop exclamation points like hot potatoes to show that you’re happy and responsive.

Try mirroring the mood of your customer without ever dropping your own tone below “nice”. Does your customer use smilies? Mirror that in your response. Do they use emphatic sign-offs (“thanks so much!!!”)? Then perhaps it’s okay to throw in a single exclamation point in your sign-off too, just this once.

Swap out mood-altering words

Words like “problem” can feel large and frightening, particularly when people don’t realise they have one yet. Softer words that mean the same — like “issue” — are less likely to inflame. Instead of a confrontational:

“You need to fix your credit card problem.”


“There was an issue with the card.”

But better still to avoid both when you can:

“Please could you check your card details for us?”

This may feel like pointless semantics or thesaurus tennis, but it is interesting to see the difference small word switches make, especially in those who are naturally defensive of any perceived critique.

There is a danger here that you’ll start to refer to bigger incidents as “our little glitch” or “today’s whoopsie”. Don’t do that. The point is not to polish your turds, and you should be up-front about major issues using plain language — language like “network-wide downtime” and “the fire ant invasion in data centre three”. (And go ahead and blog pictures of the fire ants.) But for day-to-day support communication it’s fine to soften your language to appear calmer and more neutral.

Use gender-neutral pronouns

When writing documentation or reports, favour “they” over “he” or “she”. This has three purposes:

  • It demonstrates respect and care.
  • It shows that you acknowledge diversity.
  • It saves you from having to play amateur sociologist and guess the sex of your customer by first name.

Make their day

All of this distills down to one question that’s worth keeping in mind:

“Does my response make this person’s day better?”