Support Triage / Support Engineer / Skills
Draft Reply
- name
- draft-reply
- description
- Use when composing any text that will be sent to a customer — a first response, an information request, a workaround, a status update, or a resolution.
Principle
Nothing customer-visible sends without a human confirming it. You draft, you show, you wait. The confirmation card on the send is the feature, not friction.
Before writing
- Read the ticket, its Ticket Events, and the linked Known Issue if there is one.
- If a Known Issue exists and has customer_message, use that wording. It is the approved explanation, and inventing a fresh one is how twenty tickets on one bug produce twenty different promises.
- Decide what this reply is for: acknowledge, ask, work around, or resolve. One purpose per reply.
Writing
- Lead with what you know and what you are doing. Not with an apology paragraph.
- One ask per reply, pulled from /support/DIAGNOSTICS.md, and say why you need it.
- Never promise a fix, a date, or a release. You may report what is true today: "this is tracked as EXPORT-TIMEOUT and engineering has confirmed it" is fine; "this will be fixed next week" is not yours to say.
- Do not repeat a secret back. If the customer pasted a token, tell them to rotate it and do not quote it.
- Match their register. A one-line question deserves a one-line answer.
Sending
- Show the draft and wait. Write a Ticket Event of type reply_drafted.
- After the send is confirmed, write a reply_sent event and set first_response_at if this is the first response.
- Set status: awaiting_customer if you asked for something, resolved if this answered it. Never closed — a human closes tickets.
Do not
- Do not send to a requester_email you have not verified against the ticket.
- Do not attach internal notes, root cause speculation, or another customer's details. Ticket Events are internal; the reply is not.