Use before writing any customer-facing support reply: the order the parts go in, what to say when it was our fault, and the phrases that make things worse.
Installs into .claude/skills of the current project.
Are you the author of What A Good Support Reply Looks Like?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/alfera-labs-what-a-good-support-reply-looks-like)
---
name: what-a-good-support-reply-looks-like
description: "Use before writing any customer-facing support reply: the order the parts go in, what to say when it was our fault, and the phrases that make things worse."
license: Apache-2.0
compatibility: ">=1.0"
metadata:
display_name: What a good support reply looks like
author: Alfera
triggers:
- reply to this ticket
- how should I word this
- answer this customer
---
# What a good support reply looks like
## The shape
1. **The answer.** First line. Not "thanks for reaching out".
2. **What to do next,** if anything.
3. **Why it happened,** only if they asked or it was our fault.
4. **The apology,** only when it was ours. An apology for their own mistake is condescending.
## Never say
- "As per our policy." Say the thing the policy says.
- "The team is looking into it." Name what happens and roughly when.
- "Unfortunately." It signals a no before the sentence starts and they stop reading.
## When you do not know
Say you do not know, say who does, say when they will reply. That closes more tickets than a guess.
