AI Chatbot for Ecommerce Stores

The questions that fill an online store’s inbox

Before anyone writes a line of chatbot configuration, it helps to sort what shoppers actually send. In an online store the list is short and brutally repetitive, and the questions fall at predictable points in the order’s life.

• Before buying: Will this fit me? Does it work with the model I own? What is it made of? How long does shipping take to my ZIP code? Is there a discount running? Will the sold-out color come back?
• Between checkout and delivery: Where is my order? Can I change the shipping address? Can I add something before it ships? Can I cancel?
• After the box arrives: How do I return this? Can I exchange for a different size? It arrived damaged. Tracking says delivered but nothing is on my porch. One item is missing.
• Account and subscription: I cannot log in. How do I skip next month’s shipment? How do I cancel my subscription?

Each of those needs one of three kinds of answer. Some are static: the return window, shipping zones and materials never change between shoppers. Some are live lookups: order status, stock level and tracking events depend on data that changes by the hour. The rest need judgment: a damaged item, a late refund, a shopper threatening a chargeback. A useful ecommerce chatbot is designed around that split. It answers the static questions from approved text, answers the live ones by querying your systems, and routes the judgment calls to a person instead of improvising.

Stores that skip this sorting step usually end up with a bot that is confident about everything, which is the worst possible trait in a support channel that touches money and personal addresses.

Order lookups that don’t leak customer data

Order status is the question most worth automating, and also the one most likely to go wrong. Here is how a lookup works in a build we would sign off on.

1. The shopper asks where their order is. If they are signed in to your store, the bot already knows who they are from the session. If not, it asks for the order number plus a second identifier, typically the email address on the order or the billing ZIP code.
2. The bot queries your store platform’s order API with read-only credentials and checks that both identifiers match the same order.
3. It reads the fulfillment status and, where a tracking number exists, the latest carrier event.
4. It replies in plain language: which items shipped, with which carrier, the most recent scan, and a tracking link. Items still waiting to ship are called out separately so a split shipment does not look like a lost one.

What the bot does not show matters as much. It never displays a full street address, phone number or payment details, even to a verified shopper; a masked city and state is enough to confirm the right order. It never answers a lookup based on an order number alone, because on many platforms order numbers are sequential and trivially guessable, which turns a friendly chatbot into a tool for reading other people’s purchases.

When tracking says delivered and the porch is empty

This conversation goes badly when a bot argues with the carrier scan. Instead, it follows whatever your policy says: suggest checking with neighbors or the building’s package room, wait the period you specify, and then open a claim ticket in your helpdesk with the order, tracking history and the shopper’s description attached. Your agent picks it up without asking a single repeat question.

Grounding product answers in your catalog, not the model’s memory

Pre-purchase questions are where a chatbot earns revenue, and where a wrong answer quietly creates a return later. A language model has read millions of product pages that are not yours, so left unsupervised it will happily describe a fabric blend, a battery life or a compatibility claim that your listing never made.

We ground product answers in your own catalog data: titles, descriptions, variant attributes such as size, color and material, custom fields or metafields, size charts, compatibility tables and live inventory. The bot is instructed to answer only from those sources and to say plainly when the data does not cover a question.

Take a shopper who asks whether a phone case fits a model released several years ago. If your compatibility table lists that model, the bot says yes and links the right variant. If the table is silent, the bot says it cannot confirm the fit, shows the models that are listed, and offers to pass the question to your team. That small refusal is worth more than a confident guess that comes back in the mail.

Sizing, stock and discount codes

• Sizing: the bot can walk a shopper through your size chart using measurements they provide. It should not recommend a size from height and weight unless you publish that guidance yourself.
• Out of stock: rather than promising a restock date nobody knows, the bot offers a back-in-stock alert through your email or SMS tool, with the shopper’s consent captured properly.
• Discounts: the bot shares only promotions you have marked as public and current. It cannot invent a code, stack codes, or waive an exclusion, no matter how politely it is asked. Shoppers do test this, so we test it too.

Catalog data also goes stale. When you discontinue a product or change a material, the sync has to pick it up. We agree a refresh schedule with you and flag products the bot keeps being asked about that have thin descriptions, because those listings are usually underperforming on the storefront as well.

Returns, exchanges and the point where the bot stops

