Four Gaps in Every ERP for a Decorated Goods Business

Every ERP sold into this trade leaves the same four gaps, and it isn't because the software is bad. It's because almost none of it was built for decorated goods in the UK.

I reviewed twelve of the platforms sold into print, embroidery and workwear businesses. Some are shop management tools, some are full ERPs, some are web-to-print systems. They differ enormously in price and polish. They fail in remarkably similar places.

Being upfront: I build software in this space, so I have an interest. I have also spent twenty five years inside businesses running these systems, and what follows is what I actually see when I walk in.

Gap one: UK supplier data

This is the big one, and it is the one nobody talks about in a demo.

Of the twelve platforms I reviewed, exactly one lists a single UK garment supplier catalogue. Ralawise and BTC Activewear appear in none of them. Every other live supplier catalogue integration I found is American wholesale.

That matters more than it sounds. Live stock and pricing feeds are the feature these platforms lead with. Brilliant if you buy from Carolina. Useless if you order from Ralawise or PenCarrie every morning, which most UK decorators do.

So the headline feature dies on arrival here, and you end up re-keying purchase orders by hand inside software you pay hundreds a month for.

It gets worse in teamwear. In my experience, the big athletic brands rarely publish properly formatted product data or imagery. If you sell their garments, somebody in your office is pulling product information out of a supplier portal behind a login and reformatting it by hand. I built the supplier data integration in my own platform because I got tired of recommending tools that half worked.

Gap two: artwork approval

Nobody owns this.

The generalist ERPs have nothing for it. Where proofing and a customer approval portal do exist, they are sold as separate paid modules rather than being part of the system you already bought. Nothing I reviewed owns the depth: revision history tied to the order line, a clear record of which version the customer actually signed off, blind approval for contract work.

So the gap gets filled with shared folders, email attachments and a naming convention somebody invented in 2019. Three files called final. Nobody quite sure which one went to print.

That is not a training problem. Email was never built to be an approval system, and a folder is not a version history.

Gap three: what it costs to leave

Quote-only pricing on the way in, modules priced one by one once you are committed, and an exit bill nobody mentions in the demo.

One shop owner's published review put the cost of getting out of their system at over forty thousand pounds. Not to run it. To leave it. Another signed a three year contract, is no longer using the system, and is still paying.

I've read plenty of these reviews. The pattern is consistent enough that I now treat exit cost as a selection criterion rather than a footnote. Ask what it costs to get your data out, in a usable format, on the day you decide to go. Get the answer in writing before you sign.

That's also why I price engagements rather than software, and why the platform I build with a client vests to them over the term. Their system, their data, no ransom on the way out.

Gap four: the implementation nobody budgets for

This one is not specific to any product. It is true of every ERP implementation I have seen.

Three things consistently blow the estimate:

Data migration. Your existing data is never as clean as anyone assumes. Duplicate customer records, product data in formats that do not map, size and colour matrices that only make sense to the person who built them. This is almost always the longest part of the project and the most underestimated.

Requirements that were never defined. The system gets configured during implementation. If the requirements were not settled before configuration started, every change mid project costs money and time.

Training time for people who are not confident with software. Consistently underbudgeted.

None of that means an implementation will fail. It means a realistic budget is meaningfully above the quoted price and a realistic timeline is considerably longer. Plan for it rather than being surprised by it.

What to do with this

The gaps are not a reason to avoid buying software. They are a reason to know which ones you can live with before you commit, rather than discovering them in month seven.

The honest test is simple. Take the four gaps above, and for each one ask: does this system cover it, does a separate tool cover it, or does a person in my office cover it? Write down the answer. That list is your actual requirement, and it is worth more than any demo.

If you want a second pair of eyes on it, I will give you twenty minutes and the screen. Bring the platform you are evaluating and your worst operational headache, and I will tell you honestly whether your problem needs new software at all. Half the time it does not, and I will say so.

Message me and I will find a slot.