Support Response Writing

Support response writing

A support reply has one job: resolve the issue or clearly move it forward. Most bad replies fail by answering a different question, by hiding the answer under process language, or by using apology formulas that read as evasion.

Method

1. Answer in the first line. The resolution, the status, or the next step, before context or explanation. Customers scan for the answer and read the rest only if they need it.
2. Restate the problem in your own words. It proves you understood and catches misreadings before you spend effort on the wrong issue.
3. Say what you did, not what happens generally. Specific action taken on their account beats a description of how the system works.
4. Give the next step and who owns it. Whether they act or you do, and by when, since ambiguity here generates the follow-up.
5. Apologise once and specifically. For the actual impact, not ritually. Repeated apology reads as insincere and delays the answer.
6. Avoid the corporate deflections. Unfortunately our policy, as previously mentioned, and per our terms all escalate rather than resolve.
7. Match their register. A frustrated customer needs directness and brevity; a curious one can take detail. One tone for everyone serves neither (see audience-adaptation).

Boundaries

Good writing cannot fix a bad answer: if the product is broken or the policy unreasonable, a well-written refusal is still a refusal. Templates speed replies and go stale, needing review. Commitments made in support are commitments the company must keep (see support-escalation).