Why image approval breaks before the catalog does
Image approval is the last step in a product launch and the first one to be skipped. The photographer delivers, someone eyeballs a contact sheet, files go to the CDN, and the product goes live. That works at forty SKUs a season. At four hundred it produces the failure everyone recognises: two products from the same collection sitting side by side on a category page at visibly different scales, on visibly different whites.
The root cause is almost never carelessness. It is that "approved" was never defined as anything a person could check. When approval means "looks fine to me," two reviewers will disagree, the same reviewer will disagree with themselves on a Friday, and nothing that fails can be traced back to a decision. A product image review and approval workflow exists to convert taste into criteria, and criteria into a repeatable pass or fail.
The second-order cost is worse than the rework. Every extra review round pushes a launch date, and a launch that slips past a buying window loses the season, not a week.
Write the spec before you write the workflow
A review workflow without a written image spec is just a queue with opinions in it. Before you route a single asset, put the following in a document that reviewers can open in a second tab. Every line has to be checkable by someone who did not shoot the product.
| Spec item | Bad (unverifiable) | Good (checkable) |
|---|---|---|
| Background | "Clean white" | #FFFFFF, no gradient, RGB variance under 2 |
| Product scale | "Fills the frame" | Product occupies 82-88% of frame height |
| Placement | "Centred" | Centroid within 1% of frame centre |
| Dimensions | "High res" | 2048x2048, sRGB, JPEG q85 |
| Shadow | "Natural" | Contact shadow only, 15-25% opacity |
| Colour | "Accurate" | Delta-E under 3 vs. reference swatch |
| Gallery order | "Hero first" | Position 1 hero, 2 detail, 3 scale, 4 in-use |
The scale and placement rules matter more than they look. Inconsistent product scale is the single most visible catalog defect, because a category grid puts the inconsistency directly next to its own control group. It is also the rule most often left as taste, because measuring it by hand is tedious — which is exactly why it should be enforced by the pipeline rather than by a reviewer's eye.
Attach a reference image to each spec line — an approved asset that passes. Reviewers calibrate against examples far faster than against numbers, and the numbers settle the arguments the examples cannot.
Separate the three kinds of review
Most approval bottlenecks come from asking one person to do three incompatible jobs in one pass. Split them, and the queue stops stalling on the most expensive reviewer.
Technical review checks the measurable spec: dimensions, colour space, file size, background value, scale, filename convention. Nothing here requires judgement, which means nothing here requires a person. This tier should be automated, and anything that fails should never reach a human.
Brand review checks whether the image belongs in the catalog: styling, prop choices, crop feel, whether the shot communicates the product's actual character. This needs a person with authority, and it should only ever see assets that already passed the technical tier.
Commercial review checks the facts: is that the right colourway, the right variant, the right season, the right claim. This is the merchandiser's or product owner's job, and it is the review most often skipped, because it is the least visual. It is also the one whose failures cause returns.
Single-pass review
- One reviewer, three job descriptions
- Brand lead spends time checking pixel dimensions
- Failures batch up until end of round
- No record of why an asset was rejected
- Same defect recurs next season
Tiered review
- Automated technical gate runs on upload
- Humans only see spec-compliant assets
- Failures return to source immediately
- Rejection reason logged against a spec line
- Recurring defects become spec or pipeline fixes
The ordering is what produces the gain. When the technical gate runs first and automatically, the human reviewers stop spending their attention on problems that a script can find, and start spending it on the problems only they can judge.
Automate the technical gate
Every line in the technical tier is a measurement, and measurements belong in code. A gate that runs on upload can check dimensions and colour space, sample the background corners for a consistent value, measure the product's bounding box as a percentage of frame, compare the centroid to the frame centre, and validate the filename against your SKU pattern — before anyone is notified that there is anything to review.
The stronger move is to stop checking for defects you can prevent. If framing, scale and background colour are applied deterministically as the last step of image production rather than judged afterwards, the technical tier has nothing left to reject. This is the approach Retouchable takes with its framing step: the generation stage makes the pixels, and a separate deterministic stage measures the cutout, scales it by a per-category rule, places it in the safe area, and paints the exact background value. Consistency stops being a review outcome and becomes a property of the output.
Whatever produces your images, the principle transfers: anything the spec can state numerically should be enforced at production time, not discovered at review time. For more on removing manual steps across the whole pipeline, see our guide to AI product photography workflow automation.
Design the states and the handoffs
An approval workflow is a state machine, and most teams run one implicitly without ever drawing it. Drawing it is most of the work. A workable minimum:
- Submitted — asset uploaded, technical gate queued. No human notified.
- Auto-rejected — failed a measurable spec line. Returns to the producer with the specific line that failed. Never enters a human queue.
- Ready for brand review — passed technical. Enters the brand queue with its spec reference attached.
- Changes requested — rejected with a reason tied to a spec line or a written note. Returns to the producer.
- Ready for commercial review — brand-approved, awaiting variant and claim verification.
- Approved — cleared for publication, locked against silent edits.
- Published — live on the storefront at a known position, with alt text set.
Two rules keep this from decaying. First, every rejection must name a reason, and reasons must come from a fixed list rather than a free-text box. Free text cannot be counted, and if you cannot count your rejection reasons you cannot find the defect that costs you the most. Second, approval must be per-asset and per-version, not per-batch. Batch approval is how an unreviewed replacement file ends up live under an approved SKU.
The most common silent failure is an approved asset being overwritten at the same URL. Approval attaches to a version, not a filename. If your storage lets anyone replace a file in place, your approval record is decorative.
The handoff to publication deserves the same rigour. An approved image that lands in the wrong gallery position, or ships without alt text, has failed at the last inch — see product image gallery order and sequence for why position is a merchandising decision rather than an upload accident.
Measure the workflow, not just the images
Once the states exist, they generate the metrics that tell you whether the process is working. Four are worth tracking from the first week.
| Metric | What it tells you | Healthy direction |
|---|---|---|
| Rounds per asset | Whether the spec is clear enough to hit first time | Trending to 1 |
| Time in queue by state | Which reviewer is the bottleneck | No state over 48h |
| Rejection reasons by frequency | Which defect to fix at production, not review | Top reason shrinking |
| Auto-gate catch rate | How much human attention automation is saving | Rising share of rejections |
The rejection-reason table is the one that pays for the whole exercise. If sixty percent of your rejections are "product too small in frame," you do not have a review problem — you have a production rule that nobody encoded. Fix it upstream once, and that reason disappears from the table permanently. That is the loop the workflow is really for: each round of review should reduce the number of rounds the next batch needs.
Track image quality outcomes alongside the process metrics, too. Catalog consistency is not an aesthetic preference — it correlates directly with how confidently shoppers buy, as covered in product image quality and conversion rates.
Rolling it out without stalling production
Teams usually try to launch the full workflow across the whole catalog at once, and abandon it in week three because the queue backs up behind a spec nobody has internalised yet. A narrower rollout works better.
Start with one category and one reviewer. Write the spec for that category only — scale rules in particular are category-specific, and a rule that suits footwear will be wrong for jewellery. Run a single collection through the full state machine and log every rejection reason by hand if you have to. That first collection is not really about the images; it is about discovering which spec lines are ambiguous.
Then automate only the rejection reasons that actually appeared. Building a technical gate for defects you have never seen is wasted effort, and it adds latency to a queue for no return. Once the top two or three reasons are gated, the human queue is meaningfully lighter, and you can add the next category.
Finally, make the spec a living document with an owner. A spec nobody maintains drifts out of alignment with the storefront within two seasons — new marketplace requirements land, the site redesigns to a different aspect ratio, a new category arrives with no rule. Someone has to own the reconciliation, and it should be the same person who reads the rejection-reason table each month. The workflow and the spec are one system; neither survives long without the other.