Draft-and-Approve AI Support: A Category Decision Framework

Full automation is not the goal. The goal is knowing exactly which ticket categories your AI can handle solo, which ones need a human glance before sending, and which ones should never touch the queue. Here is the category-by-category decision framework I built into Trigli's automation rules - and how to apply it to your own support stack today.

The short version

Most teams I have talked to make one of two mistakes. They try to automate everything on day one, something goes wrong, and they turn it all off. Or they are so scared of that outcome that they never automate anything and keep paying $3-4K per month per support rep to answer the same WISMO emails on repeat.

The middle ground is not a compromise. It is actually the correct architecture. You map each ticket category to one of four actions: auto_send, draft, human_review, or skip. Each category gets exactly one action. You set it up in an afternoon. You adjust it as confidence data comes in. That is the whole framework.

If you want to see how this plays out in practice before reading the whole post, the free tier at trigli.com is $0 and lets you connect your inbox and set your first rules with no card required.

Why full automation is the wrong starting point

You probably heard about Klarna. They pushed AI into the queue for nearly everything, cut support headcount aggressively, and then quietly walked some of it back when the customer experience degraded. Hacker News had a field day. The lesson most people took was "AI support does not work." That is the wrong lesson.

The actual lesson is that the blast radius of a bad auto-sent reply is not uniform across ticket types. A wrong answer on a WISMO email is a minor inconvenience. A wrong answer on a billing dispute is real damage - potential chargeback, potential legal exposure, definitely a lost customer. If you treat those two categories the same way in your automation rules, you are going to have a bad time.

Think about the math. If you auto-send 50 WISMO replies and 2 of them are slightly off, the cost is two follow-up emails. If you auto-send 5 billing dispute replies and 1 of them is wrong, you might be looking at a chargeback, a refund you did not intend to issue, and a customer who posts about it. The expected cost of those two errors is not comparable.

Draft-and-approve is not a stepping stone to full automation. For certain categories, it is the permanent setting. That is not a failure mode. That is the correct answer. For more on keeping automation from going sideways, see /blog/automate-customer-support-without-losing-human-touch.

The four routing actions explained

Here is what each action actually does inside Trigli's automation rules - and what the equivalent would look like in any system you build yourself.

auto_send: the AI writes the reply and sends it immediately, no human in the loop. Only fires when the confidence score is above your set threshold. Below that floor, it falls back to draft regardless of the category rule.

draft: the AI writes the reply and drops it in your queue. One click to approve, or edit and send. The reply does not go anywhere until a human says so.

human_review: the ticket is flagged and assigned to a team member. The AI does not draft a reply at all. The human starts from scratch.

skip: the automation system ignores the ticket entirely. It falls into normal inbox flow. No AI involvement, no flagging, no draft.

The confidence floor is your safety net across all of this. Even if a category is set to auto_send, if the AI's confidence on a specific reply is below your threshold - say, 80% - it will not send. It will draft instead. Set that floor conservatively when you start. You can always raise it later once you have seen how the AI performs on your actual ticket mix.

The default for a new account should always be draft, not auto_send. Every time.

The decision framework: four questions per category

For each ticket category in your queue, ask these four questions in order. First, how factual is the answer? A WISMO reply is a lookup. A billing dispute requires judgment about intent, context, and relationship history. Factual answers are automation candidates. Judgment calls are not.

Second, what is the blast radius if the AI gets it wrong? Wrong order status means a minor correction, the customer follows up, you fix it. Wrong refund amount means real financial damage, potential chargeback, broken trust. High blast radius categories should never be on auto_send.

Third, how often does this category appear? High volume plus low blast radius is the strongest signal for auto_send. If the category shows up 200 times a month and the worst case of a wrong answer is a follow-up email, that is exactly what automation is for.

Fourth, does the reply require any action outside the inbox? Answering a return policy question is pure information. Processing a refund inside Shopify requires a human to actually do something. If the reply commits you to an action that the AI cannot execute, a human needs to be in the loop before the reply goes out.

Picture a simple grid. One axis is blast radius (low to high). The other axis is answer complexity (factual to judgment-based). Low blast radius plus factual answer: auto_send. High blast radius plus judgment-based: human_review. The middle ground is where draft lives.

