The problem
The catalog is the constraint
A product record starts life in three or four systems at once. An ERP with codes and no copy. Supplier files in whatever shape the supplier felt like sending. A PIM built to hold specifications rather than to sell them. A spreadsheet holding the hand-offs together, maintained by the one person who understands it.
None of that is wrong, and replacing it is not the job. The problem is narrower: the fields that decide whether a product is found and bought, fit, material, dimensions, the variant it belongs to, the category it sits in, are the fields no system owns. So they get typed in by hand, once per channel and once per market, by the team that is already the constraint.
The cost shows up in assortment. Every channel and every market that needs the same fields retyped is a channel that opens later, with less of the catalog on it. Everything above this layer reads from the same records, so fixing the record once is what makes the other seven areas cheap.
Common use cases
The jobs on the record
A few of the ones that run here. Each is a single workflow with its own output and its own numbers, and a job you do not see named is usually a variant of one that is. Run one, or run the set.
Product onboarding
A supplier file in, a sellable product out
Twenty suppliers, twenty formats: an XML feed, a CSV dropped on SFTP, an API, a spreadsheet somebody maintains by hand. Every field is mapped onto your own attribute model and normalized on the way in: currency on price, category paths flattened, image URLs rewritten, and a field with no home is flagged rather than quietly dropped. The specs the supplier left blank, fit, material, compatibility, get read off the product imagery and the datasheet, then recovered from sources online and cross-checked. Every value carries where it came from.
CommerceClarity agent · Apparel EU
The feedback loop
Every correction makes the next run better
Your team judges the output. A value is right, or it is wrong and gets fixed once. Each verdict changes the next run: the score on your own sample moves, and the agent starts from what the last one learned. So the share of values that need a person keeps falling, measured on your catalog and your rules rather than on an average of everybody else.
How we work
Live on your catalog in weeks, not months
We run all four phases with your team, on the stack you already have, and each one ends with a number you agreed in advance.
- 01
Design
We map how your data comes in and how the result goes back out, then agree the business KPI the agent has to move.
- 02
Implement
We build the agent and test it on a sample of your own catalog, agreed with you. Every change is scored against that sample, so the tuning runs on numbers.
- 03
Prove
Done means the KPI reached target on the full catalog, and you have seen the numbers yourself.
- 04
Evolve
We stay on the account. Your corrections keep improving the agent, the KPI holds where you need it, and the next use case starts from the context this one already built.
Enterprise, on a catalog you cannot break
It runs on the stack you have
It reads your PIM, ERP and DAM through their APIs and writes the result back to them.
A person approves everything that publishes
Every value is checked against your rules, and anything uncertain goes to review before it reaches a channel.
Your data stays yours
Your own isolated workspace. It is never pooled into shared models, and you can export it at any point.
Every run is logged
Each value carries its source, its run and its score, so you can see why a wrong one went wrong.
Questions
What retailers ask us
Who runs the agents, us or you?
We do, on your data, category by category, and we stay on the account after go-live. What you are buying is the outcome on your catalog, not a licence and a manual.
Do we have to replace our PIM or ERP?
No. The agents read your PIM, ERP and DAM and write back to them. We sit on top of the stack you already run, and mapping how data enters and leaves is the first thing we do.
What if the agent we need does not exist yet?
Most of these already run for another retailer and adapt to your catalog, and that adaptation is part of the service. Where a workflow is not covered, we design the agent with you and scope it separately.
How do you know the output is right?
The KPI, agreed before any build, says whether the business moved on the real catalog. Underneath it we score the work itself against your rules on a sample of your catalog, and that score re-runs on every change.
Whose data is it?
Yours. The corrections your team makes are what the agents learn from, and both the data and the corrections stay exportable at any point.