Ecommerce chatbots

An ecommerce chatbot is an automated conversational interface that handles customer questions on a store's site or messaging channels. In post-purchase use the questions are dominated by order status, returns, and refunds, which are answerable from data rather than from language. That makes the useful evaluation criteria different from general chatbot criteria: what the bot can see, and what it can do, matter more than how naturally it writes. There is also a disclosure question that is now settled law in some markets, since the EU AI Act requires a person to be told they are interacting with a machine, and a brand selling into Europe inherits that whatever its own policy says.

What an AI chatbot for customer service is

An AI chatbot for customer service is software that answers customer questions in chat, email or messaging without a human agent, using a language model to compose replies from the sources it is connected to. The most capable read live order data and can take a simple action, such as changing an address.

Most support bots run the same loop on every message. They classify the intent (order status, return, refund timing, a product question), identify the shopper and the order, pull the answer from an approved policy or a live order record, then reply, take a permitted action or hand the conversation to an agent with the context attached. Each step fails in its own way. A wrong intent produces a confident answer to the wrong question. A failed order match makes the shopper repeat themselves. A stale record tells the shopper a refund is on its way after the payment provider rejected it. The sections below take those steps in order.

My view on where a bot fits: when a shopper asks where an order is, the question usually exists because the order is late or silent, which means a promise already slipped before the chat opened. A bot is the right tool for the questions where nothing went wrong, and we integrate with Gorgias and Zendesk so those get answered fast. Keeyu is not a chatbot. It finds the order problem in real time and fixes it before the shopper knows, which is proactive e-commerce operations. Every order is a promise. Keeyu keeps it.

Deflection has a ceiling, and the ceiling is the interesting part

Deflection is the primary business case. Order-status questions are high volume, repetitive, and deterministic, which makes them the natural first target, followed by returns initiation and policy questions such as delivery windows and refund timing. The wider deflection layer is customer self-service and the option-by-option catalog is self-service options. The metric is contacts resolved without an agent, tracked alongside the escalation rate and, critically, the reopen rate, since a bot that closes conversations without resolving them shows excellent deflection and produces repeat contact. Deflection has a structural ceiling: it removes the contacts where nothing is wrong.

Two years ago the whole industry agreed that chatbots were the future of customer experience. Faster deflection, smarter responses, better bots. We took the other side of that, and the reason is the ceiling named above. Deflecting a contact gets rid of the customer more quickly. It does not do anything about the reason they got in touch. For the questions where nothing is wrong that is a genuinely good outcome and worth building. For the rest, a deflected customer is a customer whose problem is still sitting in your warehouse. The queue that inherits those is the automated ticketing system.

When someone clicks the buy button, none of us is opting in to call the brand later and say: fix the problem you created for me, and now you are making me work for you. That is the ceiling, and it is visible in our data. Across the 786 pain points we mined from 270 customer call transcripts between May 2025 and May 2026, returns were the highest-volume category after WISMO, one brand took 400 'how do I return this' tickets a month with a returns portal already live, and 'where is my refund' tickets clustered at the nine-day mark, the point where the gap between the warehouse and the refund becomes visible to the customer. None of those is a conversation a bot can close, because the answer the customer needs is a label that generates or a refund that lands.

What the bot can see decides what it can say

A bot's usefulness is bounded by its data access. The connections that matter are the storefront for order and customer records, the fulfillment system or third-party logistics provider for dispatch state, carriers for tracking events, the returns platform, and the payment provider for refund status. Carrier data arrives as scans rather than as answers, which the USPS Track and Confirm API shows plainly, and joining all five is third-party integrations work. Without them the bot can answer policy questions but not order questions, which is the volume. Two behaviors are worth testing directly during evaluation: how the bot identifies which order a customer means without asking, and what it says about an order in an unusual state, such as a partial shipment or a parcel that has not moved.

The way I put it: a helpdesk cannot prevent a ticket or a complaint, the same way a hospital ER cannot prevent a heart attack. It can only triage the symptom, not prevent the cause. A chatbot on top of it has the same limit, because it cannot solve the root cause when it has no visibility into the operation, and the difference shows up entirely in what it is connected to. A conversational layer with no order access is a well-written apology generator. The same layer wired into fulfillment, carriers, returns and payments can tell a customer something true. Wired in and given permission to act, it does not need to tell them anything, which is what proactive e-commerce operations means in practice. It is why we link to the customer promise, the order, instead of linking to a ticket. Deciding what it may do unattended is a scoping question rather than a modeling one, and the NIST AI Risk Management Framework is the standard place to start on it.

