A WooCommerce store's support inbox is remarkably predictable. Where is my order. Do you ship to my country. Is this the right size. What's your returns policy. Do you have a discount code. Five questions, over and over, and every one of them is a customer who is either about to buy or about to be disappointed.
An AI chatbot handles all five, and the first one, "where is my order", it can answer with the actual order status pulled live from your store. This guide covers what a WooCommerce chatbot should and should not be allowed to do, how to connect it, and the pre-sale flows that make it a revenue tool rather than a support-cost reduction.
A store chatbot has two jobs, and one is worth more
| Post-sale (support) | Pre-sale (revenue) | |
|---|---|---|
| Typical questions | Where's my order, how do I return this, when will it arrive | Which one should I buy, does it fit, do you ship here, is there a code |
| What automation saves | Your time | The sale |
| Where most stores start | Here | Should be here |
Order tracking is the obvious win and it is genuinely useful, but it is a cost saving on customers who already paid. The money is in the pre-sale half: the visitor standing in front of two products who cannot tell which one is right, and who will close the tab rather than send an email and wait a day.
Connecting the store
PopABot connects to WooCommerce through the store's REST API using a read-only key pair you generate in WooCommerce itself, on Essential and above. Three steps:
- In WordPress, go to WooCommerce → Settings → Advanced → REST API and create a key. Set permissions to Read, never Read/Write. The chatbot never needs to change anything in your store.
- Paste the consumer key and secret into the WooCommerce connection screen in your PopABot dashboard, along with your store URL.
- Test the connection, then enable it on the chatbot that serves your storefront. The WooCommerce integration tutorial has the click-by-click version.
If the connection test fails, the usual cause is a security plugin or WAF blocking the API path rather than a bad key. Whitelisting /wp-json/wc/v3 for the integration fixes it.
What the integration can and cannot answer
This is worth being precise about, because vendor marketing in this category is vague and store owners get burned by assuming more.
| Capability | How it works |
|---|---|
| Order lookup | Live. The customer gives an order number and the email on the order; the bot returns that order's status. Both are required, so one shopper cannot read another's order. |
| Product search | Live against your real catalogue: names, descriptions and prices as they are right now, not a stale scrape. |
| Coupons, shipping options, payment methods | Synced from your store daily and answered from that cached context. Fine for policy questions, not for real-time changes. |
| Stock status in search results | Shown inline on the product cards, alongside price and rating. Search can also filter to in-stock items only, so out-of-stock products stop being recommended. |
| A standalone "is X in stock?" lookup | Not a separate capability. There are exactly two live actions, product search and order lookup. Stock reaches the visitor as part of a search result, not as its own answer. |
| Product variations | Not answered. Variant matrices produce confidently wrong answers. Direct to the product page. |
| Refund status | Not answered. Money questions go to a human, every time. |
The exclusions are design decisions, not gaps. Variations and refunds are both cases where a plausible wrong answer costs more than an honest handoff. Stock is the subtler one: it is accurate enough to show on a product card the moment it is fetched, but there is no standalone stock question, because "yes, we have it" as a bare answer ages badly between the reply and the checkout.
The pre-sale flows worth building
1. The product finder
Three questions that narrow a catalogue to two or three recommendations. What are you buying it for, what's your budget, any constraint that matters (size, skin type, machine compatibility, room dimensions). Build it in the flow builder with buttons rather than free text, and end with product links. This is the single highest-value thing a store chatbot can do, and it works best on stores with more than about twenty SKUs where browsing is genuinely hard.
2. The shipping and returns answer
"Do you ship to Ireland and how much is it" is a purchase-blocking question. Put your shipping table and returns policy into a dataset as plain text, organised by destination, and the bot answers it instantly in the shopper's own language. Roughly 100 languages, detected from the browser, from the English text you wrote once, which matters a lot if you ship internationally.
3. The sizing and fit conversation
Fashion, footwear, furniture, pet products, anything with dimensions. Feed the bot your size guide as text, not as an image, and let it answer "I'm usually a 42 in Nike, what should I order" properly. Returns caused by sizing are the most expensive returns there are; a good answer here pays for the subscription several times over.
4. The exit capture
When someone is clearly leaving without buying, one well-timed question ("want the size guide emailed to you?") converts a bounce into an address. Exit-intent flows and inactivity nudges are available on Essential and above. Use them sparingly: one prompt per visit, never on the checkout page.
Keep it off the checkout
The most common WooCommerce chatbot mistake is running the widget on cart and checkout pages. A chat bubble at the payment step is a distraction from the only action that matters, and worse, it invites the customer to ask a question instead of completing the purchase.
Run the bot on product pages, category pages, the homepage, and your policy pages. Turn it off on cart, checkout and order-received. If you installed via a snippet plugin, that is a display rule; if you installed in a child theme, it is a conditional tag. The WordPress install guide covers both.
Order lookup and customer data
Order tracking touches customer data, so a few rules:
- Require both order number and the email on the order. This is enforced by the integration. Never build a flow that returns an order from the number alone.
- Do not have the bot repeat back full addresses or payment details. Status and expected delivery are enough.
- Use a read-only API key. If the key is ever exposed, read-only is the difference between an incident and a catastrophe.
- Mention the chat tool in your privacy policy, including what it stores and for how long. This is a GDPR requirement for most EU-facing stores and it takes one paragraph.
Setup checklist
- Create a read-only WooCommerce REST API key
- Connect it in the dashboard and test
- Load shipping, returns and sizing as text datasets, in plain text not images
- Add 20 Q&A pairs from your actual support inbox
- Build the product finder flow with buttons
- Add an order-tracking path that asks for number and email
- Set display rules so the widget stays off cart and checkout
- Turn on SMS notifications for pre-sale enquiries that need a human
- Test on mobile, where most of your traffic is
- Read the first week of transcripts and turn every miss into a Q&A pair
What to expect
On a store doing a few hundred orders a month, the realistic outcome is that most "where is my order" emails stop arriving, and pre-sale questions that used to go unanswered overnight get answered. The number to watch is not deflection rate. It is whether the product-finder flow produces sessions that end at a product page, and whether your sizing-related returns go down. Both show up within a month.
Related reading
- How to add an AI chatbot to WordPress
- WooCommerce integration tutorial
- Training a chatbot on your own catalogue and policies
- Best Tidio alternative in 2026, if you're comparing e-commerce chat tools