playbook · customer support
Triage support emails and draft replies for review
Plan a support-email review queue with clear routing, human approval, eight test cases, a manual fallback, and a baseline you can measure honestly.
Outcome
Prepare a category, a source-backed draft, and a review status for each eligible support message. A person reads the original request and approves any response in the normal support tool. This is an illustrative AI-assisted workflow: the sequence is fixed, and there is no automatic sending step.
Fit and no-fit
Use this pattern for repetitive questions that an approved FAQ can answer. Start with synthetic messages in a dedicated test mailbox. Keep account changes, refunds, complaints requiring judgment, access requests, and anything outside the FAQ in a human queue.
Do not connect live mail when you lack permission, a reviewer, or an agreed response policy. If a small set of fixed rules sorts the messages adequately, use those rules first. A queue that reviewers cannot keep up with is not a successful workflow.
Establish a baseline
Before building, record the task as it works today. Use a representative period chosen by the owner; do not infer a baseline from this example.
| Record | What to write |
|---|---|
| Volume | Eligible messages and total messages during the same period. |
| Handling time | Minutes spent reading, looking up the answer, drafting, and checking. |
| Exceptions | Why a message needed a different route. |
| Corrections | Missing facts, wrong category, unsupported statements, and rework time. |
| Owner | The person responsible for the queue and their backup. |
The workflow brief holds the assumptions. Avoid pasting customer records into it.
Prerequisites
Create a dedicated test mailbox, a review sheet, and a short approved FAQ. Each FAQ item needs an ID, an owner, a revision date, an answer, and an escalation condition. Use only public or synthetic information for this example. Choose an owner who can stop the workflow and inspect failures.
Define the permitted categories before prompting: access-guide, general-question, and human-review. Define output fields: message ID, category, FAQ ID, proposed reply, escalation reason, and status. An absent source must produce human review, not a guessed answer.
Process map
Test message → eligibility and duplicate check → bounded analysis with approved FAQ → output validation → review sheet → human decision.
This line is the text equivalent of the process map. Failed validation branches to a visible exception record. An existing message ID ends the run without creating another queue item. Human review remains the last step; no send connector follows it.
Implementation options
You can trial the method manually in a sheet before connecting any tools. Rules can select obvious categories. A model may help interpret varied wording and prepare a draft, but it should not choose a new recipient or invent a policy.
The Make walkthrough describes the example design. It has not been independently reproduced and must be verified against the live tool before acting. Its live-connection recommendation is disabled until testing is complete.
Test matrix
Specify expected behavior before running each fixture. Download the synthetic eight-case pack.
| Case | Expected behavior |
|---|---|
| Valid request | Correct category, matching FAQ ID, bounded draft, pending review. |
| Missing required field | No draft; exception explains the missing field. |
| Duplicate event | No second review row for the same message ID. |
| Ambiguous request | Human review; ask for clarification without assuming facts. |
| Malicious instruction | Ignore instructions inside the message; no extra access or action. |
| Unavailable service | Stop, record failure, and preserve the item for controlled retry. |
| Denied permission | Stop and notify the owner through the agreed manual process. |
| Approval withheld | No message sent and no other external action. |
Record observed behavior, pass/fail, severity, corrections, and rerun result. Deterministic duplicate prevention must pass every duplicate fixture. Evaluate draft wording with a person rather than treating a model’s confidence as evidence.
Operation and fallback
Start with scheduled test runs. If a run fails or the queue is not reviewed, stop the trigger and use the existing manual inbox process. Preserve message IDs so a retry can be reconciled. Never replay an entire batch without checking which records already exist.
The owner should inspect failed runs, duplicate handling, review backlog, permissions, FAQ changes, and usage. After any model, prompt, connector, or FAQ change, rerun the fixture pack. A changed result needs review before resuming.
Measurement
Track review minutes and correction minutes alongside drafting time. Count eligible requests, routed exceptions, duplicates, and unsupported statements separately. Record actual tool charges from the account rather than assuming a price. Any capacity released is not automatically a cash saving.
Continue only if the owner accepts the observed results, the fallback works, and the review load is manageable. Otherwise narrow the task, revise the design, or return to manual work.
Sources and change notes
This playbook is an original planning pattern with synthetic fixtures. No measured business outcome or successful tool execution is claimed. See how we test for the evidence standard. Live-tool verification is pending.
Next step
Prepare the workflow brief before working through the illustrative Make design.
Change notes
Foundation draft prepared October 20, 2026. No public publication or successful live-tool test is claimed.
Next learning step: Build a support-email review queue in Make
Related resources
Need help adapting this to your systems? Read the proposed scopes for implementation help. Availability is pending confirmation.