Brands feel that limit already. On a Retail Fest 2026 panel I said: "brands are getting burnt with ... reactive AI. Reactive AI is chat bots ... when we reach out ... they go, I've got a help desk chatbot. And we're like, well, no, that's frustrating your customer because it ... triage ... and then kick up to a human agent."

Hand-off quality decides whether automation helps or hurts

Hand-off quality determines whether automation improves or degrades the experience. The requirements are that the customer is not asked to repeat what they have already said, that the agent receives the full conversation and the order context, and that the route to a human is visible rather than hidden. Escalation triggers should include explicit customer request, repeated failure to resolve, and objective severity signals such as a breached delivery promise or high order value, rather than sentiment alone. The helpdesk receiving the hand-off has to carry that context or the customer starts again.

Getting AI to know when to step back is the underrated part of this, and it is hard to execute. Optimizing for a good experience over a raw deflection number feels obvious, but it is clearly not the norm. A clean hand-off is worth more than a higher deflection rate.

Pre-purchase questions are a separate job

Pre-purchase chatbots answer sizing, product-fit and promotion questions and try to recover abandoned carts, so they are judged on assisted conversion rate. Post-purchase bots are judged on whether the order question went away.

Before buying one bot for both jobs, split a month of tickets by whether the shopper had already paid. The pre-purchase share is the bot's sales job. The post-purchase share is mostly order questions, and each one that operations prevents frees agent time for the conversations that sell. Keeyu works on the second share only, from payment through delivery and return, which is why the rest of this page stays there.

Guardrails: the brand owns every answer the bot gives

A chatbot guardrail is a rule that limits what a bot may say or promise, so answers stay inside approved policy and true order data. In February 2024 a British Columbia tribunal ordered Air Canada to pay a passenger C$812.02 after its chatbot wrongly told him he could claim a bereavement fare after travel. The tribunal's words, as the BBC reported: "It makes no difference whether the information comes from a static page or a chatbot."

Four rules follow:

• Policy answers quote one approved, versioned source.
• Order facts come only from live systems; a failed lookup means hand off.
• The bot never promises a refund, credit or date it cannot execute.
• Every answer is logged with its sources.

We are starting to see a trend in the brands we talk to, a few in the USA in particular, saying they do not want AI interacting with their customers. That concern is understandable, and it is the reason the second rule is the one to hold a post-purchase bot to hardest. A policy answer can be checked once and versioned. An order answer is only as true as the last scan, so a bot quoting stale carrier data will tell a shopper a parcel is moving when it stopped days ago, and that is a promise made on your behalf that the shopper will hold you to. The durable fix is upstream: an order exception caught in operations becomes a true fact the bot can quote.

It changed how we describe Keeyu. In a LinkedIn comment I wrote: "we took AI out of our pitches, and just say: 'Keeyu is a system of action' vs. 'Keeyu is an AI-powered platform'".

The math: deflection, net resolution and the preventable ceiling

Deflection rate is the share of contacts a chatbot closes without an agent; net resolution rate is the share that stays closed. Vendors usually report the first, so a business case needs the second and two more formulas:

• Deflection rate = contacts closed with no agent touch / contacts the bot received.
• Net resolution rate = (bot-closed contacts minus those reopened within 7 days) / contacts the bot received.
• Cost per bot resolution = (bot fees + agent cost of handling reopened contacts) / net resolved contacts. Set it beside your agent cost per contact.
• Preventable share = contacts caused by an order failure (late, stuck, lost, refund not landed) / all contacts.

An illustrative example, not a Keeyu result: of 1,000 monthly contacts the bot closes 700 (70% deflection), but 200 reopen within a week, so net resolution is 50%. If 600 of the 1,000 started with an order failure, the bot makes those cheaper to handle. Only fixing the failure upstream removes them.

