Website Chatbot for E-commerce (2026)

A shopper on a product page has already done the hard part - found the item, opened it, and started reading the description. What stops them from buying is almost always one specific, answerable doubt: does this run small, will it arrive before Friday, can it be returned if it doesn't fit. A widget that answers that one doubt in the moment converts a browsing session that would otherwise end in a closed tab.

The advantage over a generic contact form is page context. On a size-run t-shirt page, the bot can open with fit guidance drawn from the product's own size chart. On the shipping-and-returns page, it can open with the policy relevant to the shopper's cart total rather than a static block of text nobody reads. A marketplace listing can't do this - the platform controls the page, not the seller.

The concrete scenario: a shopper adds a jacket to the cart, hesitates at checkout, and opens the widget to ask "does this run true to size?" A store that answers in ten seconds keeps the sale. A store where that question goes to a contact form loses the shopper to a competitor's tab before the reply ever arrives.

Keep the automated scope tied to the product and the order, not to subjective styling advice:

• Sizing and fit. Read from the product's size chart and reviews, not a guess.
• Stock and variant availability. Confirm a specific color or size is in stock before the shopper adds it to cart.
• Order status and tracking. Look up a real order by number or email and return the actual status.
• Shipping and returns policy. Answer against the store's actual policy, scoped to the shopper's cart or destination when that changes the answer.
• Discount and promotion questions. Confirm whether a code applies to the items in the cart.
• Cart recovery. If a shopper who has given an email leaves items sitting in the cart, the bot can proactively offer to help finish checkout.

What's deliberately off that list: styling opinions and comparisons dressed up as advice - "which one should I get" is a judgement call a person can make better, and a bot guessing confidently is worse than a bot saying so.

This is the constraint that defines an ecommerce widget more than any other. Unlike a WhatsApp thread tied to a phone number, a website session exists only inside that browser tab. A shopper who asks a question, gets an answer, and closes the tab to "think about it" leaves nothing behind unless an email was captured during the conversation.

Picture it concretely: a shopper opens the widget from a product page, asks whether a jacket runs small, gets a helpful answer, and closes the tab to compare it against another store's price. Without an email captured in that exchange, the store has no way to follow up - no abandoned-cart reminder, no answer to a second question they think of later, nothing. The conversation that almost converted simply stops existing.

The fix is to make the capture feel like part of the shopping experience, not a tollbooth. Offering to email a size-chart link, a discount code, or an order confirmation are all natural, low-friction reasons to ask for an address - each gives the shopper something in return rather than gating the answer behind a form. Asking for an email before answering a basic sizing question, on the other hand, reads as a bait-and-switch and drives the shopper straight to a competitor's tab instead.

Until that email exists, every visitor is anonymous, including returning customers who haven't logged in. The bot can't tell a first-time browser from someone on their fifth order without that handoff, which is why the earliest useful moment to ask is right after the bot has already been helpful once.

The line here is less about regulation than about money moving and trust breaking:

• No unilateral refund approval for high-value orders. Automating a standard return within policy is fine; approving an exception on a large order should route to a person who can see the full account.
• No payment or card detail handling inside the chat. Checkout stays on the store's actual checkout flow - the bot should link to it, never collect card numbers in the conversation.
• No confirming stock it hasn't actually checked. A bot guessing an item is available because it usually is causes an oversell; it should check the live count or say it isn't sure.
• No resolving a dispute over a damaged or wrong item sight unseen. Collect photos and details, then hand to a person who can approve a replacement or refund.

The pattern across all four: anything involving money changing hands beyond a standard, policy-covered return should end in a human decision, even if the bot does the information-gathering first.

A website widget can trigger itself on scroll depth, time on page, or exit intent - capabilities no messaging channel has, since there the shopper has to open the thread first. Ecommerce is where this is most tempting to overuse, because more conversations look like more engagement on a dashboard.

