Where the real answer already lives, and why nobody can find it fast
Every product a store sells has more than one document describing it, and the documents rarely agree. A supplier's spec sheet says the finish is not dishwasher-safe. The product description page, written two years ago by whoever was doing marketing copy that quarter, says "easy clean" because that sounded better and nobody checked it against the spec sheet before it shipped. The sizing chart was measured once, against one batch, and nobody has revisited it since a supplier changed a cut. Care instructions live on a separate PDF the warehouse team has, not the one linked from the product page. And underneath all of that sits the knowledge nobody wrote down anywhere formal at all — the answer a founder or a senior support rep has typed into a ticket a hundred times, because it's the exception the official documentation never mentions.
A support rep facing a real customer question has to reconcile all of that in the time it takes to answer a chat message. Get it wrong and the cost isn't abstract: a customer who's told a mug is dishwasher-safe when the spec sheet says otherwise either damages it and blames the brand, or the item comes back as a return with a complaint attached. A shopper told the wrong size ships back the wrong item. A customer in a region where the warranty terms are actually different than the general policy gets a promise the company can't honor. None of these are edge cases in the sense of being rare — they're the normal shape of running a catalogue with real suppliers, real regional variation, and product copy that was accurate when someone wrote it and has drifted since.
What the system does, day to day
Once it's built around your actual documents, the system works the same way for every question a support rep, or an automated agent working on their behalf, throws at it: it searches the indexed material, finds the passage that actually answers the question, and returns an answer built from that passage with the source document attached. Nobody has to know whether the answer lives in a supplier PDF, a Shopify metafield, or last month's ticket log — they ask the question in plain language and get back an answer plus a citation, the same way a good colleague would say "here, this is where I got that" instead of just asserting it.
The index covers four kinds of material, because ecommerce product truth genuinely splits into four different sources with different owners and different update cycles. Product knowledge — specs, materials, dimensions, compatibility — comes from supplier documentation and your own catalogue data, and it's the layer most likely to disagree with the marketing copy sitting on the live product page. Compliance and certification documents — safety data sheets, country-of-origin paperwork, regulatory certificates for categories that need them — come from suppliers directly and change on their own schedule, not yours. Policy documents — returns, warranty, shipping by region — matter less for their general rule than for their exceptions, because the general rule is usually what's already on the policy page; the reason someone is asking is almost always that their situation is the exception. And past-ticket knowledge captures the accumulated, unwritten answers your team has been giving by memory: the SKU with a zipper that's known to jam under specific conditions, the color that photographs differently than it ships, the workaround support has been repeating without it ever making it into an official document.
Each source stays on its own refresh schedule. A supplier's spec sheet might update rarely; ticket knowledge accumulates daily. When a document is superseded — a policy update, a corrected sizing chart — the old version comes out of the index instead of sitting there waiting to be surfaced as if it were still current.
Three questions this answers on a normal day
Is this actually dishwasher-safe
A customer asks a support rep, through chat or through the agent that handles routine tickets, whether a ceramic mug is dishwasher-safe. The product page copy says "easy clean," which is vague enough to mean anything. The system searches the indexed material and returns the supplier's actual spec sheet, which specifies hand-wash only above a certain water temperature, cited to the document. The rep — or the automated agent — answers with the real constraint instead of the marketing phrase, and the mug doesn't come back three weeks later chipped from a dishwasher cycle with a complaint attached.
Does the warranty actually cover this, for this customer
A customer in a region where the store's general warranty terms don't apply the same way — a different statutory return window, a different repair-versus-replace rule — asks what's covered. The general policy page states the default rule, but the honest answer depends on the regional exception, which lives in a separate addendum most reps have never opened. The system retrieves the regional exception itself, not the general policy, and cites the addendum it came from. That's the entire point of policy retrieval done properly: the rule is rarely the hard part, the exception is, and a system that only ever surfaces the general policy page is answering the easy ninety percent of the question and guessing at the part that actually needed checking.
The question that's been asked a hundred times before
A new support hire gets a message about a specific product's zipper catching on the lining under normal use — not a defect covered in any official documentation, just something the team has learned to recognize and has a standard response for. Rather than escalating to a senior rep who's answered this exact question dozens of times, the new hire asks the system. It surfaces the pattern from past tickets where the same issue was reported and resolved, with the accumulated answer — what to tell the customer, whether it's a known batch issue, what the standard resolution is. The founder or senior rep who used to be the only source of that answer stops being a bottleneck for it.
Where the knowledge itself breaks down before the system can fix it
This is the part worth being honest about rather than glossing over: a retrieval system is a layer that stands on top of whatever documentation already exists, and it is only as reliable as that documentation. If the supplier spec sheet says one thing and the product page copy says another, the system will find both, and a well-built one flags the conflict rather than confidently picking a side — but it cannot make the decision about which one is actually true. That's a judgment call for someone on your team, not something retrieval engineering solves on its own.
That matters because the failure mode here is quiet, not loud. A support agent — human or automated — built on top of contradictory source material doesn't know it's wrong. It answers with exactly the same tone of confidence whether the underlying document is current and correct or two years stale, because confidence is a property of how an answer is phrased, not a signal of whether the source behind it was ever checked. Cleaning up which document is authoritative — retiring the outdated PDP copy, reconciling the sizing chart against what the supplier actually ships now — is part of the work of building this properly, not a side effect the system handles for you. Part of scoping any engagement honestly is looking at what's actually contradictory in your existing material before anything gets indexed, because building fast retrieval on top of a genuine conflict just makes the wrong answer arrive faster.
How it connects to what you already run
The system indexes the documents and data your business already has rather than asking anyone to re-enter anything. Supplier spec sheets and compliance PDFs, wherever they currently live — a shared drive, an email thread, a supplier portal export. Product and catalogue data from Shopify or a similar platform, including custom fields and metafields that often hold the details a generic product description leaves out. Policy documents, including any regional addenda that live separately from the main policy page. And historical ticket data exported from Gorgias, Zendesk, or whatever your support desk runs, so the answers your team has already given become searchable instead of re-derived from memory every time.
This is the retrieval layer, not the agent that talks to customers. AI agents for ecommerce are what actually resolve a ticket end to end — matching the customer, checking policy, issuing a label, routing anything that touches money to a person. What this system does is give that agent, or a human rep working the same queue, something true to say instead of something plausible-sounding. The two are usually built together, but they're separate pieces solving separate problems: one finds the right answer in your own material, the other decides what to do with it.
This sits inside the broader knowledge systems Calfy builds for document-heavy parts of a business, and the use case for searching an internal knowledge base covers the retrieval mechanics in more general terms if some of this is new. The glossary entry on AI knowledge bases is worth a look for the underlying terminology, and the full range of AI systems built for ecommerce covers where this fits alongside the rest.