Customer messages pile up faster than the team can answer them
You open the inbox in the morning and the unread count is already high. A few people asked whether an item is in stock. Several want to know where their order is. One asked about sizing at 11 pm, waited, and then wrote "never mind". Somewhere in the pile is a real complaint that should have gone to you first.
A slow reply rarely costs you the message. It costs you the buyer. Someone asking a question before checkout is close to buying, and they don't wait. If your answer takes six hours, they ask the next store in their search results, and that store answers in two minutes. You won't see this in a report. It shows up as chats that end with silence and carts that never turn into orders.
If this sounds familiar, the problem usually isn't effort. Your team is answering. It is answering the same things, by hand, in too many places.
Why it happens
The same questions, every day
Look at a week of messages and most of them repeat: shipping times, return windows, stock, sizing, ingredients, "is this the same as the other one". Each answer takes a minute, but the minutes add up across the day, and the person answering is often you.
Order lookups are done by hand
"Where is my order?" means someone opens WooCommerce or Shopify, searches by name or email, finds the order, copies the tracking number, opens the carrier page and writes back. It's simple work that takes a few minutes every single time.
Messages are spread across channels
Messenger, Instagram, WhatsApp, email and the chat widget on your site each have their own inbox. Nobody sees the full queue in one place, so some messages get two replies and others get none.
Nobody owns the inbox off-hours
Your customers are in other time zones, or they shop in the evening after work. If nobody is responsible for messages between 6 pm and 9 am, everything sent in those hours waits until morning, and so does the buyer.
Why a generic chatbot makes it worse
The usual first fix is a chatbot that came with the help desk or a plugin. It tends to fail in three ways:
- Wrong answers. It invents a return window or a shipping time because it was never given your real policies, or it guesses when it should say "let me check".
- No access to orders. It can't answer the most common question of all, so it sends a link to the tracking page and the customer writes again, now annoyed.
- No way out. The customer types "human" three times and gets the same menu. That conversation is now worse than no reply at all.
A bot that answers fast and wrong costs you more than a person who answers slowly and right.
What fixing it involves
The goal is an agent that handles the routine messages well, knows exactly where its limits are, and passes everything else to a person with enough context that the person doesn't have to ask again. Here is the order I work in.
1. Sort a sample of real messages into types
I export a few weeks of past conversations from every channel and sort them by type: pre-sale questions, order status, returns and exchanges, complaints, product problems, wholesale, spam. This tells you what the agent should handle, what it should never touch, and which answers your team keeps writing from memory because they aren't written down anywhere.
2. Decide what it may answer and what it must never do
We write the rules together, in plain language. A typical "never" list:
- No refunds, returns approvals or chargeback discussions.
- No medical, health or legal claims, even when a customer asks directly whether a product will help with a condition.
- No discounts or free shipping outside your published policy.
- No promises about delivery dates the carrier hasn't confirmed.
For each type of message the agent can't answer, the rule says what to collect and who it goes to.
3. Connect it to your catalog, policies and order data
An agent is only as good as what it can look up. I connect it to your product catalog (stock, variants, descriptions), your written policies and your order data, so "where is my order" gets a real answer with the real tracking number. With Claude, this access is set up through MCP servers: small, controlled connections that let the agent read the data it needs and nothing else. Where several systems have to talk to each other, such as the help desk, the store and a spreadsheet, I use n8n for the plumbing.
4. Let it place orders only as pending
If customers order through chat, the agent can take the order details and create the order with a pending status. A person checks it and confirms it before anything ships or gets charged. The agent saves the typing and your staff keep the final say.
5. Build a clean hand-off
When the agent reaches a limit, or the customer asks for a person, it says so plainly, opens a ticket and attaches a short summary: who the customer is, the order number, what they want, and what the agent already told them. Your staff pick it up without scrolling back through the chat, and the customer doesn't have to repeat themselves.
6. Test against real past messages before customers see it
Before launch, I run the agent against a set of real past conversations and compare its answers with what a good staff reply would have been. Every wrong answer, made-up fact or missed hand-off gets fixed in the rules or the data, and then I run the set again. Customers see it only after it passes.
7. Review mistakes every week for the first month
Live customers will ask things the test set didn't cover. For the first month I read through a sample of conversations each week, flag every mistake and fix the cause. Most fixes end up being a missing policy line or a product detail nobody wrote down.
8. Measure what changed
Three numbers tell you whether it worked:
- First response time: how long a customer waits for the first useful reply, across all channels.
- Share of chats handled: how many conversations the agent closes without a hand-off.
- Hours saved: time your team no longer spends on lookups and repeat answers.
I record these before the agent goes live so the comparison is honest. If you want the wider picture of what I build in this area, see AI automation & agents.