How to write product data an AI can actually answer from

Every AI answer tool has the same failure mode. Ask it something your product data does not cover and it will either say it does not know, which is fine, or it will produce a plausible answer from adjacent information, which is not. The second one loses you a customer and gains you a return.

The fix is not a better model. It is better source data. Here is how to write it.

Write specifications as facts, not marketing

Marketing copy is written to persuade, which makes it a poor source. "Beautifully crafted from the finest materials" cannot answer "is this real leather". "Full-grain buffalo leather, unlined, edges painted" can.

You need both. Keep the persuasive description for the reader, and add a factual specification block for the questions. The factual block is where every measurement, material, dimension, compatibility statement and care instruction lives, written flatly.

Put facts in structured fields, not in prose

A paragraph containing "available in sizes S to XXL, with the XL running slightly large" is hard to answer from reliably. A metafield called size_run containing S, M, L, XL, XXL and one called fit_note containing XL runs approximately half a size large is not.

In Shopify, use metafields for anything that is a fact rather than a sentence:

• Measurements per size, as a structured table
• Material composition, by percentage
• Country of origin
• Care instructions
• Compatibility lists — the models, sizes or versions this fits
• Warranty terms
• What is in the box

Structured fields also make the data reusable. The same measurement table can feed your size guide, your answer layer and your feed to a marketplace.

Answer the negative case explicitly

This is the one people miss, and it matters more than any other item here.

A product record almost always says what a product is and does. It rarely says what it is not and does not. So when a customer asks "is this waterproof", a system with no statement either way has nothing to work from, and the risk of an optimistic inference is real.

Write the negatives down:

• Water resistant, not waterproof. Not suitable for submersion.
• Not compatible with the 2019 model.
• Hand wash only. Not machine washable.
• Does not include a charger.

A record that states its limits produces answers that state limits, which is exactly what you want before a purchase rather than after one.

Use the customer's vocabulary

Your product record says "crew neck, ribbed collar, 200 GSM". Your customer asks "is it thick enough for winter". Those do not match, and a lookup that depends on matching will miss.

Add a line to each product that translates the specification into the terms people actually use. "Midweight — comfortable indoors in winter, not a substitute for a jacket." It feels redundant when you write it. It is the line that answers the question.

The same applies to regional vocabulary. If your customers say "kurti" and your record says "tunic", one of those needs to appear in the data.

Keep an FAQ per product, not just per store

A store-level FAQ answers shipping and returns. A product-level FAQ answers the things that are specific to that item, and it is the highest-value source an answer layer can draw on because it is written in question form already.

You do not need many. Three to five per product, taken directly from the tally of real questions described in the previous post. Write them in the customer's phrasing, answer them plainly, and include the ones with unflattering answers. "Does this come with a warranty? No — this line is sold without warranty." That answer loses a small number of sales and prevents a larger number of disputes.

Audit what you have

Before adding anything, check what is already there. Export your product data and look for:

• Products with an empty or one-line description
• Variants with no distinguishing information beyond a size code
• Specification fields present on some products and absent on others
• Copied descriptions across products, where the details do not actually match
• Supplier copy pasted in verbatim, including specifications that are not true of your version

That last one causes real damage. A supplier's spec sheet describes the supplier's product, which may differ from the variant you carry.

Start with the products that get asked about

You do not need to do this for the whole catalogue. Take your support tally, find the products that generate the most pre-purchase questions, and fix those records first. In most catalogues a small number of products generate most of the questions, usually the ones that are expensive, technical, or hard to size.

Fix those, watch what happens to your question volume, then work down the list.

The honest limit

Good product data makes automated answers accurate. It does not make them omniscient. Some questions — "will this suit me", "should I buy this or the other one" — are judgement, not fact, and the right behaviour is to hand those to a person rather than answer them.

Any answer layer you put on your product pages should have a visible route to a human, and should prefer saying "I don't have that detail" over guessing. If yours does not, that is a reason to change tools rather than a reason to accept the guesses.

QwikAns AI draws its answers from your existing product data, descriptions and FAQs — which means the work described above is the work that makes it accurate.