Ticket reply draft for queue handling

Use this workflow when you need a safe first draft from a live support ticket. It gives you a reply that matches the case facts and approved policy, then makes you choose: send, edit or escalate.

This is for agents working a queue, not for writing a generic template. Run it once per ticket. Keep the ticket as the source of truth.

1. Collect the case record

Before opening the drafting tool, read the ticket from oldest to newest. Then collect only the material needed to answer this customer.

Create a short working note with these fields:

• Customer request: what the customer wants you to do or explain.
• Case facts: dates, order or case status, product, actions already taken and previous promises.
• Account notes: facts that change the answer, such as a prior exception or an open investigation.
• Relevant policy: paste the specific approved rule, including conditions and exclusions.
• Required next action: the action you can take now, or the team that must take it.
• Tone requirement: for example, concise, apologetic, firm or neutral.

Remove information that does not affect the reply. Do not paste passwords, payment card details, identity documents, access codes or private notes unrelated to the case. Use your approved workspace and follow your organisation's data-handling rules. Configuration and product behaviour can vary, so check the current xAI documentation before using customer data in a new setup.

2. Decide whether the ticket can be drafted

Do not draft every ticket. First decide whether you have enough evidence and authority to give an answer.

If the ticket contains	Do this before drafting	Likely decision
A clear request, confirmed facts and an applicable policy	Prepare the working note	Draft for review or send
A missing order status, unclear ownership or conflicting notes	Find the missing record or ask the owner	Edit or escalate
A request outside your authority or a policy exception	Record the exact exception requested	Escalate
A threat, safety concern, suspected fraud or sensitive complaint	Follow your internal urgent-case process	Escalate

If the customer has asked two questions, separate them in the working note. A draft that answers only the easier question is not ready to send.

3. Request a structured draft

Paste the working note and use a prompt that forces the reply to stay within the evidence. Ask for a decision as well as the customer-facing text.

Draft a customer support reply using only the case record below.

Customer request:
[insert]

Confirmed case facts:
[insert]

Relevant account notes:
[insert]

Approved policy:
[insert]

Required next action:
[insert]

Tone requirement:
[insert]

Rules:
- Do not invent dates, actions, eligibility, refunds, credits, causes or promises.
- If the record does not support an answer, state what is missing in the internal notes.
- Do not mention internal policies, teams or account notes to the customer unless the case record says to do so.
- Keep the reply concise and answer every customer question.
- Include any action the customer needs to take.

Return these sections:
1. Customer reply
2. Internal rationale: facts and policy points used
3. Missing information or risks
4. Decision: SEND, EDIT or ESCALATE, with one reason

Keep the case record close to the wording used in the ticket. For example, write replacement dispatched on 14 May rather than replacement is probably on its way. Exact facts make the review faster.

4. Check the draft against the ticket

Read the draft beside the ticket, not on its own. Check each sentence that makes a claim. In particular, verify dates, money amounts, eligibility, delivery status, promised actions and named teams.

Use this check before deciding what to do:

• Does the opening show that the draft understood the customer's actual question?
• Does every factual statement appear in the ticket, account record or approved policy?
• Does the outcome match the policy conditions, not just its general intention?
• Does the reply state what happens next and who does it?
• Does it avoid a promise that you or another team cannot keep?
• Does the wording fit your approved tone and avoid blame?
• Does it reveal no internal-only information?

A common failure is a draft that sounds helpful but quietly changes the case. Watch for words such as “shortly”, “guarantee”, “will”, “eligible” and “exception”. They can create a commitment where the record only supports a possibility or a next review step.

5. Make the send, edit or escalate decision

Choose one outcome. Record the reason in the ticket according to your normal queue process.

1. Send when the facts are confirmed, the policy applies, the reply answers every question and you have authority to take the stated action. Make any required personal edits first, then send it through the normal ticket channel.
2. Edit when the draft is substantively correct but needs a factual correction, clearer wording, a missing answer or a tone adjustment. Correct the case record first if needed. Then revise the reply and run the check again.
3. Escalate when evidence is missing, policies conflict, the customer requests an exception, the required action is outside your authority, or the case follows an urgent internal route. Send the escalation summary, not the unreviewed customer draft.

For an escalation, include: the customer request, confirmed facts, relevant policy, what you need decided and the customer impact of delay. State what you have already checked. This prevents the next team from reopening the same records.

When the workflow does not work

If the output is vague, shorten the input to the specific question and paste the exact policy section. If it invents a fact, remove that sentence and add the missing fact only after verifying it in the account record. If it repeatedly cannot produce a safe answer, stop drafting and escalate with the evidence you have.

Do not send a reply because it is well written. Send it only when the case record supports it.