Sample output: support triage review queue

This is the artifact a support-triage workflow should produce before it replies to a customer or changes anything: one reviewable queue item that shows what arrived, why it was classified, which source supports the next step, what remains unknown, and who owns the decision.

A polished reply is not the primary output. The primary output is a decision packet small enough for a support owner to inspect and correct.

Synthetic queue context

Request ID: SUPPORT-0147
Channel: website support form
Received: 2026-07-28 08:42
Customer identity: unverified
Account reference: missing
Product area: billing
Queue status: needs_human_review
Assigned lane: billing_escalation

Synthetic request summary: the sender says the same purchase appears twice and asks for one charge to be refunded.

The workflow preserves the request identifier and the uncertainty around identity. It does not infer an account from the sender’s name, merge the message with a similar prior ticket, or treat a billing claim as verified because the wording sounds plausible.

Classification and source check

Field	Proposed value	Reason or source	Review status
Category	Duplicate-charge report	The request names two charges for one purchase.	Plausible; verify against the account record.
Urgency	Normal billing review	No service outage, access loss, safety issue, or time-bound threat is stated.	Human may raise priority after account lookup.
Risk	Consequential	A refund changes money and requires explicit authority.	Must escalate; no automatic action.
Missing facts	Account or order reference	The message does not identify the transaction safely.	Ask for an approved identifier through the allowed channel.
Answer source	Example billing-support policy, current approved version	Defines identity checks, duplicate-charge review, and refund authority.	Reviewer must confirm the source is current.
Owner	Billing support lead	The declared escalation owner for refund decisions.	Confirm availability before sending anything.

The classification includes reasons because labels without evidence are weak automation. The source is described as an example policy in a synthetic artifact; it is not a claim about a real company, account, or customer.

Bounded draft

Draft status: held_for_review
Purpose: request the minimum information needed for account lookup

Thanks for flagging this. We need to verify the purchase before we can review
whether the charges are duplicates. Please reply through the approved support
channel with your order reference. Do not send card details or passwords.
A billing support owner will review the account record and confirm the next step.

The draft asks for missing context and avoids promising a refund, confirming that a duplicate charge occurred, or suggesting a deadline. It remains held because the workflow has not verified identity, transaction state, source currency, or the support owner’s decision.

If the approved policy requires a different verification method, the reviewer rejects this draft and uses the approved path. The model does not get to improvise identity handling.

Escalation and human decision

Escalation reason: money movement requested; customer identity unverified
Required reviewer: billing support lead
Prohibited actions: refund, account edit, payment-state change, autonomous send
Human decision: request approved account identifier; hold refund decision
Send decision: approve only the information-request reply after source review

The human reviewer can approve the information request without approving a refund. Those are different decisions and should not share one vague button.

A useful review surface records:

the category or priority correction, if any;
the exact source version the reviewer accepted;
the approved draft revision or hold reason;
the escalation owner and decision;
whether any reply was sent and by whom;
whether the ticket or account record changed.

Send and learning boundary

AI can prepare:

request normalization with stable identifiers;
proposed category, urgency, risk, and owner with reasons;
approved-source retrieval and stale-source warnings;
missing-information questions;
a bounded draft for reviewer inspection;
a summary of repeated human corrections using approved metadata.

AI should not:

guess customer identity, payment state, entitlement, or prior history;
approve or issue refunds, credits, cancellations, or account changes;
send through legal, security, privacy, safety, abuse, or high-conflict cases;
use stale or conflicting policy without exposing the conflict;
put raw customer messages or personal data into analytics;
treat queue closure, deflection, or a calm tone as proof of a correct outcome.

The first useful build should run on synthetic or safely exported examples with sending and write-back disabled. Widen the workflow only after the team can explain recurring corrections, keep the source set current, and name the owner who can stop it.