Tecof • September 14, 2026
Writing Product Descriptions with AI: Optimise 1,000 Products in an Hour
In Brief
Generating descriptions for a thousand products in an hour is possible; getting them publish-ready in an hour is not. In bulk work most of the time goes not into generating text but into the data preparation before it and the review after it. The real gain is this: work that takes 200 hours by hand comes down to 12-15 hours when set up properly. As of 2026 the question is not "can AI write descriptions" but "do we have the product data the description has to stand on".
Monday morning, 09.30. The catalog holds 1,040 active products. You open ten at random: six have descriptions copied verbatim from supplier catalogs, two are a single sentence, one is empty, and one carries another product's dimensions. The same text sits on three competitor sites; Google cannot decide which to prefer and ranks none of them.
The problem here is not writing, it is scale. A copywriter working through 1,040 products at twelve minutes each is 208 hours — roughly six full-time weeks. By the end of those six weeks the season has turned and a fifth of the catalog has been replaced. That is why bulk generation is a necessity rather than a convenience.
What the "One Hour" Actually Covers
The hour in the title is the time the model spends producing a thousand descriptions, and it is accurate. It is not the project duration. The breakdown below is what a mid-sized catalog typically looks like in practice.
| Stage | What happens | Typical time | Delegable |
|---|---|---|---|
| Data preparation | Collecting attribute fields, closing gaps | 6-8 hours | Partly |
| Template and prompt | Writing the pattern, testing on 20 | 2-3 hours | No |
| Generation | The bulk run | 1 hour | Yes |
| Automated checks | Length, banned words, similarity | 1 hour | Yes |
| Human review | Sample plus high-risk categories | 3-4 hours | No |
Thirteen to seventeen hours in total — about a twelfth of the manual job. That is where the gain sits; the "one hour" is only the generation step and means nothing on its own.
The Prerequisite: Product Data
In bulk generation, output quality is decided by the fields you hand the model, not by the model. If all you have is a product name, the model invents the rest, and what it invents comes back as returns.
The minimum fields each product needs
- Category and subcategory: sets the tone and which attributes lead.
- Three distinguishing attributes: concrete data such as material, dimensions, capacity, compatibility.
- Intended use: who uses it and in what situation. The benefit sentences come from here.
- Banned phrases: category-specific regulatory limits (health claims in cosmetics, treatment promises in food).
- Brand voice note: a one-sentence description of tone, the same across the catalog.
These fields cannot be assembled on top of a messy SKU structure; it has to be clear which variant belongs to which product. Fixing the SKU structure is the step before this one, not a parallel one.
What if the data is missing?
Three options, all legitimate. First, request the missing fields from suppliers in bulk. Second, have a vision-capable model extract the attributes readable from the product image, then put them through human approval. Third, leave those products out of the queue until the data exists. The one thing not to do is generate on incomplete data and tell yourself nobody reads it.
A Description Template That Works
The most common catalog mistake is letting the model write freeform for every product. A fixed skeleton improves both quality and reviewability.
The first two sentences: what it is and who it is for
A visitor stays on the page for a few seconds. The first two sentences must say what the product is and who it suits. "Made from quality materials" says neither, and belongs on the banned-phrase list in your prompt.
Attribute-to-benefit mapping
Each attribute is written with what it does for the buyer: not "1,200 W motor" but "1,200 W motor — grinds hard-shelled nuts in one pass". Do not expect the model to do this unprompted; the instruction "pair every attribute with a one-sentence benefit" has to be in the prompt.
The spec table, and what stays out of it
Dimensions, weight and material go into a table rather than prose: it reads better and can be exposed to search engines as structured data. Stock status, price and campaign details never go into the description — the moment they change, the text starts lying.
SEO and character limits
Let the target keyword appear once in the title and once in the first paragraph; more brings nothing. Write the 60-character meta title and 155-character meta description limits into the prompt itself. Why those particular numbers is a subject for its own piece.
| Section | Length | Must contain | Must not contain |
|---|---|---|---|
| Opening | 2 sentences | What it is + who it suits | Generic praise |
| Benefit paragraph | 60-90 words | Attribute-benefit pairs | Attributes not supplied |
| Bullet list | 3-5 bullets | Concrete data | Repeated phrasing |
| Spec table | 4-8 rows | Dimensions, material, compatibility | Price, stock, campaigns |
| Meta fields | 60 / 155 characters | Keyword once | Exceeding the limit |
The Batch Workflow
Running all thousand in one pass is tempting and wrong: if something is off, you are fixing a thousand at once. Batching gives faster correction and less waste.
Batches of fifty
Make the first batch fifty products spanning easy, medium and hard cases. Review the output against acceptance criteria and record the pass rate. Below 70 percent, fix the prompt and rerun the same fifty. Once you clear 90 percent you can run the remaining batches back to back.
Automated checks
Every output should pass a few simple checks before it reaches a human. These are small pieces of engineering that catch most of the errors.
| Check | What it catches | Action |
|---|---|---|
| Character limit | Overlong meta fields | Regenerate automatically |
| Banned-word list | Non-compliant claims | Queue for a human |
| Similarity score | Near-identical descriptions | Swap examples, regenerate |
| Field matching | Another product's dimensions | Stop, fix the data error |
| Competitor brand names | Unwanted brand mentions | Strip automatically |
The similarity check matters most: if fifty products in one category read the same, search engines see little difference from duplicated content. The fix is a different example set per batch, plus making product-specific fields mandatory.
Importing and rolling back
Do not write generated text straight to production. Do a dry run first to see how many records change, keep the old descriptions somewhere, and build the rollback path up front. We covered the API side of this flow in the integrations piece; having an agent do it itself within a permission ceiling belongs to agentic commerce.
Marketplace Copy Cannot Be the Same Copy
Sending the same description to your own site and to marketplaces creates two problems. First, marketplaces require category attributes and process freeform text under different limits. Second, when your own page carries the same text as the marketplace listing, you lose your own page to the marketplace in search.
The practical fix is to produce two outputs from the same product data: a longer, benefit-led piece in your own voice for your site, and a shorter, attribute-led piece that meets the rules for the marketplace. Two variants of the same prompt do this without needing extra data.
A 30-Day Plan for 1,000 Products
The one hour of generation is a small box inside a thirty-day project. Here is how the calendar works.
Days 1-7: data audit
Export the catalog and fill in three columns: is the category right, are there three attributes, is the imagery adequate. Products with all three are your first wave. No copy is written this week.
Days 8-14: template and first batch
Write the template, build the prompt, measure on fifty products, revise once, measure the same fifty again. The week's output is an approved template and a measured pass rate.
Days 15-21: generate in waves
Start with the 200 highest-traffic products, then work down by revenue. Run the automated checks after each wave and do human review on a sample. Products with missing data wait at the back of the queue.
Days 22-30: measure and hand over
Compare click-through and conversion on the optimised pages against the prior period — SEO effects take weeks to show, so be patient. Then answer this: who produces the description for the next new product, through which flow? Without an answer you are back here in six months.
Here is the job for tomorrow morning: pick twenty products at random and try to fill in "category, three attributes, intended use" for each. How many you get stuck on tells you the real duration of your project. On a platform where product data and content generation sit in the same dashboard, most of this step arrives already done.
Frequently Asked Questions
Does a thousand products really take one hour?
The generation step does; the project does not. With data preparation, template work and review, the realistic figure is 13-17 hours. That is still about a twelfth of the manual job, so the promise is not exaggerated — it is just incompletely told.
Does AI-written product copy hurt SEO?
What matters is originality, not production method. Copying supplier text hurts; so do fifty descriptions cut from the same pattern. Text generated from product-specific data that genuinely differs between items does not cause problems.
How many words is ideal?
It varies by category. For simple consumables 80-120 words is enough; for technical products and apparel 150-250 works better. Look at structure before length: is the information needed to decide actually on the page?
Should I overwrite existing descriptions?
Never without keeping the old ones. Store the previous text, change in waves, and watch conversion on the first wave. In some categories the old copy may be performing better than expected.
For a multilingual catalog, translate or rewrite?
Rewriting in the target language from the same product data beats translating the Turkish. Translation carries Turkish-specific phrasing and search habits; rewriting works with the terms the target market actually searches for.
What happens if the model writes an attribute the product does not have?
The customer buys for that attribute and returns the product, and leaves a negative review as well. There is one countermeasure: the constraint "use only the attributes given" in the prompt, plus an automated check of output against the source fields.
Is sample-based review enough?
In low-risk categories, yes — a 10-15 percent sample does the job. In tightly regulated categories such as cosmetics, food, baby products and electronics, every output should be read. Splitting risk by category halves total review time.
How many people should run this?
One is enough: the person who writes the template, sets the acceptance criteria and manages review. If a second person is needed, it is usually on the data side rather than the copy side.
How do you keep the flow going for new products?
Make it impossible to create a product record before the mandatory fields are filled, and trigger description generation when they are. Then "bulk optimisation" never has to happen again; the process runs by itself.