AI product description generator: where the manual workflow breaks
A catalog with several thousand SKUs hits a limit not in the number of writers but in the throughput of one person.
The copywriter keeps the description structure, set of attributes, marketplace restrictions, and category rules in their head — and reassembles the same thing for every product card. Catalog growth outpaces text growth, and the publication queue grows faster than it is cleared.
The second bottleneck in content preparation is the divergence in marketplace requirements for descriptions. Some cut length and do not allow links, others require filled attributes and a strict title structure, and still others interpret category nesting in their own way.
The same product has to be rewritten differently, and this is no longer creative work but mechanical.
The third layer is the human factor during mass manual card filling. The result comes out uneven: a key parameter is missing somewhere, a paragraph is duplicated somewhere else, and a characteristic does not match the marketplace filter elsewhere.
The card passes review but loses impressions because it does not match the customer's search queries.
Generating descriptions for a marketplace removes all three limitations — but only if it is built not as a “button with text” but as a managed pipeline: data from the accounting system, a template tailored to the requirements of a specific marketplace, automated completeness checks, and a consistent style across the entire catalog.
Below, we break down exactly what the AI product description generator takes on and where humans remain in this process.
What changes after implementation: measurable effects
The effect of implementation is visible not in a generation demo but in the production cycle: how many cards are produced per day, how many are returned for revision, and how much time the editor spends per unit of content. Below are metrics that change predictably.
Card production speed
The description draft is assembled from product attributes rather than written from scratch: the generator inserts characteristics, category, and key queries, and the editor edits the wording.
The average “attributes → finished card” cycle is reduced by 3–4 times, and launching a new category with several hundred SKUs takes days instead of weeks.
Share of rejected cards
The main reason for returns on marketplaces is formal: length exceeded, a required attribute missing, the same text duplicated across fields.
Requirements for the export are checked before publication and configured separately for each channel — Wildberries and other marketplaces have their own rules for field composition and tone. The share of cards sent for revision drops from 15–20% to single digits.
Consistent style and reduced load on editors
Tone, paragraph structure, and attribute order are set by the category profile, so descriptions from different authors read consistently rather than “each with their own voice.” The editor shifts from routine to edge cases — unique products, complex categories, promotional copy.
Manual effort per card drops severalfold, and the catalog scales without a proportional increase in team size.
Generation options: from templates to a fine-tuned model
The approach is chosen based on the state of the catalog, not on how “advanced” the method is.
If characteristics are stored in structured fields, description templates with substitution rules work more predictably: text is assembled from proven blocks, and discrepancies are caught at the attribute level. A model is connected where coherent text for a specific category is needed.
The second criterion is the volume of the moderated catalog and the stability of attributes. Fine-tuning a model on the catalog provides a consistent style and fewer invented characteristics, but it requires reference cards and retraining when the assortment changes.
That is why teams more often settle on a hybrid generation scheme: rules are responsible for facts, and the model is responsible for wording.
| Approach | When it is appropriate | Limitations |
|---|---|---|
| Templates and attribute substitution rules | Attributes are filled, categories are uniform, predictability is needed | Monotonous text; when fields are empty, gaps appear in the description |
| Generation by a base model from instructions with examples | The catalog is new or small, there are few reference descriptions, and publishing is needed quickly | Wording drifts from run to run, invented characteristics are possible |
| Fine-tuning a model on the catalog | There are hundreds of moderated cards and stable attributes | Labeled data is required, as is retraining when the assortment changes |
| Hybrid generation scheme | Large catalog, heterogeneous categories, accumulated rules and examples | Rules, model, and checks are updated together — harder to maintain |
A trial run of candidates on the same set of cards helps with the choice: we count the share of descriptions published without manual edits and the number of returns due to mismatched characteristics.
Generator implementation stages: from data audit to handover
The order of work here is not accidental: the quality of the resulting descriptions is determined not by the model but by data preparation and acceptance rules.
If you skip the catalog audit or do not fix the validation criteria, the generator produces plausible text that category managers then rewrite manually. Below is the implementation plan we follow for a project.
- Catalog and data audit. We export categories, attributes, and card history and find bottlenecks: empty characteristics, discrepancies in units of measurement, duplicates, mismatched brand names, and cards without photos. The result is a data map indicating which categories can have descriptions generated immediately and where normalization is needed first.
- Generation schema and rules. We fix required fields, description structure, tone requirements, and a stop list: no unverifiable claims, third-party brands, or promises that contradict marketplace rules.
- Source preparation. We collect synonym and unit dictionaries, bring attributes to a unified form, and label reference descriptions that the generator will use as examples.
- Setup and integration. We connect the generator to the accounting system or seller account, configure the processing queue, volume limits, and run log so every change can be traced.
- Validation on a control sample. We run several hundred cards from different categories, count the share of descriptions accepted without edits, and analyze deviations. We adjust rules and examples based on results, not impressions.
- Result acceptance regulations. We agree on measurable criteria: share of cards without manual revision, time per card, share of moderation rejections, and completeness of attribute filling.
- Handover and implementation plan. We provide access, instructions, and settings, train responsible staff, and lay out a category-by-category rollout in waves — so errors from the first batches are not replicated across the entire catalog.
Each stage ends with a verifiable artifact, so by handover the client’s team has a working scheme rather than a set of experiments.
What you receive: project artifacts
Project artifacts are not a presentation but a working loop that remains with you and runs without our involvement. Everything is arranged so that the editorial team or content manager can continue independently: settings, rules, dictionaries, and regulations are in one place. You receive:
- Configured description generation — rules for each field: title, list of benefits, characteristics, and a text block for specific categories.
- A library of templates and reference cards — examples for key categories that set tone and structure; results are checked against them.
- Rules and dictionaries — brand names, required characteristics, stop phrases, and marketplace requirements for text length and structure.
- Process diagram — the path from nomenclature export to publication, with marked points: where a person works, where automation works.
- Description moderation regulations — review procedure, acceptance criteria, what to do with a rejected card, and who makes the final decision.
- Quality control rules — metrics: share of cards without edits, completeness of characteristics, repetitions between cards, and measurement frequency.
- Generation documentation — field and dependency descriptions, and instructions for editing rules without a developer.
- Team handover — a walkthrough on your nomenclature, access, responsible parties, and escalation procedure.
The package removes dependence on the contractor: the editorial team can add categories, edit wording, and handle disputed cards on its own. We get involved when the logic changes — a new marketplace, a new content type, or updated requirements.
Case study: how manual card preparation was reduced
Before implementation, a catalog of 18,000 SKUs was managed by three content managers: the card was assembled by hand — title, 5–7 characteristic fields, description, and key queries — and one SKU took 12–18 minutes.
Launching a new line of 400 SKUs stretched over two to three weeks, and descriptions diverged in tone and structure from manager to manager.
We built a pipeline: the supplier export is parsed and normalized against the category dictionary, attributes are mapped to required marketplace fields, generation runs in batches via the OpenAI API with request templates per category, and at the output the text passes validation — length, prohibited wording, repetitions, and presence of keywords. Sensitive categories go to a local model so data does not leave the perimeter.
| Metric | Before | After |
|---|---|---|
| Time per card | 12–18 min | 2–3 min for review and editing |
| Launch of a line of 400 SKUs | 2–3 weeks | 4–5 days |
| Cards accepted without revision | about one third | 84% |
| Consistency of descriptions | unique to each manager | one template per category |
Limitations remain: certificates, composition, medical and legal wording are not approved by the model — a specialist verifies them, so 12–15% of cards go for manual revision.
New categories require template calibration on a sample of 30–50 SKUs, and complex characteristics with ambiguous values are best sent for dictionary labeling — otherwise the generator repeats errors from the source data. Describe your catalog — we will come back with an estimate and implementation plan.
How a fine-tuned model differs from template cards
A template relies on substitution rules: feed attributes are distributed into pre-written phrases. In a narrow category with a dozen stable properties, this is fast and predictable, and the text remains fully controllable.
The limit appears at scale — the number of meaningful combinations is limited, and by the thousandth card, wording begins to repeat verbatim.
You can tell a template is exhausted by symptoms: the share of repetitions within a category grows, approvals break on rare attribute values, and properties outside the table — fit, usage scenario, compatibility — do not make it into the description at all.
This is where the choice arises: a fine-tuned model or a template with an extended dictionary. The second option is justified while there are few attributes and wording must remain strictly fixed.
A fine-tuned model learns from labeled training data — pairs of “feed attributes → manually approved description.” The sample includes the best cards in the category, category manager edits, and separately labeled tone, length, required blocks, and prohibited wording.
One and a half to two thousand vetted examples per category yield generation that does not confuse properties with one another and does not invent characteristics that are not in the feed.
Text quality control moves from the editor’s head into metrics: coverage of required attributes, reconciliation with the feed, share of matching fragments between cards, readability, and absence of marketing noise.
Description uniqueness is calculated within a category, not across the entire catalog — that is precisely where repetitions hurt product visibility. On top, there remains selective manual review and analysis of cards that failed the filters.
Technical questions before project start
Questions at the start usually concern not generation itself but the manageability of the result: who is responsible for uniqueness, where characteristics come from, whether texts will diverge from marketplace rules, and what will happen with a new category. Below is how these risks are closed at the setup level rather than with promises.
Will the texts turn out to be duplicates within the catalog and relative to competitors?
The generator works from structured attributes, not from a single template, so descriptions differ at the level of wording, block order, and emphasis.
On top of that, automated checking works: fragment overlaps within the catalog and reconciliation with public marketplace search results — if the threshold is exceeded, the card is sent for regeneration.
Where do characteristics come from, and what prevents the model from inventing them?
The source of facts is only the filled fields of the card and your value dictionary. If an attribute is empty, the text is built without it rather than with a plausible guess.
At acceptance, we calculate the share of cards where the description diverges from the fields and keep this metric as a target.
How are marketplace requirements met, and what happens when their rules change?
Length limits, required blocks, service labels, and stop words are stored as separate profiles for each marketplace, including Ozon. Validation runs before publication, so a mismatch is cut off at the draft stage rather than after the card is rejected. Updating the profile does not require retraining the model.
What should be done with a new category that was not in the training data?
We label a small sample of reference cards and configure generation on it — this is enough for the style and set of fields to match your line. We check quality on a holdout sample before rollout to the catalog, and the previous setup remains a rollback point.
Let’s discuss your task and come back with an estimate and plan
For the project estimate to be realistic and the implementation plan feasible, it is better to start the conversation not with generalities but with facts about the catalog.
Collecting this in advance requires little effort from you, but we can immediately name timelines for the first phase instead of revising them midway.
- Catalog composition: the number of product groups, cards, and languages for which descriptions are needed. This determines how many generation rules and checks to build in.
- Card samples: ten to twenty descriptions you consider reference, and the same number of poor ones. They show the required style and field structure.
- Data source: nomenclature export with characteristics, availability of photos, and filled attributes. The more complete the source data, the fewer manual edits after generation.
- Marketplace requirements: restrictions on length and field structure, prohibited wording, and required details. We build them into checks rather than catching them after publication.
- Roles and approval: who approves texts and who is responsible for export. Without this, the implementation plan stalls waiting for an answer.
- Acceptance criteria: the share of cards that pass without edits and the allowable percentage of manual revision.
If most of the above is at hand, let’s discuss the task concretely: we will come back with timeline estimates, the composition of the first phase, and a step-by-step implementation plan.
