Draft replies from a support brief

A practical brief contains seven fields:

1. Customer goal: the outcome the customer is asking for.
2. Verified case facts: account, order, product, dates, actions, and status from trusted systems.
3. Approved knowledge: policy or troubleshooting steps that apply.
4. Unknowns and conflicts: missing identity, stale status, contradictory records, or unavailable evidence.
5. Permitted action: what the current agent or workflow may offer.
6. Escalation conditions: signals that require another owner.
7. Reply requirements: channel, language, structure, accessibility, and timing.

Keep customer statements separate from verified facts. “The app charged me twice” is a reported observation until records confirm duplicate settled charges. A good acknowledgment can take the report seriously without converting it into a conclusion: “I understand you’re seeing two charges. I’m checking the transaction record now.”

The prompt should explicitly restrict the source set and expose assumptions:

Draft a support reply using only VERIFIED CASE FACTS and APPROVED KNOWLEDGE.

The reply must:
- acknowledge the customer’s stated goal and impact;
- answer every question that the approved evidence supports;
- state the next action, owner, and timing;
- ask only for information still required;
- preserve uncertainty and policy conditions.

Do not invent a cause, status, date, remedy, eligibility decision, or promise.
Do not expose internal notes or mention risk labels.
If evidence is insufficient, say what must be checked and mark [AGENT DECISION].

After the draft, list claims with their supporting source and any escalation flag.

The claim list creates a review surface. It does not prove correctness: the model can pair a claim with the wrong excerpt. The agent still checks source, applicability, and freshness.

A useful reply often follows this order:

• Recognition: name the request or concrete impact.
• Answer or status: give the most important supported information early.
• Action: explain what has been done or what will happen next.
• Customer step: request only necessary action, with clear instructions.
• Expectation: state timing and conditions accurately.
• Close: explain how to continue if the expected outcome does not occur.

Do not force every reply into an apology-heavy script. If the team caused a documented problem, an accurate apology can be appropriate. If the cause is unknown, acknowledge the inconvenience without assigning blame: “I can see why being unable to access your account is disruptive” is safer than “We broke your account.”

Reduce repeated work. If the customer already supplied an order number, do not ask for it again. If identity verification requires a particular secure flow, direct them to that flow rather than asking for sensitive data in free text.

Support policies are often conditional: “returns are accepted within 30 days for unused items purchased directly from us.” A model may compress this to “You can return it within 30 days,” silently dropping product condition and sales channel.

Treat conditions, exclusions, amounts, dates, and jurisdiction as invariants. Ask the model to quote or list the exact policy elements used. If the customer’s case does not clearly meet every condition, draft a question or escalation instead of an eligibility decision.

The same rule applies to troubleshooting. “Restart the device” may be inappropriate when unsaved work could be lost. Approved steps should include prerequisites, stop conditions, and recovery paths.

Drafting is a language task. Approving a refund, changing an account, or disclosing case information is a decision. Sending creates customer impact. Keeping these stages separate makes review possible.

A low-risk acknowledgment may eventually be approved for automatic sending after extensive testing. A response involving billing, identity, safety, legal threats, policy exceptions, or meaningful commitments should retain a named human gate. Never let persuasive fluency erase the distinction.

Before sending, extract each:

• case fact and current status;
• policy statement and condition;
• date, duration, amount, and identifier;
• causal explanation;
• promised action, owner, and deadline;
• request for customer data;
• link or attachment.

Mark each as supported, unsupported, stale, conflicting, or requiring authority. Then read the reply as the customer will. Is the main answer visible? Does it imply certainty the evidence does not have? Could the requested step expose data or repeat work? Does “we’ll resolve this” promise an outcome when only an investigation is approved?

When a draft is weak, name the failure rather than asking for a generic rewrite:

• “Move the confirmed replacement status into the first paragraph.”
• “Remove the invented explanation for the warehouse delay.”
• “Preserve the policy condition that the item must be unused.”
• “Replace the guarantee with the approved estimate and fallback.”
• “Ask one combined verification question instead of three repeated requests.”

Focused revision limits drift and creates feedback that can improve the template.