Ticket triage and drafting
Each ticket is matched to the customer order before anything is written. A model trained on three years of Bloom replies drafts the answer, and an agent approves or edits it.
Six people were drowning in a support queue, and the brand posted whenever the founder found a spare hour. Drafts now arrive written, so the team approves instead of typing.
Hugo takes the project apart on screen: the bottleneck we found, the system we shipped, the number it moved.
No walkthrough yet. The written case below carries the same numbers.
Bloom Supply Co. sells refill cleaning products direct to consumers across the UK. Six people, 40,000 orders a year, one founder who wrote almost all of the marketing herself.
Support ran at 340 tickets a week and roughly 70 percent repeated. Three questions covered most of it: order tracking, subscription changes, bottle compatibility.
Median first reply was six hours. On Mondays it stretched past a day. Refund requests climbed every time the queue did, which made the queue worse.
Content was the other problem. The founder wrote at night when she had energy, so the brand published five posts in a week then went quiet for a month.
Two days of interviews and one week of their own data. Here is what was actually going wrong, told the way the people living with it told us.
Bloom had one founder doing two full time jobs. She answered support in the morning, wrote the marketing at night, so whichever queue shouted loudest got her.
Most of that typing was three questions dressed in different words. The team retyped the answers anyway, because the order lived in one system while the ticket sat in another.
Customers read the delay as indifference. A refund request usually arrived not because the product had failed, but because nobody had replied in a day. The queue was manufacturing its own work.
Built inside the tools the company already paid for. Every workflow, credential and prompt was handed over at the end.
Each ticket is matched to the customer order before anything is written. A model trained on three years of Bloom replies drafts the answer, and an agent approves or edits it.
Research runs every Monday on the questions customers actually asked that week. The founder picks an angle in five minutes, then reviews a week of posts written in her own voice.
Order history and churn signals decide who hears what. Every campaign is drafted against the same voice guide, then approved once before it goes out.
Before figures come from the company's own records, pulled during the audit. The after column is the ninety day average once every system was live.
| Metric | Before | After |
|---|---|---|
| Median first reply | 6 h | 11 min |
| Tickets answered under 15 min | 4% | 74% |
| Agent hours on support, weekly | 22 h | 7 h |
| Refunds requested for delay | 41 a quarter | 9 a quarter |
| Founder hours on content, weekly | 9 h | 45 min |
| Posts published per month | 8 | 24 |
I write one paragraph on a Monday and the whole week goes out. The support queue stopped being the thing I dreaded opening.
Every project has them. Writing them down is how the next one gets shorter.
We let the agent send low risk replies on its own in week three, before the team trusted it. Two poor answers reached customers, so we pulled it back to draft only for a month.
Approval first would have cost nothing and saved that month.
We also trained the writing on every past post rather than the best ones, which took a second pass to fix.
First system in production inside a month. Everything after that is iteration with the client in the room.




Summary, was 2 days: 5 min
Read the caseBack per week: 22 h
Read the caseThe AI and Operations Audit finds it, prices it, then hands you a plan in two working days. Your fee comes off the first thing you build with us.