Key takeaways
- Start with the jobs whose output lands in a field, a queue or a report you control: triage, routing, status chasing, reporting. A mistake there costs an hour, not a relationship.
- The risk in support is rarely money. It is that the wrong message reaches a real person and cannot be recalled, so the gate belongs immediately before the send.
- Judge the automation on what customers received. First-response time and tickets-per-hour both improve when a machine sends fast rubbish, so read a sample of sent replies instead.
- Refunds, credits and account restrictions keep a permanent human approval, because they are decisions about an individual with a real consequence.
- If you cannot take twenty past tickets of a type and say what the correct handling would have been, you have a habit rather than a procedure. Write it down first.
The recurring support jobs, and which end of the list to start from
A support team repeats about seven jobs. The column that should drive your sequencing is the fourth: whether a mistake makes an internal mess you can quietly fix, or a message a customer has already read.
| Job | Frequency | Variability | Wrong output means | Approval needed |
|---|---|---|---|---|
| Triage and routing | Every ticket | Low, once categories settle | The ticket is answered late from the wrong queue | None. Reversible in a click; sample the classifications |
| Recurring reporting | Weekly | Low | A colleague reads a wrong number for a week | None. Reconcile against the source system |
| Status chasing | Daily | Medium. Depends why it stalled | A customer gets a nudge they did not need | Human approves anything off-template |
| Knowledge-base upkeep | Weekly | Medium | An article is quietly wrong until someone notices | Human approves publication, permanently |
| Escalation to engineering | Weekly | High. Every case differs | A bad report burns a day, or a real bug is lost | Human approves the handover; the write-up is drafted |
| First-response drafting | Every ticket | High | A wrong or invented answer reaches the customer, permanently | Human approves before the send, per reply type |
| Refunds, credits, goodwill | Several a day | High | Money leaves, or a customer is refused what they were owed | Permanent. It is a decision about a person |
Start at the top. The first four land their output in a field, a queue or a document you own, so a mistake costs an hour rather than a relationship. They are also your highest-frequency, lowest-variability work — Google's definition of toil: manual, repetitive, automatable, producing no enduring value, and growing in direct proportion to how well the business is doing. Triage grows with every customer you win.
The bottom two rows are what teams reach for first, because reply drafting demos well. They are the right target eventually and the wrong one on day one: you have not yet built the thing that decides whether a draft is good enough to send.
Why the approval gate belongs immediately before the send
In finance the irreversible moment is the payment. In support it is the send. The classification, the lookup and five rewrites of the draft cost nothing to redo; the delivered message is a thing your customer has read. So let the process classify, retrieve and draft freely, then stop it dead in front of the send. The gate sits at the boundary of your systems, not at the step where the thinking happened.
- 01A ticket arrivesTriggerAn email, a chat, a form. Nothing has left the building.
- 02Classify, deduplicate, pull the recordCodeCategory, priority, language, plan, entitlement, order state, prior tickets. Once the categories stop moving this is ordinary deterministic code, testable against past tickets.
- 03Decide the handling and draft the replyAI judgmentChoosing between five near-identical policies for an ambiguous complaint is judgment, and so is writing the answer. The step worth paying a model for, and the step to keep shrinking.
- 04Approve the sendHuman approvalOne question on the finished artefact: would I put my name on this, going to this customer, today? A review of what is about to leave, not of the reasoning.
- 05Send, update the ticket, record the runCodeDelivery, the write-back, and a recorded run you can replay to see what the reviewer approved.
Step three is the expensive one. Every reply type that turns out to have the same shape every time should stop being a judgment call and become a written procedure with fixed wording.
An automation-readiness rubric for one support job
Before automating any row of that table, answer five questions about the specific job. A no near the top stops you; a no further down only changes the design.
| Check | What the answer changes |
|---|---|
| Can you take twenty past tickets of this type and say what the correct handling would have been? | A no means you have a habit, not a procedure. The disagreements that exercise surfaces are the real work. |
| Is the right answer fixed by data the system can read: plan, entitlement, order state, prior tickets? | A no keeps the decision with a person. Automate the retrieval and the write-up around them instead. |
| Does the output leave the building? | A yes puts the gate before the send until that reply type has a track record. A no can run unattended sooner. |
| Would the outcome change what this customer gets: a refund, a credit, a restriction? | A yes makes the approval permanent, and the reviewer needs authority to overturn the decision, not just to approve it. |
| Will you know within a day, and can you undo it? | A no means sampling and a rollback path come before autonomy. Silent failures cost customers. |
Pass the first two with no customer-facing output and the job is ready now. Pass them but send something, and it is ready behind a gate. Fail the first and this is not an automation problem.
Judge it on what the customer received, not on ticket throughput
The numbers a support team already reports are the wrong ones here. First-response time improves the instant a machine sends fast rubbish, and tickets per agent-hour improves when replies are unhelpful enough that customers give up.
The honest measure is a read-back: somebody reads a sample of what was actually sent and answers one question per reply — would I have sent this? Be explicit about the target too, because 100% is the wrong reliability target for basically everything. The question is whether you know your error rate and are content with it.
A support lead automates shipping-status replies. In week one the process drafts 180 and the lead approves every send, rewriting or rejecting 22. By week four it is 4 out of 190, so that reply type sends without a gate and the lead reads a random 20 sent replies a week instead.
Two weeks later the sample turns up two replies quoting a delivery date misread from a carrier response. First-response time had improved in both weeks; only the read-back caught it. The fault was in the deterministic lookup, not the drafting. These figures are illustrative, not measured results.
What keeps a human approval permanently
- Decisions about an individual. Refusing a refund, restricting an account, denying a warranty claim. Where a decision produces legal or similarly significant effects for a person, the GDPR gives that person the right to obtain human intervention, express a view and contest the decision.
- Money moving out. A credit or a refund is a payment, and payments keep an approver regardless of size.
- Complaints, legal threats and vulnerable customers. Lowest volume, highest cost. A tone-deaf automated reply here is the worst trade in the function.
Everything else can become code over time. all-agents learns a support process by doing it with you, captures each accepted run as an example, sharpens the written procedure run by run, and turns the settled parts into deterministic steps once you decide it is ready — while the gates you pin stay permanent. Support has more of those than most functions, and that is the point rather than a limitation.
Limitations and when not to use this
- This page assumes a team handling tens to hundreds of tickets a day across a helpdesk, a billing system and a knowledge base. A contact centre with voice queues, workforce management and regulated call recording is a different problem.
- Do not automate a support job while the product it supports changes every week. The ticket mix will move faster than the procedure can be written down, and correcting the automation will cost more than it saves.
- If your volume is genuinely low, saved replies and a routing rule capture most of the benefit for almost none of the effort. Frequency is the whole argument for automating this work.
- Nothing here is legal advice. The GDPR position is summarised, not applied to your circumstances; take advice before removing a human from a path that carries legal effect.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 24 July 2026
- Embracing Risk — Google, Site Reliability Engineering Accessed 24 July 2026
- Art. 22 GDPR — Automated individual decision-making — GDPR Accessed 24 July 2026
Design the gate before the send
The approval patterns behind this page, matched to risk tiers: when to block, when to allow an undo, when to sample, and which gates stay permanent.
Design the gate before the sendUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.