Most teams treat listing production as a writing problem. It is not. It is a chain of decisions, and the expensive part is the joins between them.
Watch how a product actually reaches a marketplace. A buyer selects it. Someone receives a spreadsheet. Someone writes a description. Someone sends it for translation. Someone receives the translation and pastes it into each channel. Someone else handles images. Weeks later, a report says how it sold, and nobody is quite sure what to do with that.
Seven or eight steps, each owned by a different person, each with a wait in between. When teams try to speed this up with AI, they almost always attack the writing — because that is the step that looks like work. But the writing was never where the time went. The time went into the waiting, the re-formatting, the version confusion, and the rework when something upstream turns out to have been wrong.
This is why AI writing tools produce such disappointing results in commerce operations. They make one step faster inside a chain that is limited by everything else.
The chain, and where it actually breaks
Source data. Almost every downstream problem starts here. Attributes are inconsistent between suppliers, units are mixed, categories do not map to what the marketplace expects. A generated description is only as good as the field it drew from, and a wrong field produces a confident, fluent, wrong sentence.
Content production. The genuinely automatable step, and the one everyone focuses on.
Multilingual adaptation. Not translation. A listing that converts in Germany is not a translated version of one that converts in Hong Kong — the objections differ, the compliance wording differs, the search terms differ.
Channel formatting. Every marketplace has its own field limits, image ratios, prohibited claims and category trees. This step is pure friction and it is where copy-paste errors enter.
Publication. Usually manual, usually one at a time.
Performance feedback. Almost always a dead end. The data exists in a dashboard nobody reads before the next buying decision.
Of these six, only one is a writing task. If you automate that one and leave the rest, you have made a 45-minute process into a 38-minute process.
The checkpoint problem
Once the chain is connected, one design decision determines whether the whole thing works: where does the human look?
The instinctive answer is: at the end, before publication. It feels safest. It is the worst available option, for two reasons.
Errors compound upstream. If a supplier's attribute field was wrong, that error is now in the description, the five translations, and the five channel variants. The reviewer at the end is not catching one error. They are catching eleven copies of one error, and fixing all eleven.
End-of-chain review does not scale. At twenty products a week, one person can read everything. At five hundred, they cannot — and what happens is not that they work harder. What happens is that review quietly becomes a formality. People approve without reading, because the alternative is being the bottleneck that everyone is waiting on. You now have a control that exists on the process diagram and not in reality.
A workable design puts control in three places, with different intensities:
Source data, on ingestion
What is checked: Missing or malformed attributes, category mapping, prohibited claims
Intensity: Automated rules, 100%
First market, first batch
What is checked: Does the generated content actually read correctly for this category and this market?
Intensity: Human, 100%
Ongoing production
What is checked: Quality drift
Intensity: Human, sampled — and always at the point where a mistake becomes expensive
The third row is the one people resist, because sampling sounds like lowering standards. It is the opposite. A sampled review that is genuinely performed beats a full review that has degraded into clicking approve. The question is not how much is reviewed but whether the review is real.
“The question is not how much is reviewed but whether the review is real.”
Certain items should never be sampled: anything touching price, regulated claims, safety wording, or a new category entering the system for the first time. Those stay at 100%, permanently.
Closing the loop
The step almost every implementation skips is writing performance back.
A commerce system that produces listings faster is a productivity tool. A commerce system that feeds sell-through, return rates and search performance back into the next round of product selection and content decisions is an operating system. The difference in value is large, and the difference in engineering effort is small — because if you have already connected the chain in one direction, you have the identifiers to connect it in the other.
Concretely: which attributes appear in listings that convert, which claims correlate with returns, which categories consistently need manual rework. That last one is the most useful and the least collected — it tells you exactly where the system is still weak.
What to measure
Four numbers, from the beginning:
Time per listing, end to end — from receiving source data to live on all channels. Not the writing step. The whole chain.
First-pass approval rate — what proportion goes through without structural rework. This is your quality signal.
Exception rate — what proportion leaves the standard path and lands on someone's desk. The most commonly omitted metric, and the one that decides whether the system reduced work or merely relocated it.
Fully loaded cost per published listing — model and infrastructure spend plus human review time. In most commerce workflows the review time is the larger half.
In our own Operating Labs, on an internal test set of 1,200 SKUs, first-draft production time fell from around 45 minutes to under 6 minutes per SKU, and 78% of multilingual drafts passed human review without structural rework. Those are internal lab figures under stated conditions, not client results — but they indicate where the ceiling sits and, more usefully, where it does not: the remaining 22% is the part that determines whether the system is actually worth operating.
When not to do this
If you carry few products at high value, each requiring individual negotiation and bespoke presentation, this is the wrong investment. Writing them by hand is faster and better, and the governance overhead will cost you more than it returns.
The economics turn when three things are true at once: volume is high enough that the chain repeats, products keep arriving, and you are selling into more than one channel or language. Two out of three is usually not enough.
Start with the workflow that matters
If listing production is consuming hours that produce no judgement, that is a workflow worth measuring before automating. This is the chain the AI Commerce System exists to connect and govern.