Writing product descriptions with AI

How the bot works

Nine steps. Reading the fields, checking the claims against them and queueing the drafts are ordinary code and cost almost nothing to run; the model is only asked to turn attributes you already have into sentences.

1. It starts from your own product data. The spec sheet, the attribute table, the export out of your catalog, the supplier's document, the dimensions somebody keeps in a spreadsheet. Not the open web, and not a photograph of the box.

2. It reads the fields before it writes a sentence. Which attributes are there, which are blank, which two sources disagree about, which units need converting, which values look like a template nobody filled in. The blanks are the output that matters first.

3. Every claim names the field it came from. A dimension, a material, a capacity, a certification, a compatibility — each one is traceable to the attribute it was written from. A reviewer can check a sentence without opening the catalog beside it.

4. A missing attribute is a gap, not a sentence. If the weight is blank, the copy does not say it is light. If nothing records the warranty, no warranty is implied. The gap goes on a list with the product and the field named, because a confident sentence about a spec nobody has is the one you end up standing behind.

5. Your words, and the words you never use. House vocabulary, the phrases legal struck out last year, the competitor names that never appear, the required disclosure for a category. The banned list is a rule in the pipeline, not a hint in a prompt.

6. One product, every field your platform asks for. The long description, the short one, the bullets, the title, the attribute summary, the meta description — written together from the same facts, so they cannot contradict each other three screens apart.

7. A variant family stays one family. Sizes, colors and pack quantities inherit the parent's facts and differ only where the attributes differ. Nobody has to notice that one color got a longer sentence than the others.

8. A person approves, in bulk or one at a time. Drafts land in a queue with the flagged claims and the gaps at the top. Approve a batch, edit a sentence, send one back — and what goes into the catalog is the version somebody approved, not the version the model produced.

9. It tells you what it would not write. The products it refused, with the reason: no usable attributes, two sources that disagree, a claim on your banned list, a category that needs a qualified reviewer. That list is the useful output in the first week.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your sources

Which systems and documents count as product truth, which one wins when two disagree, and what is out of bounds entirely.

Your words

The house vocabulary, the tone, how you refer to the customer, and the phrases that read as somebody else's brand.

Your banned claims and required disclosures

The words legal removed, the comparisons you do not make, and the disclosure that has to appear on a category whether the copy mentions it or not.

Your length and format

How long each field runs, whether bullets come before prose, what the title template is, and which fields your platform requires.

Your fields, and which ones lead

Which attributes belong in the first sentence for which category — the load rating for a bracket, the fit for a part, the fabric for a shirt.

Your variant rules

What a size or color may change in the copy, and what it must inherit from the parent untouched.

Your categories that need a qualified reviewer

Food, supplements, children's products, anything electrical or medical, anything with a certification — routed to a named person instead of written confidently.

Your approvers

Who may approve a batch, who may approve a single product, and which categories only one named person signs off.

Your release switches

Which categories may be drafted automatically, which require a gap list cleared first, and which never publish without a second reader.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every sentence shows the field it was written from, every gap says which attribute was missing, and every approval records who approved that version. A description can be audited against your own product data rather than taken on trust.

Versioned prompts you can tune yourself

The vocabulary, the banned-claims list, the field priorities and the prompts behind turning attributes into sentences are yours to tune. A change is a reviewable diff, replayed against products you have already approved so you can see exactly what it would have written differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Reading the fields, drafting, checking the claims against the data and queueing are automatic. Deciding what your product is, resolving the gaps, approving the copy and publishing it are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per product and one per draft: the sources and fields it read, every claim with its field, the gaps, the flagged phrases, who approved it and what changed — plus token usage and cost for that run.

It can be configured to run in any business. The data, the words and the rules are yours: your sources, your vocabulary, your banned claims, your categories, your approvers. The catalog wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This writes into the catalog you already run. We're not selling you a product content platform, and the copy stays yours in a format you can export without us.

• Shopify
• WooCommerce or WordPress
• BigCommerce or Magento
• A PIM or product catalog tool
• NetSuite
• An ERP product master
• Amazon or another marketplace
• A supplier feed or price list
• A spreadsheet the buyer keeps
• Supplier PDFs in a shared folder

Works well for

