Supply approved documentation, extract the facts needed for the question, and draft an answer with unresolved items separated for the reviewer. Approve the exact message before sending it through your own support channel.
In this guide
What does a source-backed reply look like?
The 30-day rule is training material, not ToolFlowKit's return policy or a merchant's current terms. The customer-facing text avoids an invented approval and gives a next step. Keep the internal note out of the email body. If the policy owner authorizes an exception, save that decision with the version of the reply that uses it.
| Record | Filled example |
|---|---|
| Practice policy P1 | Standard return requests must be made within 30 days of delivery. No gift-extension rule supplied. |
| Customer question | The gift was delivered 35 days ago. Can I return it? |
| Reply draft | Our standard return window is 30 days from delivery. I can refer your request for an exception review; please share the order reference through our support channel. |
| Internal reviewer note | P1 supports the normal window. A support lead must decide any exception before a return is promised. |
Prepare a small, current answer pack
Include the customer's permitted question, the relevant product or order context, and the policy pages that apply. Give each source a title, version or checked date, and scope. Avoid sending unrelated personal or account details into a model when the answer does not need them.
Separate general policy from authority to make exceptions. A document saying a team may review a request does not authorize the draft to grant a refund. When the sources conflict or omit a condition, prepare a precise question for a support owner rather than letting the model reconcile policy by improvisation.
- Restate the customer's question and identify which approved source can answer each part.
- Check product, region, plan, dates, or account conditions that affect the answer.
- Draft the direct answer first, followed by the steps the customer can take.
- Keep internal source references and unresolved decisions in a separate reviewer note.
- Review the exact proposed reply for promises, amounts, dates, policy exceptions, and requests for information.
- After approval, send through the intended channel and record which draft version was approved.
Keep the approval tied to the exact message
A prompt asking a model to wait is an instruction, not an execution barrier. In an automated setup, hold the message in a draft state and require a stored approval of that version before the send step. If the body or recipient changes, return it for review.
Start with draft preparation in your existing support application. Add automation after the source selection and reviewer handoff work on representative questions. The cited platforms provide examples of this pattern; the steps here are an editorial design, not an installed integration.
Draft the answer and reviewer note separately
Prepare a support reply draft. CUSTOMER QUESTION: [permitted text] APPROVED SOURCES: [passages + ID + version/scope] KNOWN CONTEXT: [relevant facts] TONE: [clear and considerate] Answer each supported question directly, preserving conditions. Ask for necessary missing information or identify a decision for the support owner. Return customer-facing draft, source map, and reviewer questions separately. Do not invent policy, grant exceptions, promise dates, or claim an action has been completed. Keep sending for a person to approve.
Use recurring questions to improve the documentation
Track which questions repeatedly need the same explanation or policy clarification. Resolve those gaps in the source material before expanding automated replies. A well-maintained answer page reduces the number of facts each draft has to reconstruct.