Seventy per cent of the tickets. Thirty cents each.

The brand is small enough that support is a handful of people and large enough that the queue never empties. It sells consumer hardware direct to customers, almost entirely through Shopify, and handles every customer conversation in Zendesk. We are not naming it, and nothing in what follows depends on who it is.

The brief was narrow, and in hindsight that is why the pilot worked. The team did not want a chatbot answering customers on their behalf. They wanted their agents to stop writing the same reply from scratch — to open a ticket and find a correct, sourced draft already waiting, which they could send, edit or throw away. Nothing would reach a customer without a person approving it.

Why one prompt is not enough

The obvious build is a single model call: hand it the ticket and the help-centre articles, ask for a reply. It produces fluent drafts quickly, and it fails in exactly the places that matter. It states a delivery date it never looked up. It offers a refund the policy does not allow. It answers the question it expected rather than the one the customer asked. Each of those is a draft the agent has to catch, and an agent who must read every draft with suspicion saves very little time.

The fix is the one that separates a trustworthy shopping assistant from a plausible one, which we went through in our piece on grounded product search: retrieve first, generate second, and only from what came back. In support that has to be enforced by structure rather than by instruction. A model told to use only its sources will usually comply. A pipeline that checks whether it did is the difference between usually and reliably.

The pipeline, stage by stage

Every ticket goes through the same sequence. Each stage has one job and a defined way to fail.

The sequence is the same for every store; what differs between brands is the policy and the data the grounding step can reach.

Two design choices carry most of the weight. The checker is a separate step with a different job, not the drafting model asked to double-check itself; a model reviewing its own output tends to agree with it. And the pipeline is allowed to give up. A dropped draft costs an agent nothing — they write the reply they would have written anyway — while a wrong draft that slips through costs trust in every draft that follows.

The steps run on a durable workflow engine, so a slow order lookup or a timed-out model call resumes rather than starting over, and every step is logged. When an agent asks why a draft said something, the answer is a trace: these sources, this objection, this revision.

What “resolved” means here

A ticket counts as resolved when it was closed with the pipeline's draft as the reply, approved by an agent with or without light edits. On that definition, 70% of incoming tickets in the pilot were resolved. It is one company's pilot rather than a controlled trial, and the figure depends heavily on the ticket mix: a queue dominated by order-status questions will do better, one made up mostly of technical faults will do worse.

The other thirty per cent are less a failure rate than a boundary. Some request types are marked human-only in the policy from the start — complaints, disputes, anything the policy does not cover. Others reach a person because the grounding step could not find what the reply needed, or because the checker would not pass the draft. That is the system doing its job. The agents' time goes to the tickets that need judgement, and those tickets arrive with the context already gathered.

The economics: about thirty cents a ticket

Across the pilot, the AI service cost averaged roughly €0.30 per ticket. That covers every model call in the sequence: intake, the maker, the checker, any retries and the final writer. Two things keep it there. The expensive model runs once, for the final email, while the high-volume steps use faster ones. And the parts of every prompt that never change — the policies, the brand voice, the instructions — are cached, so each ticket pays mainly for what is specific to it.

The number worth comparing is slightly different. Every ticket incurs the AI cost, but only the resolved ones replace an agent's work, so the cost per resolved ticket is €0.30 divided by 0.70, or roughly €0.43. Set that against your own fully loaded cost of a person handling a routine ticket — their time, the salary behind it, the tooling — and the arithmetic is yours to do with your own numbers. We would rather you did it than borrowed a benchmark from us.

What the figure does not include is the subscription, or the setup work, which in this case was mostly the customer's own.

The real input was the policy, not the model

The most valuable artefact in the pilot was not a prompt. It was the support specification the brand wrote before anything was switched on: for each request type, what the right answer is, what may be promised, what must never be, and when to hand over. The checker enforces that document. Where it was vague, the drafts were vague too, and the fix every time was to sharpen the policy rather than tune a model.

This is also why the approach transfers. The pipeline is the same for any Shopify or WooCommerce store working in Zendesk; what changes is the policy and the data it can reach. A brand that has never written down its returns rules will find that it needs to, and will be better off for it whatever software it ends up using.

When it will not work for you

Three conditions have to hold. The facts your replies depend on must be reachable: order and shipment data through the store platform, product data from the catalogue. Your policies must exist in writing, specifically enough that a reviewer could say whether a reply complies. And your queue must repeat itself enough to be worth automating. If every ticket is a novel engineering problem, drafts will rarely survive the checker, and that is the correct outcome.

If those conditions hold, the recommendation is the one we give for all of this: run it on your own queue, draft-only, for a few weeks, and count. Your resolution rate on your tickets is the only number that should decide it.

A short checklist

Before you start, export a month of tickets and sort them by type. Write the policy for the three most common types. Confirm the order and catalogue data is reachable, and decide which request types stay human-only. Then switch it on in draft mode and track two numbers each week: the share of tickets closed with the draft, and the share of drafts your agents discarded. The second number tells you exactly where the policy still needs work.

The integrations behind this — Shopify, WooCommerce and Zendesk — are listed on the SalesBot page.