Four hours to answer a complaint, fifteen minutes after the change

Where those four hours came from

An e-commerce business trading on three markets, roughly eight hundred orders a month, four people in customer service and three mailboxes — one per country. A customer writes in with a complaint. Before anybody can start composing an answer, they have to work through a sequence of moves, none of which is actual thinking:

• find whether this customer has written before, and in which of the three accounts;
• open the shop's admin panel and locate the order by name or address, because the order number is rarely in the email;
• check what exactly was shipped and when;
• recall what the company answers in this situation — because the rules exist, only not always in writing;
• write the reply and send it so that it lands in the same thread rather than starting a new one.

The four-hour median did not come from anyone spending four hours on it. It came from the complaint waiting until somebody had time to walk that path properly. With fifty emails a day, that calm tends to arrive in the afternoon.

What we built, in order, in 27 days

The system is three small pieces running in the background and one panel where the team works.

1. Mailboxes and orders in one place

Every ten minutes the system pulls new mail from the three mailboxes and tries to match it to an order in the shop. The database now holds over 7,500 messages, including the back history. When an agent opens a ticket, they see the email and the order it concerns side by side — without switching between two systems.

2. Threads that do not drift apart

All messages to the same customer land in a single thread — including when a different team member replies and when the reply goes out from the panel rather than from the mail client. It sounds like a detail, but drifting threads are exactly what makes it impossible to tell whether a case is closed.

3. A draft reply

The system prepares a draft in two to three seconds, based on the message, the order data and the company's written rules. The agent reads it, edits and sends — or deletes it and writes their own if the case is unusual.

Which change delivered the most

If one had to be named, it is not the AI-written draft. The biggest saving came from putting the email and the order in one view — because that removed the longest part of the path, which was searching.

The draft shortens what is left: instead of facing an empty box, the agent faces a written answer and decides what to change. The review takes about thirty seconds. That is the honest split of the gain: searching disappeared, writing shrank to reviewing.

The knowledge base, the most underrated part of the project

The system writes drafts from the message, the order data and the company's written rules. That third input is the only one you cannot take from any system — because it exists nowhere. It lives in the heads of four people in customer service.

In practice it works like this: you sit down with the team and walk through the situations that come up most. What do we say when a parcel never arrived. What when it arrived damaged. What when a customer wants to return goods after the deadline. Where is the line at which a manager decides. It turns out that in half the cases two people on the team answer differently — and that nobody had noticed, because everyone only ever saw their own mail.

What it costs to run

Worth stating, because the question always comes and the answer is usually vague. Here it is simple: infrastructure costs nothing while the team stays at five people or fewer — it fits inside the free tiers of the services it runs on. The only paid part is having a language model write the drafts, in the range of tens to a hundred and something dollars a month at over a hundred drafts a day.

That is not a rule for every project — with a larger team and more traffic the free tiers end and the bill grows. But it is worth knowing that a system of this class need not start with a fixed fee for merely existing.

Four traps that are easy to fall into

1. Automatic sending. The temptation is real, because nine out of ten drafts are visibly fine. The tenth, on a complaint, can cost you the customer. The human stays in the loop.
2. Guessing the order. When the email has no order number, it is tempting to substitute the closest match by surname. With two customers sharing a surname that ends in sending somebody else's data. A system that does not know must say so.
3. New threads instead of replies. If the answer goes out as a fresh message, the customer ends up with two parallel threads and after three days nobody knows what was agreed. Matching the existing thread is a technical detail that decides how the whole thing feels.
4. History starting on go-live day. A system that only knows correspondence from the moment it was switched on is useless for the first six months. That is why we loaded the back history — the database now holds over 7,500 messages, including pre-launch ones.

How long it took and how it was sequenced

The whole system was built in 27 days, across fifty steps recorded in the project history. I mention it not to boast about pace — a different scope would give a different number — but to show what a sensible order looks like.

1. First, pulling in the mail and matching it to orders. That part alone, without any artificial intelligence, removed the longest stretch of the path. Had the project stopped there, it would still have paid for itself.
2. Then sending with the thread preserved. Because without it the team would have gone back to the mail client anyway, and the system would have become one more place to check.
3. Drafting last. Only once the first two worked and we could see what real tickets looked like.

The reverse order — starting with the most impressive part — is tempting and ends in a system that beautifully drafts answers to tickets it cannot find.

What this system does not do

• It does not answer on its own. Every message goes out only once a human approves it.
• It does not guess when it does not know. If it cannot match an email to an order, it says so instead of substituting the nearest fit.
• It did not replace anybody. The same four people handle the same number of tickets — only the customer gets an answer the same morning.

The last point disappoints anyone hoping to cut headcount. We think it is the strength: in customer service, response time affects whether somebody buys again, and headcount mostly does not.