WooCommerce customer questions often look simple but require several sources of truth. “Where is my order?” depends on the customer’s identity, order status, shipment data, and possibly a carrier API. “Can I return this item?” depends on the product, purchase date, order status, store policy, and sometimes the customer’s location.
Retrieval-augmented generation (RAG) can make these conversations more useful by retrieving the relevant store information before generating an answer. The important design decision is to separate general store knowledge from private, customer-specific data.
What RAG should answer in WooCommerce
A WooCommerce support assistant commonly handles three categories of questions:
- Store-policy questions: “How long do I have to return an item?” or “Do you ship to Canada?”
- Product questions: “Is this jacket waterproof?” or “Which size should I choose?”
- Order-specific questions: “Has my order shipped?” or “Can I change my delivery address?”
The first two categories are good candidates for conventional document and product retrieval. The third category usually requires live, permission-controlled queries rather than a vector search index alone.
Use separate retrieval paths
A reliable WooCommerce implementation should route the question before retrieving context. A simple router can classify the request as policy, product, order, account, or unsupported.
For example:
- Policy: retrieve published pages, FAQs, shipping tables, and return terms.
- Product: retrieve product descriptions, attributes, variation data, manuals, and approved merchandising content.
- Order: authenticate the customer, then query the order system or fulfillment provider.
- Account: use a protected customer-account API for addresses, subscriptions, downloads, or payment-related status.
This prevents a common failure mode in which a model attempts to answer a private order question from stale or unrelated indexed content.
Preparing WooCommerce content for retrieval
Product and policy content should be indexed as meaningful documents rather than as one large export. Useful document types include:
- Product title, short description, long description, categories, tags, attributes, and variation information.
- Shipping zones, methods, delivery estimates, exclusions, and handling times.
- Return, refund, warranty, cancellation, and exchange policies.
- Frequently asked questions and support articles.
- Care instructions, installation guides, technical specifications, and downloadable manuals.
Attach metadata to every chunk so retrieval can be filtered and citations can be generated. Typical metadata includes source_type, post_id, product_id, sku, language, country, customer_segment, visibility, and updated_at.
Do not index drafts, private posts, hidden internal notes, deleted products, or unapproved content. If a product is out of stock, that fact should either be retrieved from a current inventory source or clearly marked as time-sensitive rather than embedded as permanent descriptive text.
Chunking product and policy documents
Chunking should preserve the context required to answer a question. Splitting every document into equal character counts can separate a heading from the policy it describes.
A practical structure is to create chunks around sections such as:
- Product overview
- Materials and specifications
- Sizing and fit
- Shipping information
- Returns and exclusions
- Warranty terms
Include the product name and section name in each chunk. For example:
Product: Alpine Rain Jacket<br>Section: Care instructions<br>Content: Machine wash cold on a gentle cycle. Do not use fabric softener...This gives the embedding model and the language model useful context even when a section is retrieved without the rest of the product page.
Order questions require authorization
An order number by itself is not sufficient authorization. A customer could guess or obtain another customer’s order number. Before exposing order details, require an authenticated session or use a verification flow such as a signed account link, one-time code, or a combination of order number and verified billing information.
After authorization, retrieve only the fields needed for the question. For a delivery-status request, the assistant may need the order status, tracking number, carrier, and latest tracking event. It should not receive the full billing address, payment tokens, internal notes, or unrelated orders.
A protected application service might expose a limited response such as:
{