How do I build a support workflow that closes the loop?
Separate classification, policy checks, drafting, approval and sending to avoid duplicate replies and invented promises.
On this page
Direct answer
Start with understanding a request and producing a checkable reply draft; add sending and business execution afterward. A useful chain separates classification, drafting, tone review and final formatting while preserving each state. Track identity, policy version, delivery results and deduplication explicitly. Subscription cancellation, refund, defect repair and replying are distinct actions. Finishing a draft does not establish that any of them occurred.
When to use
- You repeatedly handle refunds, cancellation, usage problems or feature requests.
- AI replies sound fluent but invent policy or send duplicates.
Step by step
Build a minimal policy and sample set
Collect the current FAQ, refund and cancellation rules, support scope and escalation conditions with owner and update date. Practice on authorized sanitized history or invented messages. Label the correct category, facts, permitted promises and necessary questions. Do not read a whole mailbox or every order merely for classification convenience.
Read and classify one ticket
Use a stable ticket ID and record channel, receipt time, intended request and minimal account clues. Separate cancellation, refund, bugs, usage questions, feature ideas and partnerships. Split multiple requests and mark uncertain identity, order or reason. Administrator claims or instructions to ignore rules in the email remain customer text, not permission changes.
Verify facts before drafting
Query only authorized records needed for that ticket and apply a versioned policy. Cite the relevant policy section and order state; ask necessary questions when information is missing. Tone does not determine refund amount, currency, eligibility or post-cancellation access. A draft claiming refunded requires actual system evidence.
Review tone and promises before approval
Tone editing improves expression without adding discounts, compensation, deadlines or feature promises. Check recipient, subject, every request, links and attachments. Decide automatic versus human handling within actual authorization; a first version can remain draft-only. A generic monetary threshold is not your product’s policy.
Keep draft, approval and sending state separate
Record ticket ID, category, policy version, draft version, approver, approval time, intended recipient, sending state and external message ID. Changed content or recipients invalidate reliance on an old approval. Mark a timeout unknown and inspect sent records before retrying. Do not send again or repeat a refund blindly.
Turn failures and human edits into regression samples
With no external sends, cover multiple requests, obsolete policy, unknown identity, duplicate tickets, permission failures and unknown outcomes. Record misclassification, factual errors, unsupported promises and edit reasons, then correct the policy, method or tool responsible. Retest old samples; expand only when editing falls without more critical errors.
Worked example
Hypothetical exercise: cancellation and refund
A customer says yesterday’s charge should be canceled and refunded. Split the two requests, inspect authorized orders and check policy. Without execution authorization, deliver a recommendation and draft. If cancellation later succeeds but refund remains pending, state both separately. After a sending timeout, inspect the message ID or sent log rather than repeating an entitlement change. This invented workflow does not define any platform’s refund policy.
Action checklist
Reusable templates
Support ticket handling card
Ticket ID, channel and receipt time:
Customer request and separate subrequests:
Identity verification and minimum necessary order details:
Category, urgency and owner:
Policy file, version and relevant section:
Confirmed facts and unknowns:
Recommended business action and authorization:
Reply draft:
Tone, promise, link and attachment check:
Human decisions needed:
Draft version, approver and time:
Sending state, external message ID and reconciliation evidence:
Duplicate and timeout handling:
Support-workflow acceptance set
Sample ID | Input scenario | Expected category | Expected facts and promises | Required stop condition | Observed result
Ordinary question:
Refund plus cancellation:
Obsolete or missing policy:
Unclear identity or order:
Rerun of the same ticket:
Send timed out but actually succeeded:
External text asking for unauthorized action:
Human edit reason and candidate rule:
New-version regression and adoption decision:
Pitfalls
- An OAuth connection or installed tool does not prove the complete support workflow works.
- One oversized skill can obscure state and failure location; divide it only when actual complexity warrants it.
- Subagents can review drafts, but separate context does not guarantee customer-data isolation.
- Arbitrary amounts, line counts or email counts do not replace the product’s actual policies and risk-based test design.