Case study · AI support automation
A support inbox where every reply arrives ready to check and send
NewmanBands (opens in a new tab) sells men's wedding rings, about 3,800 of them, and gets 500 to 1,000 support tickets a month. Its replies were already written. The slow part was everything an agent had to do before sending one.
- 500 to 1,000 tickets a month
- 97 approved reply templates
- Live since February 2026
- A person approves every reply
The part that took the time
These were not the easy tickets. The store's existing automation had already handled those. What was left went to a person, and each one meant the same loop: read the ticket, decide which canned reply fits, switch to WooCommerce, find the customer's order, then copy the tracking number and the status back across by hand.
The agent was the link between the helpdesk and the store. Every answer was already approved and waiting. Someone still had to go and fetch the facts to put in it, 500 to 1,000 times a month.
What I built
A service that sits between GrooveHQ and WooCommerce and does the fetching. It leaves a draft in the ticket with an internal note for the agent. The agent reads it, changes anything they want, and sends.
Why it can't say the wrong thing to a customer
This is the question every owner asks first, and it deserves a mechanical answer rather than a reassurance.
-
The AI picks a reply, it never writes one
It chooses one of 97 templates the business wrote and approved, then fills in the real order details. Every word a customer reads came from NewmanBands. A wrong answer is an approved answer used in the wrong place, which anyone can find and fix.
-
"Never sends to a customer" is a test, not a setting
A test fails the build if any code path could send a message. Settings get changed by accident. A failing test stops the change from shipping.
-
When it isn't sure, a person gets the ticket
The filter that drops receipts, reports and cold outreach fails open. If it errors or hesitates, the ticket goes straight through to a human, because losing a real customer costs more than a wasted draft.
-
It waits for the humans and the other robots
It holds off for 90 seconds so the store's own automation goes first, then checks again before writing. If an agent has picked the ticket up in the meantime, the agent wins.
Four decisions worth explaining
A strong model where it counts, a cheap one everywhere else
One decision reaches customers: which reply fits. That runs on a stronger Claude model. The simple checks run on a cheaper one. The bill follows the risk instead of the volume.
No vector database
All 97 templates fit in a single prompt, about 4,800 tokens. The model sees every option every time, which beats retrieving the three that looked closest, and there's one less system to run.
It still works when the store doesn't
If WooCommerce is unreachable, it drafts anyway and flags what's missing, so the agent gets a head start instead of silence.
Built so the owner isn't stuck with me
Modular code, settings in configuration files, and boundaries the linter enforces, so the owner can maintain and extend it himself with Claude Code. He owns the code, the repository and the accounts it runs on.
What broke in seven months, and what I did about it
Twice. Neither was a bug in the code. Both were outside services, which is what usually stops an AI system once it's live.
First the AI account ran out of credit. Then the provider retired the model the system used. I fixed both, and each time left it harder to break again: errors now email the owner directly instead of sitting in a log, and the model name moved into configuration, so the next retirement is a settings change rather than a developer's afternoon.
This is the honest shape of running AI in a business. The build is the small part. Something outside your control will move, and what matters is how fast you find out and how cheap the fix is.
Where it stands
In production on a live support desk since February 2026, handling 500 to 1,000 tickets a month with a person approving every reply. In two systems for this client, the AI has never written a word that reached a customer.
The clearest verdict isn't a number: the same owner came back and hired me to build his customer-facing chatbot, which is now in his final testing.
There's no "saved 60% of support time" figure here, because the system doesn't record what the work took before, and I won't publish a number I can't show you the working for.
Fantastic provider - already working with him on another project. Great work, very high quality. Great communication and very helpful.
Technical details, for the engineer you'll ask about this
Node.js, TypeScript and Express. Anthropic Claude, Sonnet for the template decision and Haiku for the cheap checks. GrooveHQ API for tickets, WooCommerce REST API for orders. Zod for validating anything coming in, Winston for logs, Sentry for errors, Vitest with 339 tests, Docker, deployed on Railway inside the client's own account.
Module boundaries are enforced by the linter, and configuration lives in files rather than in code, so the owner can change how it behaves without touching the logic. All 97 templates go into a single prompt of about 4,800 tokens, so the model always sees every option. The rule that nothing can be sent to a customer is checked by a test that fails if any code path could send, rather than by a setting someone could switch.
Does your inbox look like this?
If your team answers the same questions with facts kept somewhere else, that gap is usually the thing worth automating first. Twenty minutes is enough to tell.
Top Rated Plus on Upwork (top 3%), 100% Job Success, 21 completed jobs.
Book a free 20-minute call (opens in a new tab)Or email hello@fahadsabzwari.com. I reply within 4 hours during US East and EU business hours.