A return policy is part rules and part judgment. The rules are easy to automate: the window, the condition requirements, final-sale categories, who pays return shipping. The judgment is where a store protects its margin and its reputation, and that part stays with people.

Our standing recommendation is that a bot does not issue refunds or store credit on its own at launch. It can prepare everything so the approval takes your agent seconds, and once you have watched it handle a few hundred cases correctly, you can decide whether narrow, low-value refunds should become automatic. Moving in that order keeps a configuration mistake from becoming a financial one.

Which parts of your stack the chatbot talks to

Most online stores run on a platform plus a ring of apps. The chatbot’s usefulness is set almost entirely by which of those it can read from and, later, write to.

We start every integration with read-only permissions. Order cancellation, address edits and other write actions come later, one at a time, each with a rule about when the bot may attempt it. An address change, for instance, is only offered while the order is still unfulfilled, and the bot tells the shopper it has requested the change rather than claiming it is done, because a warehouse may already be packing the box.

Stores that also sell on Amazon, eBay or Etsy should know that marketplace orders live under the marketplace’s own messaging rules. A website chatbot generally should not try to answer those; it recognizes a marketplace order and tells the shopper where to reach you for it.

If your store is purely on Shopify, the Shopify-specific chatbot page goes deeper into that platform’s apps and admin. If a system you rely on has no usable API, our AI integration and custom software teams can build the connector instead of forcing a workaround.

Nights, weekends and holiday peaks

Shoppers browse late at night and on Sunday afternoons, which is exactly when a small support team is offline. Out of hours, the bot keeps answering everything it can answer from data and policy. For requests that need a person, it creates the ticket with full context and tells the shopper your actual support hours, instead of implying someone is about to reply.

Seasonal peaks bring their own questions. Holiday shipping cutoffs are the classic one: the bot has to know your published cutoff dates for each shipping method, and those dates need to live in one place you can edit, not scattered through prompt text. The same goes for sale-specific rules, such as items becoming final sale during a promotion, and for carrier delays you want to acknowledge up front. We give you a simple way to post a temporary notice that the bot will mention when it is relevant.

A mistake we design against: a customer asks at midnight to change an address, and a poorly built bot replies that it has been updated when it has only filed a request. By morning the order has shipped to the old address. The honest wording, plus an urgent flag on the ticket, costs nothing and prevents that entire mess.

Measuring it honestly: resolved, not just deflected

Many chatbot dashboards lead with deflection, the share of conversations that never reached a human. The number flatters the bot, because a shopper who gives up in frustration also counts as deflected. We prefer measures that separate help from abandonment:

• Conversations where the shopper confirmed the answer helped, or did not contact you again about the same order.
• Handoffs that arrived with complete context, so your agent did not have to re-ask for the order number.
• Handoff rate by topic, which shows where the bot needs better data or a new rule.
• For pre-purchase chats, whether the conversation was followed by an order in the same session.
• The unanswered-questions log, which is often the most direct list of gaps in your product pages.

We review a sample of real transcripts with you after launch. Reading twenty conversations tells you more about how the bot represents your brand than any single percentage.

How EVOTECH builds an ecommerce chatbot, step by step

1. Free consultation. A phone or video call about your platform, apps, support team size and the questions that take the most time.
2. Ticket review. You export a recent sample of support tickets, with personal details removed, and we rank the question types by volume and by how automatable each one really is.
3. Fixed-scope written quote. It lists each integration, each action the bot may take and each handoff path, so you know exactly what is and is not included.
4. Build. Policy knowledge base, catalog sync, verified order lookup, helpdesk handoff and the tone guidelines for your brand.
5. Adversarial testing. Real historical questions plus the ones people use to break bots: fishing for discount codes, asking about someone else’s order, demanding a refund in capital letters.
6. Read-only launch, followed by write actions added one at a time as you gain confidence.
7. Tuning. Transcript reviews, catalog fixes and new rules based on what shoppers actually asked.

EVOTECH IT LLC is a US-based team in the Houston area that has been in business for more than twenty years and delivers this work remotely to stores anywhere in the United States. We are rated 5.0 on Google. If you want to see the broader picture first, our AI chatbots overview covers the general approach and AI agents explains when a bot should take actions rather than just answer.

Related services

Frequently asked questions