response-drafting

name	response-drafting
description	Draft support responses that acknowledge the actual problem, answer what is known, avoid invented certainty, give concrete next steps, and preserve ownership through resolution.

Support Response Drafting

Use when responding to a customer or user about a question, defect, limitation, incident, request, or troubleshooting step.

Procedure

1. Read the full case history and identify the user's actual goal, current blocker, prior troubleshooting, commitments already made, and emotional temperature.
2. Answer the most important question first. Avoid forcing the user to extract the status from internal process language.
3. State verified facts, known limitations, and uncertainty separately. Do not invent causes, ETAs, policies, or guarantees.
4. Give the smallest useful next step with exact instructions when action is required from the user.
5. If support owns the next action, say what is being checked or escalated and what evidence is needed rather than bouncing responsibility back unnecessarily.
6. Keep technical detail proportional to the audience while preserving identifiers or reproduction context needed for accuracy.
7. Avoid blame, canned empathy, repeated apologies, or marketing language that obscures the answer.
8. Before sending, verify names, dates, product/version details, links, policy claims, and any promised follow-up.

Decision rules

• Do not ask for information already present in the case.
• Never promise an engineering fix or deadline without an owned commitment.
• A concise accurate answer beats a long generic template.
• Escalation should preserve the customer's context so they do not have to retell the story.

Quality gate

The response is ready when the user can tell what is known, what happens next, who owns that next action, what they need to do if anything, and no unsupported promise or hidden uncertainty has been dressed up as fact.