Superintelligence Prep for Ecommerce: Returns and Product Facts

An AI agent for an ecommerce store can answer return requests and product questions well only when it reads one consistent set of facts: the return rules, the exceptions, the sizing and materials, the compatibility notes and the stock status. Most stores keep these facts in several places, from a policy page and a help center to support macros and a warehouse spreadsheet, so an agent given access today would inherit every contradiction. Centralizing those facts now, with named owners and clear limits on what the agent may do, is the base that a more capable agent will need later.

Key takeaways

• An agent can only answer returns and product questions as reliably as the policy and catalog it reads.
• Turn return terms into explicit rules with exception paths, and choose one source of truth for each policy.
• Give every product fact an owner, a source and a last reviewed date, and say so when the catalog is silent.
• Separate what the agent may answer, look up, suggest and hand to a person, and grant each permission on purpose.
• Define one observable success criterion and keep logs that trace each answer back to the fact it used.

Why returns and product questions come first

Returns and product questions make up a large part of the contact in an online store, and they are where a wrong answer costs the most. A shopper told the wrong return window opens a refund dispute, and a shopper given the wrong fit information sends a parcel back that never needed to travel. These questions also repeat in similar words, which makes them a sound first test for an agent because the correct answer can be checked against a document.

Customer chat is only the visible part. The same facts feed the storefront, marketplace listings, search ads, post-purchase emails and the team that answers messages by hand. An agent that only answers chat inherits whatever gaps exist in the rest of the business, a point we develop in AI Agents for Ecommerce Operations Beyond Customer Chat.

Treat this work as preparation. The agent you may later trust with more authority will be only as reliable as the facts, owners and logs you set up now.

Turn the return policy into rules an agent can read

A return policy written as prose is hard for anyone to apply consistently, and harder for an agent. Write it as a small set of rules, each with a condition, an outcome and a named exception path. For every product category with its own terms, record these fields:

• The return window and the event it is counted from, such as delivery date, shipment date or order date
• Item conditions, such as unworn, unused, sealed or in original packaging
• Excluded items, with the reason written in plain language
• Refund method, exchange options and who pays return shipping
• Label rules, including which carriers, countries and addresses are covered
• Exception paths, such as damaged on arrival, wrong item sent or late delivery, and the role that decides each one

Conflicts are the most common failure. If the product page states one window, the checkout states another and a support macro states a third, the agent will follow whichever text it reads first. Choose one source of truth, link every other channel to it and retire the old wording. Exception decisions can stay out of public text, but the agent must know that these cases go to a person along with a summary of the order.

Give every product fact an owner and a source

Product questions concern facts that change: dimensions, materials, care, compatibility, certifications, stock and variants. Each fact should carry an owner who answers for it, a source document where it came from and a field showing when someone last checked it. Marketing language belongs in a separate layer. An agent should state a dimension only when that dimension is in the catalog, and it should say it does not know when the catalog is silent. The checklist below covers the facts most often needed:

• Dimensions and the measurement method used, including what each figure actually covers
• Materials, care instructions and any origin or labeling information the brand must show
• Compatibility, including the products or conditions the item does not work with
• Variant structure, so each option has its own availability and its own notes
• Warnings, certifications and any performance claim that needs evidence on file

Illustrative scenario: a shopper asks whether a bag fits a laptop in its sleeve. The catalog gives the interior size of the main compartment, while the sleeve is a separate variant with its own note. A reliable answer quotes the listed compartment size, names the variant that includes the sleeve and links the size guide. It does not estimate a fit the catalog never measured.

For a closer look at how catalog and support fit together, see Superintelligent Agents for Ecommerce: Catalog, Support, Returns.

A step-by-step plan to centralize the facts

Keep the first pass small. The goal is a verified set of answers to the questions customers actually ask, not a complete product database.

• Export the most frequent return and product questions from support tickets, chat logs and email, then group them by topic.
• Assign one owner for each policy and each catalog section, plus a named backup who can answer when the owner is unavailable.
• Write each answer as a short fact with its source document, its owner and the date it was last checked.
• Find every place the same policy appears, including macros, email templates and marketplace listings, and make them match.
• Mark the cases that always go to a person, such as damaged goods, international returns, chargebacks and personalized orders.
• Build a question set from real messages, run the current answers against it and record which ones are wrong, missing or unsafe.

The question set outlasts any single tool. It becomes the test suite for the agent later and remains useful if the platform or the model changes.

Decide what the agent can answer, look up, suggest and hand off

Every action an agent takes should be granted on purpose. Least privilege, a principle that runs through most access guidance, means the agent receives only the reads and writes its role needs, scoped to the customer in the conversation. Customer messages may also contain text meant to change the agent's behavior, so the agent should treat that text as information to evaluate, not as instructions that override the rules. A practical decision guide looks like this:

• Answer from published policy and verified catalog facts: allowed without approval, with the source logged.
• Read order status and return eligibility for the customer's own order: allowed, read-only and scoped to that customer.
• Create a return label: allowed only when the case matches a rule exactly, and the label event is logged.
• Issue refunds, store credit or any exception: not allowed for the agent, routed to a person with a case summary.
• Change prices, policy text or catalog content: not allowed, though the agent may draft a suggested edit for the owner.
• Any chargeback, legal claim or safety report: routed to a person immediately.

The same logic applies to marketplaces, where disputes involve more parties and tighter approval limits. Superintelligent Agents for Marketplaces: Trust, Disputes, Sellers covers that setting. For a shared vocabulary on mapping, measuring and assigning accountability for AI risks, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a reasonable reference for an operations leader.

Measure the answers and keep the facts current

Choose a success criterion someone can observe in a weekly review. Examples include the share of return requests routed to the correct rule, the share of answers that cite a current source and the number of escalations a person had to reverse. Run the question set again after every policy change, after any catalog update touching a common question and after any change to the store platform or the order system. Anthropic's guidance on context engineering makes a related point: an agent performs better when it receives only the information relevant to the task in front of it, so keep the fact library focused.

Logs close the loop. Record which fact the agent used for each answer, so a disputed reply can be traced to its source in minutes rather than reconstructed from memory.

How Be Human handles this: Be Human designs, implements and operates personalized AI infrastructure for companies, keeping an agent's identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, for example the return request path or the product question path, along with the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can include monitoring of answers and escalations, recurring evaluations against the question set, integration maintenance when the store platform or order system changes, permission review, incident response when a wrong policy is served and controlled improvements to the facts. The service is delivered remotely, in English and Portuguese.

Choosing the first task

If you want to find the first return or product question task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent issue refunds for my store? At the start, it should not. A refund is a financial action with exceptions, so the safer pattern is for the agent to check eligibility, explain the policy and hand the case to a person with the order details already summarized. Refund authority can be widened later, once the rules, logs and evaluations show that the agent applies them correctly.

Do I need a product information system before an agent can help? Not necessarily. A spreadsheet or a well-maintained catalog export can serve as the first source, provided every fact has an owner and a last reviewed date. The important step is agreeing on the answers, not buying a new system.

How is this different from the chatbot on my help page? A help page chatbot usually answers from the text it was given and stops there. A managed agent has defined memory, permitted tools, approval boundaries and monitoring, so it can check an order, apply a rule and log what it did, while a person keeps authority over exceptions.

Which languages does the service support, and where is it delivered? Be Human delivers its service remotely, in English and Portuguese. A useful first conversation covers your current return rules and catalog, which shows whether those facts are ready for an agent or need to be centralized first.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.