Categories that belong on auto_send

Most teams I have talked to see 60-70% of their ticket volume fall into categories that are legitimate auto_send candidates once the AI has been trained on their docs. Here is what that typically looks like.

WISMO (where is my order): factual, high volume, low blast radius. The answer is in the tracking data. They want the tracking link, not a conversation.

Business hours and location questions: static information. No judgment required. The AI reads it from your docs and sends it.

Password reset instructions: procedural and policy-based. No account action required from the support team.

Shipping policy and return window questions: your docs have the answer. The AI reads from those docs only and flags anything it is uncertain about for review.

Estimated delivery time questions: factual lookup based on shipping method and destination.

Basic product compatibility questions where the answer is documented.

The common thread: the answer exists in your documentation, no human judgment is required, and a wrong answer is correctable without lasting damage. If all three are true, auto_send is the right call once you have validated the AI's performance on that category.

Categories that belong on draft

Draft is where the AI does the heavy lifting but a human makes the final call. These are categories where the answer is probably right but the stakes are high enough that you want eyes on it before it goes out.

Refund requests where eligibility is clear but you want a human to confirm before committing: the AI drafts the reply, a human approves it.

Subscription cancellation acknowledgments: the AI drafts a polite reply, a human checks the tone and decides whether to add a retention offer.

First reply to a complaint: the AI drafts an empathetic acknowledgment, a human reviews it before it goes out. You do not want to auto-send the first reply to an upset customer.

Account-specific questions that require pulling context from multiple sources: the AI drafts based on what it knows, a human verifies the specifics.

New customer onboarding questions: the AI drafts from your docs, a human checks that the answer is actually relevant to that customer's plan or situation.

The value here is that the AI is doing 80% of the work - researching the answer, writing the reply, formatting it correctly - and the human is doing a 10-second review instead of writing from scratch. For some of these categories, draft will be the permanent setting. That is fine.

Categories that belong on human_review

Human_review means the AI does not draft anything. The ticket gets flagged and assigned to a team member who handles it from scratch. These are the categories where AI involvement in the reply itself is the wrong call.

Billing disputes and charge disputes: judgment call, potential legal exposure, never auto-send and probably should not even draft.

Escalations from a previous bad experience: the customer already had one bad interaction. A generic-sounding reply is the worst possible follow-up.

Anything involving a threat - chargeback threat, legal threat, public complaint threat: a human needs to own this.

VIP or high-value account tickets: flag by sender domain or account tag, route to a senior rep every time.

Emotionally charged messages: the AI can pick up sentiment signals but a human should own the reply when a customer is clearly distressed.

Categories that belong on skip

Skip is different from human_review. Human_review means the automation system actively flags the ticket for attention. Skip means the automation system ignores it entirely and it falls into normal inbox flow.

Internal team emails that land in the support inbox, automated system notifications like Stripe webhooks or shipping carrier updates that do not need a reply, spam and obvious non-support traffic, vendor invoices and partnership pitches - all of these belong on skip.

If you do not set skip rules for these, your automation will try to draft replies to Stripe payment confirmation emails. Set the skip rules early.

How to build the rule stack in practice

Start with three to five categories maximum. Do not try to map your entire ticket taxonomy on day one. You will get it wrong and spend a week fixing rules instead of watching the system work.

Priority ordering matters. More specific rules fire before broader ones. If you have a rule for sub_category=billing_dispute and a broader rule for sub_category=billing, the dispute rule needs to be higher in the stack or it will never fire.

In Trigli's automation rules, you match on sub_category, sender, or subject. A WISMO rule looks like: match sub_category=order_status, action=auto_send, confidence floor=85%. A billing dispute rule looks like: match sub_category=billing_dispute, action=human_review. No confidence floor needed on human_review because the AI is not drafting anything anyway.

Run draft mode for two weeks before you promote any category to auto_send. Look at the drafts. See how often you edit them. If you are approving 95% without changes, that category is a candidate for auto_send. If you are editing 40% of them, it is not ready.

For more on what response time improvements look like once you have this running, see /blog/reduce-customer-support-response-time.