A useful test for any bot business case is the preventable share. If more than half of contacts start with an order failure, the bot's best case is a cheaper version of the same contact. When ticket volume spikes, the reflex is to hire more agents, and I think that is the wrong response, because you are hiring humans to do work systems should do.

The cost most bot business cases miss is peak headcount. We were on a call with a brand that runs 20 support staff all year and scales to 40 for two months of peak. Measure the cause as well as the reaction: tickets prevented is the number that moves the seasonal hire.

Chatbot vendors price per automated resolution, per bundle of automated interactions, or per tier. Read the vendor's definition of a resolution before you compare. Under the billing platform Zendesk documents as in place before its resolution tiers, a messaging conversation was evaluated as an automated resolution 2 hours after the first message by default, so a shopper who writes back on day three may already be a billed resolution. Count your own 7-day net resolution beside the invoice. Keeyu is priced by monthly order volume, not per seat; see the pricing page.

A scorecard and a pilot with a go/no-go rule

An AI chatbot scorecard is a fixed set of tests run on your own orders, each with a pass condition, so vendors are compared on the same evidence. Run it on your orders, not the vendor's demo script.

Pilot two intents, order status and policy, in two stages. Stage one is two weeks in shadow mode (the bot drafts, an agent sends): read 50 sampled drafts a week against the scorecard and track the share an agent sends unedited and any invented policy. Stage two routes a small slice of live traffic, such as 10%, to the bot for two weeks so reopens can be counted. Add two triggers to the escalation list from the hand-off section above: chargeback or dispute language, and any refund above an agent's approval limit. Keep a kill switch any agent can flip. Go/no-go rule: an intent goes fully live only when shadow mode showed zero invented policy and the live slice shows net resolution above your agents' first-contact resolution on that intent. Otherwise fix the data, not the prompt.

When the bot can only describe the order, the work of fixing it still lands on an agent. What changes when software is allowed to act is covered under operational AI agent. Detect. Decide. Act. Keeyu gets shoppers what they want, on time, as promised. Every order is a promise. Keeyu keeps it.

Report on the contacts, not the bot

The analytics worth having are about the contacts, not the bot. Intent distribution shows what customers are asking. Unresolved-intent reporting shows what the bot could not handle. Escalation reason reporting shows why humans were needed. Read against order data, these identify the operational failures generating contact, which is a more valuable output than containment rate. The measures that describe those failures are ecommerce KPIs and resolution time. The common gap is that most chatbot reporting is oriented to proving the bot's performance rather than to diagnosing the business's.

The best support is the message before the question

The final capability is outbound rather than inbound: messaging a customer before they ask, triggered by an order event such as a delay, a stalled shipment, or a stock problem. This inverts the model, since the contact never becomes a conversation. It requires the same operational data integrations as the inbound case plus a trigger layer that watches order state continuously. The message set it fires is shipping notifications and the operating model is proactive customer service. It is the capability that most distinguishes vendors in this category, and the one least well covered by chatbot-first tools, because it depends on operations data rather than conversational ability.

Carriers will always drop the ball, so the question I ask is who tells the customer first. Every time a shopper has to go and find something out, you have already added friction. Brands cannot control carriers. They can control communication. Watching order state continuously is a different engineering problem from answering a message, and it is why the tools that started as conversation are weakest here. The best support is the call the customer never has to make. A bot that answers a delay question perfectly has still let the customer find out about the delay on their own, and the same integrations that let it answer would have let something act four days earlier. Every order is a promise. Keeyu keeps it. A bot that explains a broken one beautifully has still let it break. That is post-purchase operations rather than a better conversation.

• Publications Office of the European Union. EU AI Act. The disclosure obligation a brand selling into Europe inherits.
• United States Postal Service. USPS Track and Confirm API. Carrier data arriving as scans rather than as answers.
• US National Institute of Standards and Technology. NIST AI Risk Management Framework. Scoping what a connected assistant may do unattended.
• BBC. Airline held liable for its chatbot giving passenger bad advice - what this means for travellers. The tribunal ruling that a brand is responsible for what its chatbot says, and the C$812.02 award. Read 2026-10-01.
• Zendesk. About the automated resolutions platform (prior to resolution tiers). How a messaging conversation is evaluated as an automated resolution (2 hours after the first message by default). Read 2026-10-01.