27 July 2026 · Airtective Team
AI Chatbots for Ecommerce Customer Service
Most of Your Support Volume Is One Question
Across the ecommerce support inboxes we've worked in, the single biggest category by a wide margin is some version of "where is my order". Shipping status, tracking numbers, why it hasn't moved in three days, whether it'll arrive before the weekend.
Support people call it WISMO. It's mechanical, it's repetitive, and the answer already exists in your store's order record. Which makes it the best possible candidate for automation and the reason a chatbot can be genuinely worth it for an online store in a way it often isn't elsewhere.
The second and third categories are returns questions and product questions before purchase. Those are more nuanced, and one of them is a sales opportunity rather than a support cost.
Get those three right and you've covered the overwhelming majority of what hits your chat widget. Everything past that is a long tail you should route to a person rather than trying to cover.
What It Should Handle
Order status, with a real lookup. Not a canned "check your email for tracking". The bot pulls the actual order, reads the actual status, and tells the customer where the parcel is. This requires connecting to your store rather than just answering from a script, and it's the difference between a chatbot people use and one they abandon.
Returns eligibility. Is this order inside the window, is this item returnable, what's the process. The rules are usually written down and rarely ambiguous, so a bot can answer them accurately. What it should not do is approve the return. It explains the policy and starts the request. A person or a rule decides.
Pre-purchase product questions. Sizing, materials, compatibility, whether something's back in stock. This is the one that makes money rather than saving it, because a shopper who gets an answer in eight seconds at 10pm is a shopper who checks out. Worth pointing at your product data rather than a generic FAQ.
Handoff with context. When it can't answer, it passes the conversation to a human with the order already looked up and the question summarised. The customer shouldn't have to repeat themselves. This is the piece that separates a tolerable bot from an infuriating one.
Order status is also worth pushing out rather than waiting to be asked. If the status changes and the customer hears about it automatically, the question never gets asked at all. We've written up how to trigger those updates over WhatsApp the moment a status field changes, and it reduces WISMO volume more than any chatbot does.
The Identity Check Almost Everyone Skips
This one matters and it gets missed constantly.
If your bot looks up an order from an email address or an order number alone, then anyone who has either can retrieve someone else's order. Name, delivery address, what they bought, when they'll be home. We have seen live storefronts where typing a plausible order number returned a stranger's shipping address.
Order numbers on many platforms are sequential. Guessing them is trivial.
So the lookup needs two things that match before it returns anything: order number plus the email or postcode on the order, or a link sent to the email on file. It's a small amount of extra work at build time. Skipping it turns your support widget into a data leak, and depending on where your customers are, into a reportable one.
Buy a Platform or Build It
Both work. They fail differently.
Buying a chatbot platform gets you live quickly, usually with a Shopify or WooCommerce connector that handles order lookup out of the box. You get a dashboard, someone else maintains the integration, and there's a support line when it breaks. You pay monthly, often per resolution or per seat, and you're limited to what the platform decides to support. If your process has an unusual step, you'll be working around the product.
Building it means the flow matches how you actually operate, you own the logic, and the running cost is usually a fraction of a per-resolution price once volume is meaningful. It takes one to three weeks to get right, and somebody has to maintain it when your store changes.
The honest split we use: if your support volume is under a few hundred conversations a month and your process is standard, buy something. If you're past that, or your fulfilment has quirks a product won't accommodate, building pays back within months. We laid out what actually separates the AI support tools on the market if you're comparing options, and how to calculate the return before committing either way.
One thing to check whichever route you take: per-resolution pricing sounds cheap until you model it against a Black Friday week. Run your peak month through the pricing, not your average month.
What Breaks
The order lookup, when your data is messy. Guest checkouts with a different email than the account. Orders split across two shipments with two tracking numbers. Exchanges that create a new order referencing an old one. The bot handles the clean case fine and then gives a confidently wrong answer on the messy one. Test with your ugliest real orders, not with a test order you just created.
Peak season. Your volume triples in late November and the handoff queue overflows. If there's no fallback for "no human is available for two hours", the bot keeps promising someone will be right with them. Decide in advance what it says when the queue is genuinely swamped, and make it honest.
Channel drift. You add the bot to the website, then Instagram DMs, then WhatsApp. Three months later each channel is answering the returns question slightly differently because each one got configured separately. One source of truth for the answers, many channels reading from it.
Silent failure. Your store updates an API, the order lookup starts returning nothing, and the bot politely tells every customer it can't find their order. Nobody notices for a week because the bot never complains. This is the standard way these things die quietly, and catching that class of failure has to be part of the build.
What to Measure
Containment rate is the number platforms sell on, meaning the share of conversations resolved without a human. Watch it, but don't let it be the only number, because a bot can "contain" a conversation by wearing the customer down until they leave.
Better pair: containment alongside the rate at which customers come back with the same question within 48 hours. If containment is climbing and repeat contacts are climbing too, the bot isn't resolving anything. It's deflecting.
Also worth tracking the pre-purchase conversations that end in a checkout. That's the number that turns your support widget from a cost line into something you'd defend in a budget meeting.
The Messages Worth Sending Before Anyone Asks
A chatbot answers questions. The cheaper win is making sure fewer questions get asked.
Four post-purchase messages do most of that work. An order confirmation that actually says when to expect dispatch rather than just thanking them. A dispatch notice with the tracking link, sent the moment the label is created rather than in an overnight batch. A delivery confirmation. And a message when something goes wrong, meaning a delay, a split shipment, an out-of-stock line, sent before the customer discovers it themselves.
That last one is the one almost nobody builds and it's worth more than the other three combined. A customer told about a three-day delay is mildly annoyed. A customer who finds out by checking tracking on day four and seeing nothing has moved is the one who opens a chat, then emails, then leaves a review about it.
Once those are running, a review request fits naturally at the end of the sequence, timed off actual delivery rather than off the order date. Sending it while the parcel is still in transit is the classic mistake, and it's how you collect a two-star review about shipping speed. We've written about asking for reviews properly instead of buying them.
None of this needs AI. It's status changes triggering messages, which is exactly what the no-code tools are good at. Build these first, measure how much WISMO volume drops, and then decide how much chatbot you still need. Plenty of stores find the answer is less than they assumed.
A First Build That Doesn't Overreach
Week one, order status only, with the identity check in place. One question, done properly, tested against your genuinely messy orders rather than clean ones.
Week two, returns eligibility. Explains the policy, starts the request, approves nothing.
Week three, the handoff path. Make sure context carries across and that there's an honest message for when nobody's available.
Week four, product questions, pointed at real product data.
Leave it there for a month before adding anything else. If you're also getting ready to push more traffic at the store, the support side is only one of the pieces worth having running first, and we've listed the five automations to get in place before scaling ad spend.
For where a chatbot sits relative to the rest of your support workload, including the parts that shouldn't be automated at all, we've mapped out the four jobs AI genuinely handles well.
If you'd rather have someone look at your actual order data and support volume before you commit to a platform or a build, book a free 60-minute call. Bring your last month of chat transcripts if you have them. The category breakdown usually surprises people.
Related articles
27 July 2026
AI Email Customer Support: What to Automate
Email is the easiest support channel to automate badly. Here's what to draft, what to auto-send, and the mail loop that catches almost everyone out.
27 July 2026
AI for Customer Service: What Works for Small Teams
AI handles four jobs well in a small support team and gets unreliable past that. Here's what to automate, what to leave alone, and how to test it cheaply.