• Furniture and home goods sellers — Dimensions, materials and assembly facts live in a spec sheet, and the listing has to match it.
• Auto parts sellers — Fitment is the whole description, and a compatibility nobody checked is a return.
• Apparel and footwear brands — Fabric, fit and care copy repeats across a size and color grid that has to stay consistent.
• Food and beverage brands — Ingredients, allergens and net weight are facts on a label, and the copy cannot drift from them.
• Wholesale distributors — Catalogs arrive as supplier feeds, and the same part needs your words rather than theirs.

How a rollout works

Nothing publishes on day one. The first milestone is a batch of your own products described twice — by the bot and by whoever writes them now — so you can compare before anything reaches a storefront.

1. 01Discovery

   The quote call, then a working session. We go through your product data, which source wins, your vocabulary and banned claims, the fields each category leads with, who approves, and which categories need a qualified reviewer. You get the field map, the rules and a written scope.

2. 02Dry run

   A batch you choose, described against your real data. Nothing is published. You read the drafts, the claim-to-field trail and the gap list — and the gap list is where the work is, because a blank attribute stays invisible until somebody writes a sentence about it.

3. 03Assisted mode

   Live on a category you pick. The bot drafts, a person approves in the queue, and your writer edits instead of starting from a blank field. Who owns the catalog does not change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of categories you name, drafted and queued automatically with the gaps cleared first, still unpublished until somebody approves, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No conversion, ranking, traffic or products-per-hour figure. We haven't written yours. What a batch takes and what it costs come out of the dry run, and they will be your numbers.
• No customer claims on this page. No names, no case studies, no logos.
• It cannot know what is not in a field. A model can write, structure and shorten. It cannot know the tolerance nobody recorded, the finish the supplier changed in March, or which of two spec sheets is current. That is why a gap is a gap.
• Good copy is not the same as a good listing. Photography, price, availability, reviews and the category page all do work a description cannot do. This fixes the words, and it does not claim to fix the rest.
• Somebody still has to read it. The review queue is the honest part of this build. If nobody is going to approve a batch, a catalog full of confident sentences nobody checked is worse than the empty fields you have now.

Questions people ask

Can AI write our product descriptions?

Yes, from your own product data. Give an agent the spec sheet, the attribute table or the catalog export and it can write the long description, the short one, the bullets and the title in your words and your format, with every claim traceable to the field it came from. What it will not do is fill a blank attribute with a plausible sentence - that comes back as a gap with the product and the field named.

How is this different from the generator built into our store?

The difference is where the facts come from. A generator takes a title and some keywords and writes around them, and the platform's own documentation says the output can include benefits you never listed and facts drawn from other published content about similar products. This writes only from fields you own, names the field behind each claim, and refuses rather than borrowing - and it holds the result for a person instead of publishing it.

What stops it from inventing specifications?

A rule rather than good intentions: a measurement, material, capacity, certification or compatibility has to come from a field in the data, and anything else is a gap on a list instead of a sentence. Your banned-claims list is checked in the pipeline, not suggested in a prompt, and a category you mark as regulated is routed to a qualified reviewer before anybody reads a draft.

Will this help our SEO?

We make no ranking or traffic claim, here or in a quote. What this does is fill the fields your platform asks for - the title, the meta description, the attribute summary - consistently, from your own data, on products that currently have nothing or have somebody else's copy. Whether that moves anything is measured in your analytics, by you.

Can it do our whole catalog at once?

It can run a batch as large as your data supports, and the queue is built for approving in bulk. The limit is not the writing - it is how many descriptions a person is willing to approve, which is why the gap list and the flagged claims sit at the top of the queue and why a first run is a category rather than everything.

Can it sound like us?

That is the configuration, not a prompt flourish. Your vocabulary, your sentence length, how you address the customer, what you call a feature, the phrases that read as a competitor, the words legal struck out. The dry run exists so you can read it in your own voice before anything is live.

What about the copy our suppliers send us?

A supplier document is a source for facts, not a draft to publish. We read the attributes out of it, record it as the field's source, and write your sentences - and if the supplier's sheet disagrees with your own catalog, that is a hard stop rather than a coin toss.

Who approves a description?

Whoever owns the category. Drafts land in a queue with the gaps and the flagged claims first, and approval is recorded against that version of the text. Nothing reaches a storefront, a feed or a marketplace listing until somebody approves it, and a regulated category can require a named reviewer on top.

Is there a record of what it wrote and why?

Yes, per product and per draft: the sources and fields it read, every claim with the field behind it, the gaps it reported, the phrases it flagged, who approved it, what changed from the previous version, and the token usage and cost for that run.