Guides
Write merchant knowledge the assistant can actually use
Policies, care, shipping, and store Q&A belong in approved knowledge—not in a hidden prompt you cannot audit.
Shoppers do not only ask for products. They ask about returns, alterations, lead times, care, shipping regions, and whether a fabric can be dry cleaned. If those answers live only in a founder’s memory, a Slack thread, or a PDF nobody updates, the assistant cannot stay on-brand. Merchant knowledge is the auditable layer that sits beside the catalog.
This guide explains how to write knowledge the assistant can actually use: short, factual, consistent with public policy pages, and explicit about what must not be said. It is not a prompt-engineering essay. WardrobeIt expects knowledge to be curated in the merchant workspace, not hidden in an unreviewable instruction.
Catalog facts versus store knowledge
Catalog facts are product records: price, variant, image, inventory, type. Store knowledge is operational language: how returns work, which regions you ship to, how long a made-to-order piece takes, and how you talk about fit without inventing a guarantee. Mixing the two causes drift. A care instruction that exists only in knowledge and contradicts the PDP will surface as a trust problem.
- If it is a sellable attribute, put it on the product.
- If it is a store policy or process, put it in merchant knowledge.
- If you cannot defend it on a policy page or an approved internal source, do not give it to the assistant.
Fashion teams often try to stuff styling opinion into knowledge (“this dress is universally flattering”). That is not knowledge. That is an ungrounded claim. Knowledge should read like a careful policy or operations note, not like a lookbook caption.
How to write an entry
Write in the same words customers will read on your site. Avoid slogans. Prefer “Returns are accepted within 14 days on unworn items with tags” over “We make returns easy.” Split combined topics. Shipping and returns are different entries even if they share a footer link. Lead times for made-to-order bridal pieces are different from standard apparel shipping.
Keep entries short enough to maintain. Long essays go stale. If an answer needs three caveats, the caveats belong in the entry, not in a sidebar only staff can see. The assistant will not know the sidebar exists.
Good versus weak examples
Weak: “Our pieces are luxe and run true to size.” That invents a fit guarantee and a quality claim the catalog may not support. Better: “Size notes are listed on each product when merchandising has added them. If a product has no size note, the assistant should not invent one.”
Weak: “We ship everywhere fast.” Better: “We ship to the regions listed on the shipping policy page. If a destination is not listed, the assistant should not promise delivery.” Weak: “Virtual try-on proves fit.” Better: “Virtual Try-On is a visualization for eligible products. It is not an exact-fit assessment.”
What belongs in the first published set
Do not aim for a large library on day one. Publish the entries you will actually maintain. A practical first set for fashion stores usually includes shipping regions, return windows and conditions, care that is store-wide rather than SKU-specific, appointment or made-to-order lead times if you sell that way, and a clear sentence about try-on language if you offer eligible Virtual Try-On.
- Open the live policy pages and copy the facts, not the marketing wrapping.
- Add only the operational detail a shopper asks before purchase, not post-purchase order tracking you cannot access.
- Write prohibitions in the same sitting as permissions.
- Assign an owner who will update the entry when the public page changes.
What the assistant must not say
Document prohibitions as clearly as permissions. Typical fashion constraints include: no medical or therapeutic claims, no invented celebrity styling, no promising a delivery date that operations cannot keep, no describing a Virtual Try-On preview as an exact-fit assessment, and no quoting plan prices or discount codes that finance has not approved.
If you sell jewelry, do not let knowledge invent metal purity or stone origin the PDP does not state. If you sell activewear, do not let knowledge invent a performance claim merchandising did not publish. If you sell footwear, do not let knowledge invent a size conversion the shopper did not provide evidence for.
Where entries live and who owns them
Follow Merchant Knowledge and Store Help for where entries live, and the Merchant Portal Guide for day-to-day control. Product context for shopper-facing Q&A sits on Store Help and Product Q&A. After you publish knowledge, test the same questions a shopper would ask and compare the answer to the live policy page.
Name an owner. If knowledge “belongs to everyone,” it belongs to no one, and seasonal exceptions will rot in the assistant after the public page has moved on.
A verification walkthrough
Pick ten questions from real support mail, PDP comments, or the questions your team already knows by heart. For each question, find the public source, write or update the knowledge entry, then ask the assistant on a staging theme. Mark pass, gap, or conflict. Conflicts are not “close enough.” Fix the source of truth first, then the entry.
- Does the answer match the live page, including the caveats?
- Does the answer avoid product facts that belong on the SKU instead?
- If the fact is unknown, does the assistant say so rather than improvise?
A maintenance habit
Knowledge is not a launch artifact. When you change a return window, update the public page and the knowledge entry in the same change. When a seasonal collection introduces new lead times, add them before paid traffic points at those SKUs. A quarterly audit of the ten most common questions is more valuable than a one-time dump of fifty unused articles.
Related reading: Merchant Portal, Getting Started, and the academy module on knowledge if your team needs a shared language for audits.
