Writing a great support email: content
Be content with your content
Technical support folks are great at digging to the root cause of a problem and driving it to a resolution, but that’s only half the job: it’s just as important to keep the customer in the loop throughout the lifetime of the support issue by efficiently communicating with the customer, both live and in writing. In this short series I’ll talk about how to consistently write clear, complete, and actionable customer emails.
There are three major things to keep in mind when communicating in writing, and all three are absolutely critical to writing effective support messages.
Does the writing convey the information I intend it to convey?
Is the writing both understandable and clear?
How do I come across when the recipient reads this message?
In this series I’ll cover them in order, starting with the content of the message. Though it may seem too obvious to state, the most important thing in writing a support email—or, frankly, any communication—is to be clear on what you’re trying to get across. In a support context this is usually one or more of the following:
Status updates (including handoffs)
Requests for information gathering or other customer actions
Replies to questions
Request for live troubleshooting
Summaries of live troubleshooting
An efficient support email will often cover several topics, commonly a combination of providing information (‘here’s an update on the status of the bug we discovered’) and making a request (‘in the meantime, can you try this workaround and let us know whether it unblocks your workflow?’). This prevents the situation of the engineer providing information to the customer that isn’t immediately useful—while it’s nice to know a bug fix is on the way, what can the customer do in the meantime to get things working again? “Sitting on their hands” is not a satisfying answer, so if there is a workaround, even an annoying or a partial one, it’s important to share that information as soon as you have it.
Only when you’re clear on the topics you intend to address is it time to actually start assembling the email.
Before writing the email, take a little time to clearly state what information, and which requests, need to be conveyed. Make a list of topics in the order you want to deliver them. Generally you should start with the most important information first since it will set the tone for the rest of the message.
Update on timing of bug fix
Suggested workaround
Request for further information on impact
For each of the pieces of information you want to convey, or request, break it down further to make sure all important components of that topic are clear.
Update on timing of bug fix
It has been prioritized by engineering
We expect a resolution by the end of next week
I’ll provide an update by the end of this week
Suggested workaround
Steps of workaround
Known limitations
Request for further information on impact
What is the effect of this issue on your workflow?
How many folks are affected? Is it just you, or are there others?
If others, can you provide additional information from their environments?
During this process, you should be asking yourself:
Do I have all the information I need to continue working on this issue?
Can I anticipate any reasonable follow-up questions and address them in advance, to help prevent back-and-forth?
Is the information I’m asking the customer to gather necessary for this investigation, and is there anything else I should be asking?
Only when you’re clear on the topics you intend to address is it time to actually start assembling the email, which coincidentally is what I’ll cover in the next post.
Thanks for reading Andy's Support Notes 💻💥📝!