An ecommerce chatbot is only useful if it can answer the two questions a shop actually receives: the pre-purchase questions a product page already answers (size, fit, stock, dispatch), and the post-purchase questions that need the order record (where is it, when does it arrive, how do I return it). One list is solved by reading your own pages. The other is solved by reading your own database. Most shops mix the two up and then wonder why it never works.
The cost question is simple once you stop counting chats and start counting messages. A chat is typically 4 to 6 messages, and Asyntai's published plans are written in messages per month, not in conversations.
An online shop is not a generic website. A visitor does not arrive curious. They arrive with a wallet open or a receipt in their hand, and they want one of five answers. The work of building a chatbot for ecommerce is not choosing a vendor. It is recognising which of those five answers can be given instantly from something the shop already publishes, and which one needs a live connection to a system the shop already runs.
The five questions an ecommerce visitor actually asks
Sit with your inbox for an hour and these five cover most of what arrives. The list is short on purpose. If a question is not one of these, it is unusual enough to deserve a human reply.
- Does it fit? Sizing charts, measurements, model-specific notes (a model runs small, a fabric does not stretch).
- Is it in stock, and in my size? Live availability by SKU, including the size or colour currently selected.
- When will it arrive, and how much is shipping? Cut-off times, dispatch windows, carrier options, customs for cross-border.
- Where is my order? Tracking link, current status, what to do if the tracking has not updated.
- Can I return it, and how? Window, condition, label, refund timing, who pays postage.
Each one is answerable. None of them requires a human to type a custom sentence. What makes a shop hard is that the answer to question 4 lives in a different system from the answer to question 1, and a chatbot that only knows your product pages will silently fail on every order-status question, which is the one that arrives most often.
The split that decides whether the thing is useful
This is the split most shops get wrong. Pre-purchase questions are answered from the shop's own content, which is already on the website and just needs to be reachable. Post-purchase questions are answered from the shop's own records, which live in the order management system, the carrier feed or the returns database, and need to be connected before any answer can be given.
| Question | Source of truth | Pre or post-purchase | What has to be connected |
|---|---|---|---|
| Does it fit? | Product page, sizing guide, model-specific notes | Pre | The product page itself, including any sub-page that holds fit details |
| Is it in stock? | Inventory feed, by SKU and variant | Pre | A live inventory lookup, so the answer is not stale |
| When does it arrive? | Shipping policy, cut-off times, carrier options | Pre | The shipping policy page, with any per-region note |
| Where is my order? | Order record, tracking events from the carrier | Post | The order management system, with order number or email lookup |
| Can I return it? | Returns policy, return portal, condition rules | Post | The returns policy page, with the actual return portal link |
No vendor comparison here. The table is the structure of the problem, and the structure is the same for every shop. The decisions sit in two places: which content pages are reachable, and which systems are connected.
A chatbot that handles the top three rows but not the bottom two will leave the most common question (where is my order) unanswered, which is worse than having no chatbot at all. A chatbot that handles the bottom two but not the top three will feel slow on the browsing questions that arrive twenty times a day. The useful version does both, and does not pretend the second group is solvable by reading the website.
Pre-purchase: answering from pages you already publish
The pre-purchase questions have a single pattern. The visitor is on (or near) a product page, and the answer already exists somewhere in the shop. The job is retrieval, not generation.
Fit and sizing lives on the product page itself, on a sizing chart sub-page, and sometimes in a model-specific note buried in the description. A visitor who asks about fit is asking about the specific product they are looking at right now, which means the chatbot needs to know which product the conversation is about. If the chat widget is on the product page, the URL gives that away. If it floats on every page, the visitor has to be asked, which costs a message before the answer arrives.
Stock and availability is the only pre-purchase question that decays. A page that says "in stock" at 9am is a lie by 2pm if the SKU has sold out. The answer has to come from a live inventory feed, not from a cached copy of the product page. Anything else, and the chatbot is the source of the next complaint.
Dispatch and shipping is the question that creates the most tickets in the run-up to Christmas, and the answer is almost entirely on the shipping policy page: cut-off times for same-day dispatch, carrier options, customs duties for international orders, free-shipping thresholds. None of this needs an order record. It needs the right page to be findable.
Post-purchase: answering from the order record
The post-purchase questions have a different shape. The visitor has already paid, and they want information that only the shop's own systems hold. Asking the chatbot for this information without that connection is the mistake most shops make, because it looks, in a demo, like it works.
Where is my order needs three pieces: an order number (or an email address to look it up by), a current status from the order management system, and a tracking link from the carrier if one has been generated. The chatbot should not invent any of these. If the order number is wrong, or the system has no record, it should say so plainly and route to a human, not invent a status.
Can I return it needs the returns policy (window, condition, who pays return postage), the link to the returns portal, and an order-specific check (has the window closed, is the item marked final sale). The first two are content. The third is a lookup. Without the lookup, the chatbot will tell a customer they have 30 days when they have 3.
How a visitor conversation actually goes
Here is what a working exchange looks like, step by step. The conversation has eight messages: the greeting, the question, the answer, a follow-up question, the second answer, an order-status question, an email lookup, and a tracking link. A single chat, eight messages.
The arithmetic matters because the published plans are written in messages, not in chats. A shop that estimates "we'll get 200 chats a month" and buys a plan that covers 200 chats is buying a fifth of what it needs.
A worked example using the published Asyntai plans
Assume a small shop handles 500 chats a month, split roughly half pre-purchase and half post-purchase. At an average of 5 messages per chat, the message volume looks like this:
2,500 messages fits exactly on the Starter plan at $39, which covers 2,500 messages per month. A shop above that line, or one expecting a seasonal spike, steps up to the Standard plan, which covers 15,000 messages at $139 per month and holds the workload with headroom for a Black Friday week.
That is the cost at full use. The real cost per chat is higher in months where the allowance is not used, and lower in months where it is. The plan is sized to the chat volume and the average length, and both are inputs the shop can measure on its own site today.
At 3,000 chats a month the shop is handling roughly 100 conversations a day, which is a busy single-operator workload if every chat went to a human, and almost nothing if most are answered automatically from the shop's own pages and records.
What changes the answer
Three numbers move the plan choice more than any feature comparison.
Average messages per chat. The longer the conversation, the more messages it uses. A shop that adds a "find my size" quiz in the chat will push the average from 5 messages to 8 or more, which doubles the plan allowance needed for the same chat count.
Pre-purchase versus post-purchase mix. Pre-purchase chats are usually shorter, because the visitor has the product page open in another tab and is asking one or two pointed questions. Post-purchase chats are longer, because the visitor is anxious and asks for confirmation, then asks again. A returns-heavy period will use more messages per chat than a sale-heavy one.
Seasonality. Most shops see a November-to-December spike that is several times the baseline. The plan needs to cover the spike, not the average, because running out of messages in week two of December is the worst possible time. If the peak month is three times the average, the plan should be sized to the peak.
The mistake most shops make, and what it costs
The single most common error is launching a chatbot that can answer pre-purchase questions only, because that is the easy half. The visitor asks "is this in stock in a medium" and gets a confident answer. The visitor then asks "where is my order from last week" and gets a confused non-answer or a hallucination, because the chatbot has no order system connected.
What this costs is the trust the chatbot just built. A confident wrong answer on a post-purchase question is worse than a polite "let me get someone to help with that", because the visitor has already seen how capable the thing looks, and the failure reads as competence undermined by laziness. The shop is then worse off than if it had never installed the widget.
The fix is to decide, before launch, which post-purchase questions will be answered by the chatbot and which will be routed to a human. The answer depends on which systems are connected, and the systems that need connecting are the order management system and the carrier feed. Without those, the post-purchase half of the shop should not pretend to be automated.
What to measure on your own site before choosing a plan
Two numbers will tell you almost everything you need. Both are checkable today, before any vendor decision.
Chats per month at peak. Pull the contact form submissions, the live-chat sessions, and the email volume that is answerable from your published pages. Add them up for your busiest month. That is the floor for what an automated assistant would handle, before any deflection gain.
Average messages per conversation. Open twenty recent chats from a busy week and count the messages in each one. The average is your conversion factor from chats to messages, and the high ones (eight messages and above) tell you which conversations are the expensive ones.
Multiply the two. The product is the monthly message allowance you need, with no headroom. Add 50% for the spike, then choose the plan above that number. The arithmetic is yours to do, and it is the part of the decision that does not depend on any vendor's marketing.
Connecting the systems before turning the chatbot on
A chatbot that goes live before the connections are in place will be the source of the problems it was meant to solve. The connection list is short and each one is a discrete piece of work.
Product catalog and inventory. Live stock by SKU and variant. A nightly scrape is not enough on a fast-moving shop; the answer to "is this in my size" needs to be true at the moment it is given.
Order management. An order lookup by order number or by email address, returning current status, items, and the dispatch date. This is the connection that makes the post-purchase half work, and it is the one most often skipped.
Carrier feed. Tracking events from the carrier, attached to the order record. Without this, "where is it" can only say "dispatched" and never "out for delivery".
Returns portal link. The actual URL of the returns portal, with any per-order eligibility check. The chatbot should hand the visitor the link, not paraphrase the policy.
Each connection is a job that takes longer than the chatbot install itself, which is why shops that start with the chatbot and add the connections later get the worst of both worlds: a confident widget that does not know the order has shipped.
When the chatbot should not answer at all
There are questions a chatbot should refuse, and the list is shorter than most teams think.
Damaged or missing items. These need a human, because they need a photograph, a decision, and a resolution the chatbot cannot make. The right behaviour is to acknowledge the problem, collect the order number and a description, and route to a named person.
Refund disputes. If the customer is contesting a refund decision, the chatbot is the wrong audience. Hand it off with the case reference attached.
Customisation requests. Bespoke orders, gift messages, special delivery instructions. The shop needs to capture these in a structured way, not in chat, and a human entry is faster than an AI guessing at the format.
Anything involving a child. Some ecommerce categories sell to or near minors. The chatbot should recognise this and route to a human, both for compliance and because the answers needed are not on a product page.
A chatbot that knows what to refuse is more useful than one that tries to answer everything. The refusals are where the trust is built, because they show the visitor where the boundary is.
The full picture, in one place
An ecommerce chatbot is a retrieval layer over two things: the pages the shop already publishes, and the records the shop already keeps. The five questions that arrive on the site are answerable from those two sources, and a chatbot that handles all five will deflect the majority of incoming contacts on a small or mid-sized shop.
The cost question, once chats are converted to messages, is straightforward. The published plans for Asyntai run from a free tier at 100 messages through to a Pro plan at 50,000 messages, with self-serve tiers at $39, $139 and $449 per month, and a separate enterprise contract for larger volumes. A shop that measures its own chat volume and average message length can pick the right tier without trusting any vendor's headline number.
The order of operations is the part most shops get wrong. Connect the inventory, the order system and the carrier feed before turning the chatbot on. Decide which post-purchase questions will be automated and which will be routed to a human. Then size the plan to the peak month, not the average. The technology is the easy half. The plumbing is what makes it work.
Where an ecommerce chatbot fits in your customer service stack
A chatbot is one channel among several, not a replacement for the rest. The question is where it sits, and the answer is upstream of the human team: it absorbs the questions a human would otherwise answer from the website, and hands off the ones it cannot answer. Treated as the front door of customer service rather than a standalone widget, the chatbot stops competing with the email inbox and starts feeding it the conversations that actually need a person.
Most ecommerce shops run three layers: a published help center or FAQ for the questions the visitor can answer themselves, a chat or contact form for the questions that need a reply, and an email or phone path for the questions that need a decision. The chatbot fits between the first and the second. It is not the help center, because the help center does not know who is asking. It is not the inbox, because the inbox does not know the order. It is the layer that reads both and decides which question goes where.
This is also why the connect-the-systems work has to happen first. A chatbot that lives in front of the inbox but cannot see the orders will route order-status questions to the inbox in volume, which is exactly the volume the inbox was struggling with before the chatbot was installed. The chatbot has to be able to answer a meaningful share of the questions it receives, or it just adds a hop on the way to the human team.
Once the connections are in place and the chatbot is answering both halves, the inbox changes shape. The remaining tickets are the ones that need a judgement: the damaged parcel, the refund dispute, the gift wrap request. Those are the conversations a human team is good at, and they are the conversations worth paying for. The shop's service quality goes up not because the chatbot is clever, but because the humans are no longer spending their day typing the same dispatch window into a reply box.
If you run an online shop and want to see what your own message volume would look like on the published plans, do the arithmetic above with your own numbers and match the total against the published allowances at asyntai.com/pricing. No email, no demo, no salesperson.
Sources. Asyntai published pricing page, checked September 2026 (self-serve tiers, message allowances, enterprise contract terms). Average messages-per-chat estimate is the author's input, based on common patterns in small ecommerce deployments; readers should measure their own.