A Thousand Suppliers, and About a Dozen Can Tell You Where the Order Is

We could not solve order status for our largest distributor customers, and it took us a while to accept that the problem was not on our side.

Of roughly a thousand suppliers one of those distributors buys from, about a dozen can return live order status. Twelve. And those twelve only work because integrations were built against every available route, one at a time, by people who were paid to do exactly that and nothing else.

Everyone in this industry already knows the shape of this. A distributor sells something, the customer asks where it is, and somebody picks up a phone. What surprised us was the ratio. Not "most suppliers can't" — closer to "essentially none can, and the exceptions are hand-built."

The four ways it goes wrong

Talk to suppliers about this and the same four things come up, in roughly this order.

You publish your data five different ways and still can't say where an order is. This is the one that stings, because it isn't for lack of effort. There is a product feed, and a pricing sheet, and an inventory file, and a portal somebody logs into, and an EDI connection with the one distributor big enough to insist on it. Five ways out. None of them carries status back.

Every distributor wants a different format. The same catalog, re-shaped by hand for each partner, forever. Every new relationship starts with a spreadsheet and a conversation about columns, and every one of those becomes something to maintain.

Nobody tells you which field is missing. A feed is rejected. The reason arrives days later, in an email, from a person who had to go and look. In the meantime your products are not on a site they should be on, and no one on either side knows it.

And it only works if you hire and keep an engineering team. This is the real blocker, and it is the one that never gets said out loud in a vendor meeting. Someone has to build the connections. Then that someone has to stay on staff to run them, patch them, and answer for them at 2am when a feed dies. That is not a project cost, it is a permanent salary line, and it is why the project never starts.

Notice that none of these is a standards problem in the way the industry usually means it. PromoStandards exists. The service definitions exist. The specs are public and they are not bad. The gap is not that nobody agreed what an order status message should look like.

What we got wrong

Our first instinct was the obvious one: build more integrations. If twelve suppliers work, go and make it forty. We were treating each connection as a piece of work to be scheduled.

That is a losing shape. Each integration is bespoke, so the cost is linear — forty suppliers is not much cheaper per supplier than twelve. Worse, every one of them is now something that can break, and the party who has to fix it is not the party who feels the pain. The distributor's customer is on the phone; the supplier's IT contractor is on holiday.

What actually changed our thinking was noticing which half of the problem is hard.

Agreeing what the data means is hard, and it is genuinely done. A product, a part, a color, a size, a price break, a decoration charge, an order, a shipment, an invoice, and the status of any of them — the industry has settled these. That work is finished and most people are not making use of it.

Agreeing how it travels is easy, and it is where all the effort goes. SOAP or REST. This endpoint or that one. Which version. Where the WSDL lives. Whether the test environment is up. This is the part every integration conversation is actually about, and it is the part a machine should be doing.

So the layer to standardize is the meaning. The format is an implementation detail, and an implementation detail is something you generate.

What that looks like in practice

If the data model is settled, then the access points are derivable from it. Not "easier to build" — derivable. A supplier describes its products, stock, prices and orders once, and the SOAP service, the REST API and the MCP server for every one of those follow from that description automatically. Same data, same rules, three doors.

Which means the supplier's side of the work stops being an engineering project. There is no endpoint to build, none to host, none to monitor, none to version, and nothing to keep a developer on staff for. The thing that has to be done is the thing only the supplier can do — say what its products are and keep that current.

And order status, specifically, stops being a special case. It is not a separate integration that somebody has to be persuaded to fund. It is one more thing that falls out of the model, so moving an order along in one place is what the distributor sees. No status email, no phone call.

If you already publish over PromoStandards, incidentally, you are further along than you think. What you serve today syncs in as-is, whether that is the full set of services or two of them. The work left is filling the gaps, which is usually a much shorter list than anyone expects.

The uncomfortable part

Twelve out of a thousand is not a technology failure. Every one of those thousand suppliers could return order status; the specs to do it have been published for years. It is an economics failure. The cost of connecting has been carried by whoever wanted the connection least, and priced as headcount.

Move that cost off the supplier and the ratio has no reason to stay at twelve.

That is what we ended up building, and it is why the Brikl Supplier Platform is free to set up rather than sold as an integration project.