← Back to Work
Process file · Ops Ops

What’s inside: output checking · company memory

Every Thursday a merchandiser rebuilds promo prices by hand

The question this file answersWho checks that the shelf label, the PIM and the site show the same price before the promo goes live?

Fits: retailers publishing hundreds to thousands of SKU updates a month.

Typical day

What the desk looks like today

Typical pattern, not a measured team — the e-commerce playbook counts catalogue updates in hundreds to thousands of SKUs a month, with no separate volume for promotions. A promo spreadsheet, the PIM and the live site disagree; a merchandiser reconciles them by hand weekly, and a customer finds the mismatch.

What changes

What Monday looks like after

On Thursday the merchandiser opens a review list of the conflicts — a handful of lines, not the whole promo — and the rest is already staged in the PIM for go-live. The margin conversation still happens; the copy-paste does not.

Typical, not a measured client result. Every figure here comes from the playbook source named below.

Compared

promo file, PIM and site compared line by line — the same build as our catalogue file; no published figure for promotions

Before: a merchandiser rebuilds prices by hand every Thursday. After: the three sources are compared line by line and only the conflicts wait for a decision. The percentage stays on the catalogue file.

No published figure for this desk. The range lives on the parent file: The supplier's spreadsheet into Akeneo or Salsify, for review →

How this file is built

Nobody has published a figure for promotional price synchronisation. Forrester's (2023) 40–60% faster time-to-publish and the Salsify/Akeneo 50%+ on attribute entry both describe catalogue enrichment and stay on the parent file. Not a margin claim.

What we install

What we put in front of the systems you already run

Your PIM and shop platform stay — Akeneo, Salsify, Plytix and Shopify, Magento or the ones you run. The supplier-catalogue build is run against prices instead of attributes:

  1. the promo file is read, whatever spreadsheet layout the trading team uses
  2. each SKU's promo price is compared with the PIM record, the live channel price and your margin floor
  3. consistent lines are written to the PIM and pushed through your existing channel sync, while conflicts — a missing SKU, a price below floor, two promos on one item — go to the merchandiser with the three values shown.
What stays human — and what this will not do

Brand decisions. Margin arguments. The promotion that is really a story, not a price.

Not a margin claim.

What can go wrong — and what we do about it

If the PIM and the shop platform hold different SKU codes for the same item, the match fails until an alias table exists — that is the first fortnight's work. Channels without a price API need a file upload, and go-live timing then depends on the platform's sync. Forrester's 40–60% concerns catalogue enrichment and belongs to the parent file — promotions have no figure of their own — and brand or margin calls stay with a person.

What it costs to get there

The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →

Scoped in the audit — the playbook has no estimate for this exact desk.

This is about you if…
What does this mean in euros?

That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.

Get your free savings estimate 60 seconds · no sales call Or write first → Map an ops process like this one — free, 60 seconds →

Not a named Aperanda client. Process file · Ops.

Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.

All process files