The honest trade-off: an exit-intent pop-up that fires on every product page raises the number of chats started, but a large share of those are people closing an unwanted interruption, not people with a real question. That inflates conversation volume while the actual qualified-lead rate - people who go on to buy or leave a usable email - can fall, because the shoppers who would have engaged anyway now see the prompt as noise alongside everyone who wouldn't.

A more selective approach performs better: trigger on scroll depth past the size chart or reviews section, where lingering signals genuine consideration, or on exit intent specifically from the cart page, where the shopper has already shown purchase intent and a last question is more likely to be real.

Escalate immediately on: a refund or exception request outside standard policy, a damaged or wrong item, a shopper asking for a person by name or by request, and two failed attempts at answering the same question. Order-status and sizing questions rarely need this; disputes almost always do.

During business hours that means a live agent picking up the same widget thread. Outside them, the honest move is to say so and capture the issue for a first-thing-tomorrow follow-up rather than let the bot keep guessing at an answer it doesn't have. A shopper with a genuine dispute who gets a vague non-answer at 2am is more likely to open a chargeback than wait for a reply.

Whoever picks up the conversation should see the shopper's cart, order history if identified, and everything already said - see human handoff for how that handoff should carry context instead of making the shopper start over.

1. Push stock, variants and order status in over webhook so answers reflect what the store platform actually shows, not a guess - there's no native storefront connector, so this is a build step.
2. Configure page-aware openers - a sizing prompt on product pages, a shipping-policy prompt on the cart page, an order-lookup prompt on the account page.
3. Build the email-capture moment around something the shopper wants - a size chart, a discount, an order confirmation - rather than a gate before the first answer.
4. Set proactive triggers selectively - scroll depth or cart-page exit intent, not a blanket pop-up on every page.
5. Write the refund and dispute escalation path explicitly so the bot gathers details and hands off rather than approving exceptions.
6. Check the mobile checkout flow. Over half of store traffic is mobile, and the widget needs to go full screen there so it doesn't sit on top of the add-to-cart button.

Because the same bot logic deploys across channels, the order-status and sizing flow built here becomes the starting point if the store later adds Instagram or WhatsApp for post-purchase support.

Can a website chatbot check order status for a customer?

Yes, when it's connected to the store's order system. A shopper can enter an order number or the email used at checkout and get real status back - processing, shipped, delivered - rather than a generic "check your email" reply. This is one of the highest-value automations for a store because it's a pure lookup with no judgement involved and it removes a large share of routine support tickets.

Should the chatbot handle refunds automatically?

Only within standard, published policy - a return inside the return window with no damage claim can be automated end to end. Anything outside that, like a high-value order, a damaged-item claim, or a request past the policy window, should route to a person who can see the full order and account history rather than let the bot approve an exception on its own.

What happens if a shopper closes the tab without buying?

The conversation and the cart context are lost unless an email was captured during the chat - a website session has no persistent identity across visits the way a messaging-app thread does. This is why the capture moment matters: offering something useful, like a size chart or a discount code, in exchange for an email turns an otherwise unrecoverable browsing session into a follow-up opportunity.

Does the chatbot know what's in a shopper's cart?

Yes, when connected to the storefront - the widget can read the current page and cart contents, which is what lets it answer a shipping-cost or promo-code question specific to what's actually in the cart rather than a generic policy statement. This page-awareness is one of the clearest advantages a website widget has over a messaging-app channel.

Should an ecommerce site use exit-intent pop-ups on every page?

Not everywhere. Exit-intent on every product page raises the number of chats started but pulls in a lot of people just closing an unwanted interruption, which can lower the share of conversations that turn into real leads or sales. It performs better scoped to high-intent moments, like leaving the cart page, where the shopper has already shown they're close to buying.

How should human handover work for a store's chatbot?

Escalate immediately for anything involving a refund exception, a damaged or wrong item, or a shopper explicitly asking for a person, and always after two failed attempts at the same question. The agent picking up the thread should see the shopper's cart and order history along with the full conversation, so a customer with a genuine complaint never has to explain the problem twice.