An ecommerce support Agent should use different sources for public policies, product information, returns, and individual orders. Put approved general information in a maintained knowledge source. Treat order details as authenticated customer data that needs a separate, deliberately built connection. A website chat widget or a policy document alone does not provide access to a shopper’s order.
Start by deciding which questions the Agent may answer from public information, which require a live system, and which should go to a person. The worksheet below makes those boundaries concrete before you configure anything.
Separate the four kinds of retail questions
These questions can sound similar to a shopper but require different evidence:
- Shipping policy: “How long does standard delivery usually take?” This is a general policy question. The answer should come from your current published shipping terms, including relevant limits such as delivery regions or exceptions.
- Product information: “What material is this made from?” This calls for an approved product description or specification. A question about current availability or a changing price needs a source that actually reflects that information; don’t let an old description stand in for a live check.
- Returns: “What is your return window?” is a policy question. “Can you approve my return or send a refund?” asks for an individual decision or action. Explaining a policy is not the same as authorizing a return or executing a refund.
- Individual orders: “Where is my parcel?” or “Can I change the address on my order?” requires customer-specific information. A general knowledge source cannot establish which order belongs to the person asking or confirm its current status.
Use this distinction to avoid a common setup mistake: placing every answer in one document and assuming that makes every type of request answerable.
Build a retail support source matrix
Before uploading files or designing a conversation, fill in one row for each question type. Keep the matrix focused on the information the Agent is allowed to use and the correct next step when it does not have enough evidence.
| Question type | Approved source | Information type | What the Agent may do | What it must not imply |
|---|---|---|---|---|
| Shipping policy | Current shipping policy | Public, general | Explain stated methods, terms, and exceptions | Guarantee a particular parcel’s arrival date |
| Product information | Maintained product descriptions or specifications | Public, product-specific | Answer from information present in the approved material | Invent a specification or treat the material as a live stock check |
| Returns | Current returns policy | Public policy, with possible case-specific exceptions | Explain the stated steps and direct the shopper to the right next step | Approve an individual case or claim that a refund was issued |
| Individual orders | Authenticated order lookup, if separately connected | Private, customer-specific | Give only the order information and actions that the connection and permissions actually support | Reveal or change order details based only on a name, email, or general knowledge file |
The last column is a boundary for your setup, not a claim that a particular integration or action is included. If you want an Agent to look up or change an order, identify the system that holds the information, how the shopper is authenticated, which fields or actions are permitted, and what happens when that connection cannot answer. Treat this as separate integration work. Don’t assume an ecommerce platform connection, order lookup, or refund action exists just because the chat appears on your store website.
Keep public knowledge distinct from customer-specific data
Public knowledge is suitable for information that can be shown to any visitor: shipping terms, product descriptions, care instructions, and the general returns policy. Choose one current version of each policy, remove outdated copies from the material you intend to use, and assign someone to review it when the underlying terms change.
Individual order information is different. It relates to a particular shopper and may change after purchase. Decide what authentication is required before anyone can see it, and do not put private order records into material intended to answer general visitor questions. If the required identity check and order connection have not been built and tested, the useful response is to explain that the Agent cannot verify the order and route the shopper to an appropriate support path.
For LoopReply, The website script on the Agent Deploy page uses loader.js with generated data-agent-id and data-api-key values, and an embed does not itself connect order data, a CRM, or other business systems. So plan any order connection separately rather than treating installation as integration. The knowledge base guide and the practical guide to training an Agent on your own data can help you plan the public-information side.
A database connection also needs careful interpretation. The database connector supports PostgreSQL and MySQL with a validated read-only SELECT query, but a synced knowledge dataset is not proof of a live database lookup for each visitor question. Don’t treat a dataset that was synced as confirmation that an Agent can retrieve each shopper’s current order during a conversation. Confirm what the configured connection actually answers before describing that capability to customers.
Prepare and check each source
For each public source, record its owner, last review date, and the specific questions it should answer. Prefer clear, consistent language. If a policy has exceptions, include them in the material rather than expecting the Agent to infer them from a general statement.
Then confirm the source is ready. A source must finish processing before its content can be used in answers; attaching a file alone does not prove that its contents have been indexed. After processing, test the Agent against the original policy or product information. If a source is incomplete, inconsistent, or out of date, correct that problem before broadening the set of questions.
Use a small test sheet. For each question, write down the evidence an acceptable answer must include and the response you want when the evidence is missing. For example:
| Test question | Evidence to check | Suitable boundary |
|---|---|---|
| “Do you ship to my region?” | The policy’s stated delivery coverage | If the region is not covered in the source, ask the shopper to check with support |
| “Is this product made of linen?” | The relevant product description or specification | If the material is not stated, don’t guess |
| “Can I return an opened item?” | The policy’s terms for opened items | If the policy leaves the case unclear, direct the shopper to a person |
| “Has my order shipped?” | A verified, permitted order lookup | Without that lookup, explain that the order cannot be checked in chat |
The guide to testing when knowledge is missing offers another way to structure the unanswered-question cases. Test both answerable and unanswerable examples; a confident-sounding response is not evidence that the source supports it.
Decide where returns and order requests go
Write the boundary between explaining a process and carrying it out. For example, the Agent may explain the published steps for starting a return, while a person or a separately configured and authorized system handles an exception or a refund request. Do not tell shoppers that a return was approved or a refund was issued unless the responsible process confirms that result.
Set a clear route for questions the Agent cannot answer from the approved source. Authorized Workspace members can take over a conversation and reply as a human; a waiting or human-takeover conversation does not receive an AI response from the widget, and handover is not a response-time guarantee. Make sure your team understands who can take over and what follow-up you can reasonably offer. See the human handover feature for the product details.
Use this launch worksheet
Before putting the retail support flow in front of visitors, complete these checks:
- Name the question types. List the shipping, product, returns, and order questions you intend to cover.
- Name the source for each one. Identify the current policy or product material, or state that a separate authenticated connection is required.
- Set the answer boundary. Write what the Agent may explain and what it must not claim, approve, or change.
- Set the missing-evidence route. Choose a clear response and a support route for exceptions, unclear policies, or unavailable order information.
- Check readiness and accuracy. Confirm sources have finished processing, then compare answers with the original material.
- Keep the connection question explicit. If individual order status or actions are in scope, document the authentication, permitted access, and tested behavior as separate integration requirements.
This matrix gives your ecommerce Agent a narrower job: explain supported public information, avoid presenting policy as an individual order result, and make the next step clear when a question needs authenticated data or human judgment.
Build a policy answer before an order lookup
A fictional store policy says: unopened items may be returned within 30 days; damaged items need team review. Attach that policy, wait for readiness, and ask about an unopened item after 20 days. Then ask for an immediate refund on a damaged item. The first answer should explain the rule; the second should reach the review process without claiming payment was reversed.
For installation and store-data differences, compare the Shopify shortlist and WooCommerce guide. The worked returns scenario makes the permission boundary explicit.