Key points
- Start with one narrow task, not with "AI everywhere". With five processes running at once, nobody can tell which one produced the gain or what broke the quality.
- The default pattern is draft-first: the machine prepares a draft, and nothing reaches a customer or a channel without human approval. Autonomy is granted to individual tasks, and only once the risk is low, measurable and reversible.
- You check quality with a control sample against criteria written down before you look at the output, not by the feeling that the copy "reads fine". The key question: are the errors systematic or isolated.
- Four good starting tasks: product descriptions and variants, catalog translation and localization, attribute mapping and categorization, and feeds per channel.
The data is clean: required fields filled, identifiers unique, and every field has a system that owns it. Time for your first automation. Picture a Monday a month from now: your supplier just dropped forty new products, and instead of blocking two days for descriptions, you open a list of ready drafts and spend an hour reviewing them. You fix six, approve the rest. That is the goal of this chapter.
Along the way there are three decisions:
- Scope: what to launch first.
- Freedom: how much autonomy to give the machine.
- Proof: how to tell it actually works.
The order matters, because the first rollout sets how your team will treat every one that follows.
One narrow task, not "AI everywhere"
The temptation is always the same: the tool is here, so let us switch it on everywhere at once. That is the fastest route to a rollout that nobody can evaluate a quarter later. When five processes start in parallel, no improvement or regression can be attributed to a specific change, and every rule correction touches several tasks at the same time. With one task you get a baseline, a short correction loop, and a real chance that somebody on the team actually owns it.
A good candidate for a first rollout meets four conditions:
- Repetition: it comes back weekly, not quarterly, so the effect shows fast.
- A clear correctness criterion: you can describe in three sentences how a good result differs from a bad one, and two people would judge it the same way.
- Data with an owner: it draws on data that sits in one place and has an owner.
- Reversibility: a mistake can be caught and undone before a customer sees it.
A task whose correctness you cannot describe is not the right first one, however many hours it consumed in the audit.
Draft-first: the machine drafts, you approve
The default setting for every new workflow is one thing: the machine prepares a draft, and nothing reaches a customer or a channel without human approval. This is not distrust of the tool. It is how you turn a risky automation into a process you can control and improve.
In practice it looks like a review queue: a batch of drafts waits in the morning, you go through them, approve some on the spot, edit others, and note the reason behind every edit.
Human edits teach the rules
Those notes are the second, less obvious benefit of draft-first: human edits are the best material for refining the rules. If you are crossing out the same empty phrase for the tenth time in a row, that is not work to repeat an eleventh time, that is a sentence to add to the rules: "do not use phrase X".
After two hundred approved drafts you know from data, not from a hunch, what the machine gets right and what it breaks repeatedly. Every such rule goes into the knowledge hub from the previous chapter and works for good. If you want a starting point, we collect copy-ready prompts and rules for ecommerce tasks in our free AI Library.
Autonomy grows in levels, not in one leap
There are three levels:
- Level 1, item-by-item approval: where every new workflow starts.
- Level 2, bulk approval: after checking a sample, once errors are rare and isolated.
- Level 3, running without approval: with monitoring and a fast rollback. Reserve this level for tasks where the risk is low, measurable and reversible.
How do you know it is time to move up? From numbers, not from the impression that "it has been fine lately". The simplest measure: the share of drafts approved without edits. It tends to start low, but if the rules really learn from the edits, it grows batch by batch. Once two consecutive samples show no systematic errors, bulk approval is safe.
Autonomy is granted to tasks, not to tools. The fact that an automation handles descriptions beautifully in one category does not mean it will handle technical specs in another, where every number counts. You set the level of oversight per task, and sometimes separately for sensitive parts of the assortment. A single global setting of "we trust the tool" is the shortest path to a mistake your customer sees first.
Four workflows worth starting with
The four tasks below are a good start because they repeat weekly, they have clear correctness criteria, and they use the data you have just put in order. Do not launch them together. Pick one, get it stable, then add the next.
Product descriptions and variants in your brand voice
- What the machine does: assembles a draft from attributes that exist in the catalog, keeps the structure and length uniform, handles variants from one pattern, and respects your list of forbidden claims.
- What stays with you: brand voice, everything absent from the data, and sensitive categories: supplements, cosmetics, products for children.
- The most common mistake: starting before the attributes are in order. The outcome is predictable: flowery copy without a single concrete fact or, worse, a spec invented along the way. The second mistake is one generic prompt for the entire catalog, after which every description sounds identical.
The writing craft and the acceptance criteria are in the piece on AI-assisted product descriptions.
Catalog translation and localization
- What the machine does: translates descriptions and attributes at volume, holds to a glossary, preserves the field structure, and detects untranslated fragments.
- What stays with you: the decisions a model should not make alone: units and size charts, category naming in the target market, legally required wording.
- The typical mistake: confusing translation with localization. Size 38 stays 38 after translation, while in another market it means a different number. That is not a job for a language model but for a conversion rule in the data.
Quality is judged by someone who knows the target market, and the criterion is not "is it understandable" but "does it read like a store from this market and do the specs match".
Attribute mapping and categorization
- What the machine does: proposes a mapping of internal categories onto the channel taxonomy, assigns attributes using the dictionaries from your data cleanup, and flags ambiguous cases instead of guessing.
- What stays with you: resolving the ambiguous cases and approving the mapping as a reusable rule, because a mapping is an asset, not a one-off output: set once, it serves the next export and the next channel.
- The most common mistake: approving in bulk because "ninety percent looks right". The remaining percentage is usually the unusual or expensive products, filed under a category where nobody looks for them.
Take your sample from the edge cases, not the obvious ones.
Generating and validating feeds per channel
- What the machine does: translates the catalog into the fields a channel requires, validates types and values, and flags the offers most likely to be rejected before you upload the file.
- What stays with you: the current channel spec from official documentation, decisions about gaps that cannot be derived from the data, and sign-off on publishing.
- The typical mistake: treating a feed as a one-off task while the catalog changes daily.
This is the only one of the four workflows with a hard external quality measure: the number and causes of rejections on the channel side against the previous upload. The full process, step by step, is in the piece on preparing a marketplace feed.
The table below collects the four tasks into one cheat sheet. The second column matters more than it looks: it decides whether the rollout removes work or merely moves it onto somebody else.
| Workflow | What stays with the human | Quality measure | Typical rollout mistake |
|---|---|---|---|
| Product descriptions and variants | Brand voice, claims absent from the data, sensitive categories | Share of drafts approved with no factual edits | Starting before attributes are in order, one prompt for the whole catalog |
| Translation and localization | Units, size charts, naming and legally required wording | A sample judged by someone who knows the target market | Translation instead of localization (sizes, units, categories) |
| Attribute mapping and categories | Resolving edge cases, approving the rule | Accuracy on a sample of rare nodes, not obvious ones | Bulk approval because most of it looks right |
| Feeds per channel | Current channel spec, non-derivable gaps, sign-off on publishing | Number and causes of rejections against the previous upload | Treating the feed as a one-off task |
The pattern across the whole table: the machine prepares and flags, the human resolves and approves.
A control sample instead of nodding along
Quality is not assessed by scrolling through the output approvingly, because model-generated copy almost always "reads fine". You need a control sample with the criteria written down in advance. The procedure has three steps:
- The sample: twenty to thirty items at random plus a few deliberately hard ones.
- Criteria before judging: before you look at the results, write down what has to be true for an item to count as good: consistency with the attributes, no claims absent from the data, the correct category, the right format.
- Item-by-item judgment: pass or fail, noting the type of error rather than a general impression.
You read the result in one way: separate systematic errors from isolated ones. Systematic errors share a cause, so you fix the rule, the dictionary or the data and repeat the sample. Isolated and rare errors mean the workflow is ready for bulk approval.
That distinction is the entire value of the exercise, because fixing isolated errors with a rule breaks the rest of the catalog, and fixing systematic errors by hand is work without end.
When to add the next task
You launch the second task once the first one is stable, meaning two consecutive samples showed no systematic errors, and once it has an owner on your side who runs it.
You pick the next one from the same audit queue, ideally something that reuses rules you already set: category mapping feeds the channel files, the translation glossary comes back into descriptions, attribute dictionaries serve everything at once. That is how a system grows instead of a pile of unconnected automations. A separate question is who watches quality day to day and where the machine's discretion ends, and that is what the next chapter covers.
Questions
Which workflow should you start with when everything feels urgent?
The one that is most repetitive and has the hardest correctness criterion. In practice that is often feeds or attribute mapping, because an external measure judges the result: the channel either accepts the offer or rejects it with a stated reason. Descriptions and translation can be harder to start with, since they require agreeing on voice and acceptance criteria first, and without those, quality judgments diverge between people.
Will AI-assisted descriptions hurt your store visibility in search?
The risk does not come from using a tool, it comes from the output. Duplicated or generic descriptions, or ones containing specs that are absent from your product data, do damage regardless of who wrote them. A description built from real attributes, checked before publishing and distinguishing variants, is simply a good description. No working method guarantees rankings or traffic, either.
How many items should a control sample contain?
Twenty to thirty random items plus a few deliberately hard ones is enough to tell a systematic error from an isolated one, which is the point of the exercise. You do not need statistical significance, you need a repeatable procedure. Once a workflow is stable you drop back to a smaller sample each cycle, for example on every larger upload to a channel.
