Four Shapes of Catalogue Tool, and What Each One Asks of You
There are four shapes a tool can take when your catalogue has problems in it. An audit tells you where they are. A bulk editor lets you change many things at once. A rule engine lets you write the logic once and apply it everywhere. A draft-then-approve tool writes the specific change and stops for your answer.
They are not four quality tiers, and picking badly is expensive in a way that has nothing to do with whether the tool is good.
The useful question is not "which is best" but what does this shape make me spend? Attention, typing, rule maintenance, or per-item judgment — four different budgets, and most stores have a lot of only one. What follows argues from how those four shapes divide the labour, not from a trial: we have not run one catalogue through four tools and compared the outcomes.
If you only have a minute, the whole decision is one question asked twice. Is the right change the same for every affected product? If yes, you want a bulk editor — or a rule engine, if it will still be the same change a year from now and somebody will own the rules. If no, do you care what each one says? If yes, you are in the fourth shape and the price is that you look at them; if no, an audit will at least tell you the size of the problem. The longer version, with the edge cases, is further down.
The four shapes side by side
| Shape | What it gives you | What it asks of you | When it's the right one |
|---|---|---|---|
| Audit / report | A list of what's wrong, with locations | Attention, then all the work. The findings are yours to act on | You don't yet know what's broken, or you need a defensible inventory of it |
| Bulk editor | The ability to change many records in one pass | Typing and decisions. You still supply what each change should be | The change is mechanical and uniform — a prefix, a price rule, a field swap |
| Rule / template engine | Consistency, applied automatically to everything matching | Rule maintenance forever. Rules drift, collide, and need owners | Your catalogue is genuinely homogeneous — hundreds of SKUs in one shape |
| Draft-then-approve | The specific change, already written, waiting on you | Per-item judgment. You look at each one | Items differ enough that the right change is different each time |
The four shapes differ less in what they can do than in which of your resources they consume.
Shape by shape
The audit
An audit reads your catalogue and returns findings: which products have thin descriptions, which have no product type, which categories are empty.
This is genuinely the right tool when you don't know what's wrong — which is most stores, most of the time, especially after a migration or a stretch where several people had admin access and nobody kept notes. You cannot prioritise a catalogue you haven't measured, and turning vague unease into a shape and a count is real work somebody has to do.
What it asks of you is attention, and then everything else. The output is a list, and a list is a set of jobs assigned to you. The finding "this description is thin" does not contain the replacement description. Locating was the cheap half.
The failure mode is worth naming: an audit that returns the same count next month is not broken. It finished its job and handed you yours. More on why a report leaves the expensive half with you.
There is also a case where the list is the deliverable and nothing further is needed — a migration check, a pre-launch sweep, an answer to "did the import land cleanly." There you want findings, not changes, and a tool that started editing would be the wrong tool entirely.
The bulk editor
A bulk editor lets you select a set of products and apply a change to all of them in one pass, instead of opening records one at a time.
When the change is mechanical and uniform, this is the correct tool and nothing else comes close. Adding a supplier prefix to a batch of SKUs. Moving products into a category. Raising prices on a vendor's line. Clearing a field that shouldn't have been populated. In all of these the right change is the same change for every row, and you already know what it is. A tool that stopped to ask about each one would be actively worse — it would convert a single decision into hundreds of identical confirmations.
What it asks of you is typing and decisions. It removes the repetition of applying a change, not the work of deciding what the change should be — and when the right value differs per product, it can't help with that at all. The efficiency comes entirely from the changes being identical. Feed it a job where every row needs a different answer and you've bought a faster way to type the same amount.
The boundary is easy to test before you commit. Ask whether you could hand the job to someone who has never seen the catalogue, with one sentence of instruction. If yes, it's a bulk edit and you should do it that way. If the instruction has to end with "…and use your judgment on the rest," you've left the shape.
The rule or template engine
A rule engine lets you write the logic once — if a product has no description, compose one from the title, material, and category — and applies it to everything that matches.
When your catalogue is truly homogeneous, this is unbeatable. Hundreds of SKUs in the same family, differing in size and colour, described by the same fields in the same order: a template will produce better and more consistent output than a person typing each one, and it keeps producing it as new variants arrive. Consistency is the whole product, and here consistency is what you want.
The cost has two parts, and the second surprises people.
The first is sameness. A template produces template output. Where every product genuinely is a variation on one thing, nobody minds. In a mixed catalogue, it makes your differentiated products read like your commodity ones.
The second is maintenance, which is permanent. A rule set is code, and it needs an owner. Rules drift out of alignment as you add lines that don't fit the shape, they collide in ways that only surface on particular products, and whoever wrote them eventually leaves. The cost isn't the afternoon spent writing the rules. It's every month after that.
That cost is often worth paying. A rule that stays correct is the cheapest thing in this comparison per product touched, and it gets cheaper as the catalogue grows — the opposite of everything else here. The question is only whether your catalogue actually holds still enough for a rule to stay correct.
The fourth shape
The fourth shape sits in a specific gap: what do you do when the right change genuinely differs per item, but you don't have time to compose each one?
An audit won't do it: reporting is the whole of what it does. Neither will a bulk editor, because you are the one supplying the words it applies. And a rule engine is built on the premise that one rule fits everything, which is exactly what isn't true here.
So: compose the specific change for the specific item, then stop and show it to the person.
Arvio is an AI store operator. It reads your live catalogue, writes the actual change for one actual product, and then does nothing until you say so.
There is also a difference the four-way table above does not capture, because it is not a difference in shape: who speaks first. The other three wait for you to start — you go run the audit, you go select the batch, you go write the rule. This one reads every product nightly and writes each fix with nothing for you to ask or prompt. What arrives in the morning is a set of drafts you did not have to think to request. The change arrives written — not described, not suggested — in an editable box you can change before agreeing to it.
The scheduled half of that — the reading it does overnight, without you — is the product's own scope, listed under Shopify's Scheduled tasks category. The run we recorded below is not that: it is a single product we triggered by hand, and it is the only part of this we measured ourselves.
On a run we recorded against our own demo store, a product whose stored description was 62 characters came back with a replacement already drafted. Nothing had been written to the store yet. (The replacement ran 361–364 characters, depending on whether you count the markup.) What was on screen was a confirmation card, and its scope line read:
Only this product will be updated — all others left untouched.
After the button, the result card says ✓ Description updated, and then:
This action can be undone. Let me know if you'd like to revert it.
That sequence — written, scoped, refusable, reversible — is the shape this article has been describing. One run on our own store is enough to show you what the sequence looks like; it is not evidence about how good the drafts are, how it behaves on a catalogue we have never seen, or what happens on the two-hundredth card. Those are the questions worth asking, and a single recorded run does not answer any of them. We've walked through what one of these changes looks like on screen.
What this shape costs
It costs you per-item judgment. You have to look at each one.
That is a real tax. The approval is the point of the design, which makes it the bottleneck, and the bottleneck does not shrink as the catalogue grows.
We can put one honest number against the machine's half of that and none against yours. In the run we recorded, Arvio's own progress line read Plan complete 39s before the card appeared. Your half is the part that scales: reading a draft properly is a minute or two, and two hundred of them is not two hundred minutes of the same quality — attention degrades, which is the actual failure mode of this shape. We have not measured where that degradation starts, and we are not going to quote a products-per-hour figure we did not measure.
So, plainly: if your changes are mechanical and uniform, a bulk editor is faster and you should use that. Not "faster in some cases" — faster, straightforwardly. Approving several hundred identical prefix additions is a worse design than one selection applied once. The same goes for templates on a catalogue that genuinely is one family in many variations.
The gap this shape fits is narrow: items that differ enough that the right change differs, in a catalogue where you still care what each one says.
How to tell which one you need
Four questions, answerable without installing anything.
1. Do you know what's wrong? If no, start with an audit regardless of what comes next. You can't choose between the other three without knowing the shape of the problem.
2. Is the right change the same for every affected product? If yes, you want a bulk editor. Write the change down: if it fits in one sentence that applies to every row, it's uniform. If you find yourself writing "…except for the ones where," it isn't.
3. Would one template produce acceptable output everywhere? If yes, and somebody will own the rules a year from now, a rule engine is the efficient answer. Both halves matter.
4. Does the right change differ per item, and do you care what each says? Then you're in the fourth shape, and the price is that you look at them.
Note what isn't on that list: which tool is best. For many stores the answer is more than one, for different parts of the catalogue. The variants of one product line want a rule; the flagship products want per-item attention; the SKU cleanup wants a bulk editor. Using one shape for all three is the real mistake.
Arvio: AI Store Operator — install it on the Shopify App Store.
Questions
What is actually different about this, compared with the tools I already have?
No — the difference is which side supplies the content. In a bulk editor you decide the new value and the tool applies it across the selection. Here the tool composes the value for a specific product and you decide whether it's right. Opposite divisions of labour. A bulk editor with an approval step would still be waiting for you to type.
Can't a rule engine just write good descriptions too?
It writes consistent ones, and for a homogeneous catalogue consistent is good. What it can't do is produce a different kind of answer for a product that doesn't fit the pattern — by construction it only knows the fields matched. If your catalogue is uniform, that limitation never fires and the rule engine is the better tool.
We already run an audit tool. Does that mean we picked wrong?
Almost certainly not. An audit answers a question the other three don't even ask. The mistake would be expecting it to close the items it found — that was never its job.
How does the per-item cost scale on a large catalogue?
Badly. Approval is linear in the number of items. Don't point this shape at work a rule or a bulk edit would handle.
What if we don't know whether our catalogue is homogeneous?
That's question one again, and the answer is an audit — "how uniform is this catalogue" is an empirical question about your data. The answer is usually partly, which is why allocation matters more than tool choice.