A starter rule stack you can copy today

Here is a concrete five-rule starting stack. This covers the most common ticket mix for a small e-commerce or SaaS team.

Add rules incrementally as new categories emerge in your queue. Do not pre-build rules for categories you have not seen yet. Let the real ticket mix tell you what to build next.

How to know when to promote a category from draft to auto_send

Track your edit rate on drafts per category. If you are approving 95% or more without changes, that category is a candidate for promotion. If you are editing 30-40% of them, the AI is not ready on that category yet - check your knowledge base content and see what is missing.

Set a minimum sample size before you promote. I would not move a category to auto_send on fewer than 50 reviewed drafts. That is not enough signal. 100 is better.

Also look at what happens after auto-sent messages go out. Are customers replying with follow-up questions that suggest the first answer was off? Any uptick in complaints after you promote a category is a signal to pull it back to draft.

The per-message good/bad feedback in Trigli's chat widget gives you a real signal on AI quality before you commit to auto_send on chat. Use it. It feeds directly into the AI's learning and shows you where the gaps are.

Be honest with yourself: some categories will stay on draft forever and that is fine. Draft is not a failure mode. It is the right answer for anything where human judgment adds real value.

What this looks like inside Trigli

The automation rules screen in Trigli lets you set category match conditions, pick an action, set priority order, and configure the confidence floor - all in one place. You can see the full rule stack and reorder it by dragging.

Before the AI drafts anything, it runs a reply style scan on your past sent emails. That means drafts sound like your team, not like a generic support bot. It picks up your tone, your sign-off style, how formal or casual you are with customers.

The knowledge base is where the AI gets its answers. PDFs, pasted text, URL imports. The AI answers from those sources and flags anything it is not confident about for human review. If a question falls outside your docs, it will say so rather than guess. If your return policy doc has gaps, the AI will answer based on what is there - keep the docs current.

Ticketing is built in. Priority levels, assignment to specific team members, internal notes that do not go to the customer, SLA tracking with overdue alerts. Drafts live in the same queue as tickets so you are not context-switching between systems.

Gmail and Outlook both connect via OAuth 2.0. Both are shipped and working today. Replies send from your real email address, not from a trigli.com domain. The automation rules apply to your real inbox.

Pricing is flat. Growth plan at $149/month covers 2,500 emails, 1,000 chats, and 500 tickets. No per-resolution fees that penalize you for automating well. See the full breakdown at /pricing. For context on what a support rep costs versus this kind of setup, see /blog/cost-of-support-rep-vs-ai.

Honest summary: what this framework does not solve

If your ticket categories are not defined yet, you need to do that work first. The framework assumes you know your top 10 categories. If everything is landing in a single "general inquiry" bucket, start by tagging a week's worth of tickets manually and see what the actual distribution looks like.

This does not work for channels outside email and chat. No phone, no SMS, no Instagram DMs, no WhatsApp. If those channels are a significant part of your support volume, this framework covers only part of your problem.

If you need to take action inside Shopify - process a refund, cancel an order, update a subscription - the AI can draft the reply but a human still does the action. Trigli does not execute Shopify operations. The draft tells the customer what is going to happen; the human makes it happen.

Per-agent productivity reporting is not in Trigli yet. You can see category-level patterns and overall volume, but not individual agent stats like tickets resolved per rep per week. If that reporting matters for your team, be honest about whether this fits your needs. Small teams using Trigli for email, chat, and ticketing can find more context at /use-cases/small-business.

The framework is only as good as your knowledge base. If your return policy doc is outdated or your shipping FAQ is missing edge cases, the AI will answer based on what is there. Keep the docs current.

Worth trying today?

The free tier is $0, no card required, 50 emails, 25 chats, and 10 tickets to test with. Paid plans start at $49/month. Growth at $149/month flat covers most small teams without per-resolution fees eating into the savings.

Paid plans come with a 14-day free trial. Card is collected at signup but only charged on day 15 if you have not cancelled. Setup takes about five minutes - OAuth connect, paste in your docs, set three rules, watch drafts appear in your queue.

If the category framework resonates and you want to see it running on your actual inbox, the free tier is no commitment.