What a product really is
A handful of near-identical records.
Spread across the systems that run your business, each one certain it’s right. Open them up and you’ll find the same product described a different way in every one.
The same item, as each of your systems understands it.
Finance
A code, a cost, a supplier and a VAT rate. No photograph, no description anyone would recognise.
Stock
Sizes, weights, quantities and where it sits in the building. Its own naming, set up years ago.
Image library
Photographs named by whoever saved them, with no reliable way back to the product they belong to.
Sales
Price lists and customer-specific terms, kept in spreadsheets that live alongside the system rather than in it.
Website
The words and pictures a customer actually sees — typed in by hand, and the version most likely to be out of date.
Everything else
Ordering, despatch, the supplier portal, the spreadsheet someone keeps on their own machine. Every system that touches a product keeps its own version of it.
None of those records is wrong. Each one is right about the part of the product it was built to hold — which is exactly why nobody can say which one to believe.
That’s the problem, and it never shows up as a system failure. It shows up in someone’s week.
1
Someone’s week goes on reconciliation
Exporting one system, comparing it to another, and working out by hand which figure to believe. It takes real skill, it produces nothing new, and the moment it’s finished it starts going out of date again.
2
Decisions follow whichever screen was open
A margin from finance, a stock figure from the warehouse, a price from a spreadsheet. Each is defensible on its own. Together they quietly disagree, and the answer depends on where you happened to look.
3
Anything new is typed in once per system
A new line, a price change, a better photograph — each one is re-keyed into every system in turn. A chance to mistype in every one, and no way to tell which was missed.
4
When it’s wrong, nobody can say where it started
The website shows the wrong weight, or a customer is charged last year’s price. Everyone can see the symptom. Finding which record went astray first is a morning’s work, and it happens again next month.
What doesn’t change
Nothing is ripped out.
Your finance package, your stock system, your image library, your sales records, your website and whatever else you run all stay exactly where they are, and the people who use them carry on using them.
What gets built is the joining-up: the connections between those systems, so they act as one workflow rather than a set of islands. A product moves along it — priced, counted, photographed, listed and published — as a single flow instead of the same job done by hand in every one.
1
Agree what a product is
One plain description everyone recognises, and a decision about which system is trusted for which part of it — finance for cost, stock for weight, the library for the photograph. Each system keeps its own fields. It just stops being a matter of opinion which one is right.
2
Build the connections
The systems are wired to one another, one join at a time, so each is handed what it needs when it needs it. Where a system genuinely can’t be connected, the handover is made simple and visible rather than left to memory.
3
Run it as one flow
A product enters once and travels the whole way through to the website. Change a price or swap a photograph and the change follows it. If something can’t proceed, it says so at the point it happens instead of surfacing weeks later in a customer complaint.
This isn’t a rebuild, and it isn’t a project that swallows your year. It’s built in stages, in the order that pays back first — usually the join that’s eating the most of someone’s week. Each stage stands on its own, the business keeps trading throughout, and you can stop after any one of them and be better off than you were.
No pitch, no commitment. Just a chat about how your systems actually work and whether joining them up is worth doing. If it isn’t, I’ll say so and tell you what I’d do instead.
If your product lives in a handful of systems and someone’s week goes on keeping them in step, it’s worth a conversation. Tell me which systems you run and where the re-keying hurts most, and I’ll tell you plainly what joining them up would involve.
Start a conversation
The same job elsewhere
Custom Pipelines
If the thing spread across your systems isn’t a product — jobs, suppliers, kit, orders, people — it’s the same problem, and it’s fixed the same way.
See the page
All of them
Pipelines
What a pipeline is, and the three that exist so far. Start here if you’re not sure which one describes your week.
See the pipelines