Customer service is a natural place for AI in ecommerce, because so many questions repeat. Where is my order? How do I return this? Does it come in blue? Do you ship to Canada? A person can answer each in seconds, but a store answering two hundred a week spends hours on questions whose answers sit in an order record or a policy page. A chatbot can answer those instantly, at any hour, and free the team for conversations that need judgment.
It can also go badly. A bot that invents a delivery date, refuses to let the customer reach a person or answers a refund question wrongly does more harm than no bot. This guide explains how to get the benefit without the damage: which questions to give it, what data it needs, how to design the hand-off, how to launch and how to measure. It is written for stores on any platform and for owners who are not technical. It follows from the support layer described in how to automate a Shopify store, and from the examples in AI in ecommerce: fifteen practical examples.
What a good ecommerce chatbot does
Today’s chatbots built on large language models understand free text and respond in natural language, which makes them far more flexible than the old menu-driven bots. Flexibility is also the danger: a model asked something it was not given can produce a plausible, wrong answer. The design goal is therefore to make the bot answer from your information, show where the answer came from and stop when it is unsure.
| Capability | What it needs | Example |
|---|---|---|
| Answer from policy | A current written policy for shipping, returns and warranties | How long do I have to return this? It quotes the window and links the policy |
| Look up an order | A secure connection to the order system and a way to verify the customer | Where is my order? It reads the tracking status and the expected date |
| Answer product questions | Complete product data and sizing guidance | Which size for a 175 cm customer? It uses the size chart |
| Collect details for a person | A defined hand-off with required fields | A damaged item claim gathers photos and the order number before handing over |
| Take simple actions | Clear rules and limits | Update an address before dispatch, within a set window |
Which questions to give it first
The best starting questions are frequent, factual and low risk. Read two weeks of your support inbox and tally the topics. In most stores a small number of topics make up most of the volume.
| Topic | Share of tickets (illustrative) | Good for a bot first? | Why |
|---|---|---|---|
| Where is my order | 30 percent | Yes | The answer is in the order and carrier data |
| Returns and exchanges | 20 percent | Yes, for policy and starting a return | Rules are written; the bot can start the process |
| Product and size questions | 15 percent | Yes, with good data | Answerable from specifications and guides |
| Shipping costs and countries | 10 percent | Yes | Rules and tables |
| Order changes | 8 percent | With limits | Possible before dispatch under clear rules |
| Damaged or wrong items | 7 percent | Collect details only | Needs a person to decide |
| Refund disputes and complaints | 5 percent | No | Needs judgment and tone |
| Other | 5 percent | No | Varied |
Illustrative shares. Use your own inbox to find your real mix.
If the first three topics cover half your tickets, you have a strong case for a narrow bot. The ones to leave with people are complaints, large refunds, legal threats, safety issues and anything involving vulnerable customers.
What data the bot needs
A bot is only as good as what it can read. Prepare these sources before you switch it on, and keep them current, because stale data is the commonest cause of wrong answers.
- Written policies: shipping, returns, warranty, payment and privacy, in short, plain paragraphs, with exceptions listed.
- Order data: status, items, tracking, delivery estimate and returns eligibility, from a secure, read-only connection.
- Product data: titles, specifications, sizing, materials, care and compatibility, complete and consistent.
- A glossary of your terms: names for sizes, colours and product lines, so the bot uses your words.
- A list of things it must never do or say: promise a delivery date it cannot guarantee, give medical or legal advice, discuss other customers.
Design the hand-off first
The most important screen in any chatbot is the one where it gives up gracefully. Customers forgive a bot that says it cannot help and brings in a person; they do not forgive one that loops or hides the human. Design the hand-off before you write a single answer.
- Always offer a way to reach a person, clearly visible, not hidden behind several failed attempts.
- Pass the context. The agent should see the whole conversation, the order and what the bot tried, so the customer does not repeat themselves.
- Say what happens next. Give an honest response time and a channel, such as email or live chat.
- Hand off on signals. Frustration, repeated questions, the words refund, fraud, injury or lawyer, and any request outside its remit.
- Handle out-of-hours. Take details and promise a reply, rather than pretending someone is there.
How to launch safely
Launch in stages, with a person watching, and treat the first month as a test of the instructions rather than of the technology.
- Collect real questions. Take a few hundred from your inbox and chat history, and note the correct answers.
- Write the instructions. Tone, boundaries, what it can do and when to hand off.
- Test against the real questions. Score each answer as correct, partly correct or wrong. Fix the instructions and data until the wrong rate is very low.
- Soft launch. Show the bot to a small share of visitors, or only on certain pages, with a person monitoring.
- Review conversations daily at first. Read a sample, tag errors and update the sources.
- Widen gradually. Add topics only when the earlier ones are solid.
Metrics that show whether it helps
| Metric | What it shows | Watch for |
|---|---|---|
| Resolution without a person | Share of conversations the customer considers solved | A rising share with stable ratings |
| Hand-off rate and quality | How often it escalates and whether the agent has what they need | Agents asking customers to repeat details |
| Customer rating | Satisfaction with the bot conversation | A gap between bot and human ratings |
| Wrong-answer rate | Answers a reviewer marks incorrect in a weekly sample | Any rise after a policy or catalogue change |
| Time to first response | Speed gain for customers | Fast but wrong is worse than slow |
| Tickets per hundred orders | Overall support load | A fall across the topics the bot covers |
A worked example of the numbers
Suppose a store receives 1,200 support conversations a month, and a person spends an average of five minutes on each, which is 100 hours. A bot covers three topics representing half the volume and resolves sixty percent of those without a person. That is 360 conversations handled automatically, a saving of 30 hours a month. If the owner values support time at twenty-five dollars an hour, that is $750 a month. The bot’s monthly usage cost might be a small fraction of that, so the main cost is the build and the review time. A build costing a few thousand dollars would pay back in several months on these assumptions, which is why it matters to choose topics with real volume and to measure the result. Our cost guide shows the method for comparing the figures.
Choosing between a platform bot, a plugin and a build
There are three routes to a chatbot, and the right one depends on how much your questions depend on your own data. A bot supplied by your helpdesk or store platform is quick to switch on and handles generic questions, but it may not read your live orders or follow your policies closely. A plugin sits in between: more control, more setup, and a monthly fee that grows with conversations. A built assistant is designed around your data and rules and is the most reliable for order questions, at the cost of an up-front fee.
| Route | Best for | Limits | Typical effort |
|---|---|---|---|
| Helpdesk or platform bot | Generic questions and quick starts | Weak on live order data and custom policy | Hours to days |
| Chatbot plugin or SaaS | Stores with moderate complexity | Monthly cost scales with volume; you configure and maintain it | Days to weeks |
| Built assistant | Order-heavy support, several systems, strict rules | Up-front fee, needs a clear scope | Weeks |
A useful test is to take ten real questions from your inbox and try them on a demo of each route. If the bot cannot answer the ones that depend on an order, it will not reduce your tickets, however polished the interface.
Tone, brand voice and honesty
The bot speaks for your brand, so its voice matters. Write three sample replies in your voice, covering a cheerful question, a frustrated one and a sensitive one, and give them to the builder as models. State the boundaries in plain words: it does not make promises about dates it cannot see, it does not discuss other customers, it does not give advice outside your products. A short disclosure line at the start of the chat, such as an introduction as the store’s assistant with a note that a person is available, sets honest expectations and has been shown to reduce frustration when the bot reaches its limits.
After hours, languages and peak periods
A chatbot’s clearest advantage is availability. At night and at weekends it can answer order and policy questions that would otherwise wait until Monday. Design for those hours deliberately: say when a person will reply, collect the details needed to act and send a confirmation by email. If you sell in several languages, test each one with native readers, because policy wording and product terms may not translate neatly. During peak periods, check that the bot handles bursts, that its connection to your order system respects rate limits and that the hand-off route to people is not overwhelmed.
- After hours: answer what you can, take details for the rest and promise a specific reply time.
- Languages: test each with a native reader and keep a glossary per language.
- Peak weeks: rehearse with a burst of test conversations and have extra people ready for hand-offs.
- Outages: if the order system is down, the bot should say so plainly and offer another route.
Security and customer data
To look up an order, a bot must be sure it is talking to the right customer. Use a verification step, such as an order number plus the email address, or a signed link from a logged-in account, before showing personal details. Give the bot read-only access wherever possible, log what it accessed and why, and keep conversation records only as long as you need them. Ask any vendor where conversations are stored, who can read them and whether they are used to train models, and get the answers in writing.
What it costs to run
Running a support assistant has three cost parts: the usage charge for the language model, which is usually small per conversation; the tools it connects to; and the review time of your team. In most small stores, review time is the largest ongoing cost during the first months and falls as trust builds. Budget a modest monthly allowance for monitoring, whether your own time or a care plan.
Mistakes that annoy customers
- Pretending to be a person. Say clearly that it is an assistant.
- Looping. If the bot cannot answer after two tries, hand off.
- Guessing. A wrong delivery date is worse than saying it will check.
- Stale policies. Update the sources whenever the policy changes.
- Ignoring privacy. Verify identity before sharing order details and do not store more than you need.
- No review. Without a weekly read of real conversations, errors accumulate unseen.
- Overreach. Refunds, exceptions and complaints belong with people.
If you want a chatbot built around your own policies and order data, with a defined hand-off, testing on your real questions and a handover, see our customer support chatbot service. For Shopify stores specifically, the AI Shopify chatbot page covers the platform connections. For the messages customers receive before they ever need to ask, see the post-purchase email flow.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Shopify Help Center: customer support, order and returns data available to support tools
- NIST: AI Risk Management Framework, general guidance on controlling AI systems
- FTC: business guidance on AI and chatbots, US guidance on honest claims and use of AI