Product descriptions with AI that don’t all sound the same.

A catalog team generates descriptions for its whole range over a weekend. A few weeks later, a customer returns a sofa described as having a “solid oak frame”. The frame was pine. Nobody had recorded the material, so the model filled the gap with what sofas usually have. Meanwhile, a scroll through the category shows description after description opening with the same sentence.

Generated product copy goes wrong in exactly these two ways: invented features and identical text. Both have the same cure. Write only from verified attributes, vary the structure by category, list the claims the model may never make, and let merchandisers approve what is published.

What goes wrong with generated product copy?

• Invented features. Asked to write about a product with gaps in its data, a model fills them with what is typical: solid wood, machine washable, suitable for outdoor use. Plausible, confident and wrong, and each one can end in a return or a complaint.
• Sameness. Same kind of inputs, same prompt, same shape of output. Thousands of near-identical pages help neither shoppers nor search.
• Channel mismatch. Text that is too long for a marketplace, uses formatting the channel strips out, or reads like a translation in one of its languages.
• Stale copy. The product changes supplier or material and the description doesn’t. Tie each description to the attribute values it was written from, so a change triggers a new draft.

What should the model be allowed to write from?

Verified attributes only: dimensions, materials, colors, care instructions, what is in the box, from the product information system or a supplier sheet someone has checked. Missing attributes are flagged, never guessed, above all materials, sizes and anything touching compliance. When two sources disagree, such as a supplier sheet and a warehouse measurement, the draft uses neither and flags the conflict.

The model receives the attributes as fields and returns the description together with the attributes each sentence relies on. An automatic check then confirms that every factual claim maps to an attribute. Our note on structured output covers how to make that exchange reliable.

Consider an illustrative case: a three-seat sofa like the one above, whose record lists dimensions, fabric, color and seat depth, but no frame material. The draft describes what is known, the fabric, the seat and whether it fits a narrow room, and returns a flag instead of a guess: “Frame material missing. Add it, or approve the text without it.” The merchandiser asks the supplier, and the next draft includes it.

How do you keep copy varied and useful?

• Category templates. Each category gets its own structure. A sofa leads with comfort and fit, a lamp with light and installation, a pan with use and cleaning.
• Lead with the difference. The opening line uses the attribute that sets the product apart from its siblings, not the attribute they all share.
• Customer questions as inputs. Support tickets and reviews show what shoppers ask, such as whether a wardrobe fits through a standard door, so the template answers it when the data allows.
• A similarity check. Each new description is compared with others in its category; drafts that are too close are regenerated or flagged.
• Banned claims. A list the model may never write unless a verified attribute supports it: health claims, safety claims, environmental claims, and comparisons such as “the best on the market”. Whoever owns product compliance owns the list.

A missing attribute should produce a question, never a sentence.

How do you handle channel rules and languages?

Each channel sets its own requirements. Your own site may want long-form copy in your voice, while Trendyol, Hepsiburada and Amazon each have their own limits on titles, formatting, required fields and words not allowed. Read the current rules from each channel’s own documentation, encode them as a channel profile, and give the profile an owner, because the rules change. Then generate each channel’s version from the attributes, instead of cutting down the long one. Category and attribute mapping per marketplace is its own job, covered in our note on marketplace category mapping.

Write Turkish and English versions from the attributes, not by translating one into the other. Check units and number formats, the formal “siz” in Turkish copy, and that Turkish characters such as ı, İ, ş and ğ survive every export. Native speakers review each language.

Who approves what gets published?

Merchandisers approve every description at first, on a screen that shows the draft next to the attributes it used, with flags and banned-phrase hits highlighted, so a clean draft takes seconds to approve. As a category builds a clean record, review can move to a sample, while new categories, sensitive ranges such as children’s products or electrical goods, and every flagged draft stay under full review. The catalog team fixes missing attributes, the content owner maintains templates and banned claims, and the channel manager maintains channel profiles.

How do you measure quality across a whole catalog?

Run automatic checks on every description: claims mapped to attributes, banned phrases, channel lengths and formats, similarity scores. Then have merchandisers review a sample per category and channel, and track error types: invented fact, missing key information, banned claim, channel rule broken, language error, too similar. Each type points to its fix, whether an attribute, a template or a profile. Outside signals complete the picture: marketplace rejections, returns marked “not as described”, and time to publish a product.

A first category

Pick one category with good attribute data and a merchandiser who cares about it, and run drafts next to the current process. The commerce intelligence page shows how product content fits with answers and returns, and the drafting and checks are built as custom AI software around your product data.