Reply macros from resolved support tickets

Use resolved tickets to produce candidate reply macros that an agent can find, trust and use without editing the facts. This workflow is for the support operations lead or senior agent responsible for a shared macro library.

Your output is not a list of polished replies. It is a review pack: each macro has a clear trigger, customer-facing text, exclusions and a named approval point before publication.

1. Set the review batch and fields

Choose one queue, issue type or product area. Do not mix unrelated tickets in the first pass. A batch such as delivery delays, password reset, or duplicate charge query gives you comparable cases.

Collect only tickets that meet all of these conditions:

• The case is resolved and the resolution is confirmed by your normal support process.
• The final answer reflects current policy, product behaviour and links.
• The ticket has enough internal notes to show why the agent chose that answer.
• The case does not depend on a one-off exception, goodwill gesture or account-specific arrangement.
• The customer message and final reply can be redacted safely.

Create a working sheet or document with these fields for every ticket:

Field	What to record
Ticket reference	Internal reference only, for audit and later review
Customer intent	The question or problem in plain language
Conditions	Facts that made this resolution applicable
Final resolution	What the agent did or told the customer
Source of truth	Policy page, internal procedure or product owner confirmation
Exception	Any reason this reply should not become a macro

Remove names, email addresses, order references, account details and any other customer-identifying information before you share the material with the model. Check the organisation's approved data-handling route first. Available product features and limits are version-dependent, so consult the xAI documentation overview before moving ticket content into a new workflow.

2. Group tickets by repeatable intent

Read the batch and group tickets by the customer's underlying need, not by the words they used. For example, Where is my order?, My parcel has not arrived, and Tracking has stopped moving may be separate groups if each needs a different action.

For each group, write a short trigger in the language an agent can recognise while working a queue. A good trigger contains the customer intent and the conditions that matter.

• Weak trigger: Delivery issue
• Useful trigger: Tracking shows dispatched, estimated delivery date has passed, and no loss scan is present

Then list the exclusions. These are not edge notes. They prevent agents from sending a reassuring answer where an investigation, refund review or account check is needed.

For the delivery example, exclusions might include:

• The tracking record shows a loss, return or failed delivery scan.
• The item is a regulated or restricted product.
• The customer reports damage or a missing item.
• A promised delivery date has contractual significance under your internal policy.

Keep each group separate if its trigger, action or exclusion differs. Combining them makes search results shorter but raises the risk of the wrong reply being sent.

3. Ask for macro candidates in a fixed format

Give the model one intent group at a time. Include the redacted ticket summaries, the approved source material and your existing macro naming rules. Tell it not to invent policy, links, timeframes, eligibility rules or actions.

Use a prompt shaped like this:

Create candidate customer support reply macros from the approved material below.

Return one macro per distinct repeatable intent. For each macro provide:
- Macro name
- Trigger: observable conditions that mean an agent may use it
- Customer-facing text
- Exclusions: conditions that require a different workflow
- Agent note: checks to complete before sending
- Evidence: ticket references and source-of-truth references used
- Owner approval: leave as PENDING

Use only facts present in the supplied material. If facts conflict or are missing, mark the macro NEEDS REVIEW rather than filling the gap. Keep the customer text clear, calm and direct.

Paste the model output into your review sheet, not directly into the macro tool. Keep the ticket references and policy references beside each candidate. They give the reviewer a way to test the wording later.

4. Review each candidate against the evidence

Review the draft in this order. Start with applicability, then facts, then tone. There is no value in a friendly macro that sends customers down the wrong path.

1. Read the trigger beside two or three source tickets. Confirm every condition is observable to an agent.
2. Read the exclusions. Add cases where the reply would delay a necessary escalation or action.
3. Compare each factual statement with the approved source. Check links, product names, process names and any conditional wording.
4. Check that the customer text says what will happen next, who will do it and what the customer should provide, if anything.
5. Compare the draft with nearby macros. Remove duplicate names and contradictory advice.
6. Assign an owner approval point. This should be the policy owner, product owner or support operations owner who can approve the content, not merely the person who formatted it.

Use a simple status field: PENDING, APPROVED, REWORK, or RETIRED. Do not publish a macro marked PENDING because it sounds complete.

5. Check for wrong output before approval

The model may turn a common pattern into an overconfident rule. It may also blend facts from similar tickets. Find this by testing the draft against tickets it was not built from: one case that should match and one that should be excluded.

If you see this	Treat it as wrong when	What to do
A broad trigger	Agents could apply it to different root causes	Add observable conditions or split the macro
A definite promise	The evidence only shows a usual outcome	Replace it with approved conditional wording
Missing exclusions	A risky or exceptional case could receive it	Add the stop condition and link the correct workflow internally
New facts or steps	They do not appear in the supplied sources	Remove them and ask the owner to supply the missing rule
Generic empathy	It hides the next action	Keep it brief and state the actual next step

6. Publish, label and hand over

Once the owner marks a candidate APPROVED, add it to the shared library using the same fields used in review. Use a searchable name based on the intent, not internal project language. Add the trigger and exclusions to the agent-facing description if the macro tool supports them. If it does not, include a short pre-send check in the macro's internal note.

Record these handover details:

• Macro name and library location.
• Approved owner and approval date in your internal record.
• Source-of-truth reference.
• Queue or tag where agents should use it.
• Review owner and a review condition, such as a policy change, product release or repeated agent edits.

Sample the first live uses through normal quality review. Track edits made before sending. Repeated edits usually mean the trigger is too broad, the wording is incomplete, or the macro is in the wrong place in the library.

When the workflow does not work

If the batch produces many NEEDS REVIEW items, stop expanding the batch. The problem is usually missing source material or an intent group that is too broad. Ask the relevant owner to settle the rule, then rerun only that group.

If agents cannot find approved macros, do not create more of them first. Review names, tags and library categories using the words agents see in tickets. If agents find macros but do not use them, inspect the exclusions and pre-send checks. A macro that asks for information the agent cannot see will be bypassed.

Retire any macro when its source of truth changes, its owner cannot confirm it, or quality checks show it is repeatedly selected for the wrong cases.