There is a number on your website. There is a different number in the system your business actually runs on. Both of them are supposed to be the price of the same thing.
Every business that sells from a catalogue arrives here eventually. The system in the back office holds the truth: what exists, what it costs, what has been withdrawn. The website holds a copy of that truth, made at some point in the past, by hand. A copy made by hand starts drifting the moment it is finished.
The symptoms are the same everywhere
You will recognise at least two of these.
- Prices on the website that no longer match the price list.
- Products discontinued months ago, still listed, still taking enquiries.
- New lines that have been available for weeks and are not on the site at all, because the person who adds them has been busy.
- A customer quoting your own website back at you, and being right.
Underneath all of it, somebody is re-keying. Somebody with a spreadsheet open on one screen and a website admin panel open on the other, typing the same figures into a second system because, as everyone in the building has agreed for years, the system will not talk to it.
The real cost is not the typing, though the typing is bad enough. It is that once the website has been wrong a few times, your own sales team stops trusting it. They start telling customers to ring in and check. At that point you are paying to run a website whose main output is phone calls, which is roughly the opposite of what it was bought for.
"The system won't talk to it" is usually not true
This part is worth being blunt about. When a business tells us their back office system cannot be connected to anything, what is usually meant is that nobody has tried, or that a vendor quoted an unpleasant number for a module several years ago and the idea was quietly dropped.
You do not need the vendor's blessing. You do not need a modern system with a documented API, although it is pleasanter when there is one. And you do not need to replace the ERP, which is the suggestion that kills most of these projects before they start, because replacing the system the entire company runs on is a two year argument. This is a far smaller job than that.
What you need is modest: a reliable one-way feed out of the system that already holds the data, and a decision about who owns what. Almost every business system built in the last thirty years can produce a file on a schedule. A file on a schedule is a perfectly good integration. It is unglamorous, it is well understood, and it has the considerable advantage of requiring nobody to change how they work.
Decide who owns each field, before anybody writes anything
This is the step that gets skipped, and it is the one that decides whether the result is trusted or becomes another system nobody believes.
Some information belongs to the back office and should never be editable on the website. Codes, prices, dimensions, which products exist, which have been withdrawn. If someone can edit those on the site, eventually someone will, and then the two systems disagree again and you are back where you started with an extra step in the middle.
But a surprising amount of what a customer actually sees is not in the ERP at all, and never will be. On one recent build, the entire colour range fell into this category. The manufacturing system knew about product codes, sizes and prices, and carried no colour information whatsoever. Every colour name a customer reads, every swatch shown on screen, every "this finish works well with that one" recommendation had been worked out and entered by staff who know the products properly.
That work is worth more than the import is. It is also exactly what a carelessly built feed destroys, because the simplest way to load a fresh export is to clear everything out and load the new file over the top. Do that once to a column full of hand-entered work and you will not get a second attempt at the project. So the import takes a copy of everything the people own before it reloads anything, and puts it back afterwards.
The same thinking produces one of the most useful rules in the whole system: available and visible are two different things. The ERP decides what exists. A person decides what appears. Keeping those as two separate switches means you can stock something without advertising it, or hold a new range back until the photography is ready, without anyone having to fight the import to do it.
Why this is harder than it looks
None of the above is difficult. What follows is where the time actually goes, and it is worth knowing, because these are the details that decide whether the feed is still working properly in a year.
The reference numbers in an export are not stable. An export is a snapshot, and the sensible way to load a snapshot is to discard the previous one and load this one from scratch. That means the internal row numbers in the data are reissued on every single run. If the connections between your website and your product data are built on those numbers, everything works perfectly until the second import, and then it attaches itself to the wrong records, silently, with no error message anywhere. Everything has to be joined on the values that genuinely mean something to the business instead: the item code, the range name, the finish. Slower to build, and it survives.
Never delete anything the business still refers to. A product that has dropped out of this month's export has not ceased to exist. It is on last year's orders, on quotes that are still open, on a drawing somebody will reprint in five years. Deleting it makes your own history unreadable. Mark it inactive, keep it, and let the website stop showing it. This sounds obvious written down, and it is the most common way these projects do lasting damage.
A partial import beats a failed one. If five files arrive and one of them is malformed, the useful behaviour is to load the other four, record clearly that the fifth failed, and carry on. Abandoning the whole run means one bad character in one file leaves the entire site stale, and that will happen on the worst possible morning.
The work after the import matters as much as the import. Once the new data has landed, something has to go back over it and work out what has actually changed: which products still have anything available underneath them, which are now empty and should drop off the site, what the real range of sizes is today. Skip that and you get the worst result available, which is a site that is technically up to date and still showing customers things they cannot buy.
What it looks like when it is working
Nobody re-keys anything. The website is behind the back office by hours rather than weeks, and everybody knows which hours. Staff carry on working in the system they already know, and nothing about their day changes, which is the main reason it sticks. A price changes in the back office, and it changes on the website overnight without a conversation, a ticket or a reminder.
And your sales team starts quoting the website again.
What it does not fix
We would rather set this out now than have it discovered later.
- It does not clean up your data. If descriptions are inconsistent and half the products have no dimensions recorded, a feed delivers exactly that to your customers, faster and more reliably than before. Connecting the systems does tend to make the state of the data visible for the first time, which is genuinely useful, but tidying it is separate work and usually the larger job of the two.
- It does not make the ERP nicer to use. This is a feed, not a replacement. The people in the back office will notice no improvement whatsoever.
- It runs one way, deliberately. The website does not write back into the ERP. You should want that. Two systems that can both edit the same field is not an integration, it is a standing argument with a scheduler.
- Somebody still owns the product content. The descriptions, the photography, the groupings that make sense to a customer rather than to a factory. The feed removes the re-keying, not the judgement.
- Real time is usually not what you need. Overnight is plenty for a catalogue and costs a fraction of live synchronisation to build and to run. Stock levels can be a different matter. Be honest about which of your data genuinely changes by the hour, because that single decision drives most of the cost.
Where to start
Ask one question of whoever looks after your back office system: can it produce a file of the product data on a schedule, without anybody having to press anything? If the answer is yes, and it usually is, then the part everyone assumes is impossible is already solved. What remains is careful work and an honest conversation about who owns which field.
If you have somebody re-keying product data between two systems, or a website your own staff have stopped trusting, we would be glad to take a look at it with you.