What Happens When Your Platform Vendor’s PS Team Goes Home

If you’ve ever run a multi-platform commerce stack, you’ve probably been on the 2 AM bridge call. Orders are failing in production. The OMS vendor, the PIM vendor, the ERP vendor and your cloud team are all on Zoom. Everyone has run their diagnostics and everyone’s come back clean. The OMS team thinks it’s an inventory feed. The PIM team says the schema’s correct on their side. The ERP team pings the cloud team. The cloud team says Kafka looks healthy. An hour in, nobody’s actually identified what’s broken.

The question on the call isn’t a complicated one. Whose problem is this? The honest answer is that it isn’t really anybody’s, because no one was ever paid to own it.

If you read a typical platform vendor professional services (PS) contract, the scope language is pretty narrow. It tends to come down to something like: in scope, bug fixes and minor changes to the configured platform. Out of scope, more or less anything beyond that.

That’s not a sneaky clause. It’s just the deal. The platform vendor’s PS team is paid to make their platform succeed. They install it, configure it, build out the API surface that talks to your stack, document their side of the wire, and their job ends there. Their commercial existence doesn’t include the connections between systems they don’t own.

So the integration layer between OMS and ERP and PIM and your ecommerce frontend is, contractually, nobody’s. You bought five excellent platforms. You didn’t buy anybody to own the wires between them.

These are empty cables: connections that run between two systems with no one accountable at either end once go-live is over.

Picture the typical engagement. The vendor’s team comes in for a six-to-twelve-month implementation. They configure their platform for your use case. They build the API surface that talks to your stack. They document their side of the wire. They might cooperate with the SI building the rest of the integration layer, or they might just hand it over. Either way, what their contract covers is their platform behaving correctly.

The connection between their platform and yours is half theirs. They own the side that lives on their box. The connection between two platforms that are both somebody else’s, they have no contractual reason to touch.

This isn’t malice and it isn’t laziness. It’s the structure of how services revenue works. The PS team’s economics are tied to the platform they sell, and time spent debugging the integration between an OMS they don’t license and a PIM they don’t license shows up as zero on their P&L. So they don’t do it.

It’s a bit like hiring an electrician to wire your kitchen. They do the kitchen. They don’t do the dining room. Nobody’s been dishonest about it, but the dining room still doesn’t have power.

Most companies don’t notice any of this on day one, because day one is launch. Things work. The SI is still around, the vendor PS teams are still on hypercare, and incidents get resolved quickly because the people who built the integration are still in the room. Then the contracts wind down.

The SI rolls off. Vendor PS goes back to being on-call only for tickets that fail their internal validation, which is a small fraction of what actually fails in production. Your internal team is now the owner of an integration layer they didn’t build and don’t have the runway to refactor. There’s a Confluence page from the original architect, six months out of date. There’s a Slack channel where the original developers were active for three weeks, and nobody’s posted in it since Q3.

Then the first real incident shows up. Every vendor’s L1 runs their diagnostic and every one of them comes back clean. They’re all correct. The failure isn’t inside any of their boxes; it’s between them. And the empty cable doesn’t really make itself visible until something breaks across it, by which point you’re an hour into a bridge call with five vendors and your VP of Engineering is making coffee.

This isn’t a niche problem. IHL Group’s most recent retail tracking puts inventory distortion (stockouts and overstocks) at roughly $818 billion a year worldwide, and a meaningful share of that is synchronization failures between systems — exactly the layer no vendor’s PS team is paid to watch.

For a decade, the dominant pattern has been best-of-breed. You pick the strongest commerce platform you can afford and pair it with a specialist PIM, a specialist OMS, and a specialist ERP. The thinking is that you get specialization at every layer instead of an all-in-one giving you mediocrity everywhere, and that thinking is basically right. The inside-the-box quality has gone up over the last decade.

What’s also gone up is the number of boxes, and therefore the number of connections between them. Each connection is a contract boundary. Each contract boundary is a place where the right answer to “is this your problem?” is “no.” That isn’t a flaw in composability so much as a real consequence of it that doesn’t get talked about much when the architecture decision is being made.

It’s also where the value of every platform investment actually gets realized, or doesn’t. A best-of-breed PIM is only as valuable as the product data flowing cleanly out of it and into the OMS. A best-of-breed OMS is only as valuable as the order data flowing cleanly into the ERP. The platforms themselves are easy to put a number on; the integration layer is what determines whether you ever earn that number back. When the integration layer goes unowned, the return on every platform investment in your stack rides on a layer that has nobody’s name on it.

The instinct most teams have is to push for a better PS contract on the next round. That doesn’t really fix it, because the gap isn’t a gap inside any one contract. It’s the gap between contracts. No vendor PS team can sell you “responsibility for the cables we don’t own,” because their economic model can’t price it.

What you actually need is somebody whose only job is the layer between platforms. Somebody who builds those connections and then keeps watch on them in production, on whatever stack you happen to have, as an ongoing practice rather than another finite project.

That’s a different kind of relationship from a platform PS engagement. The platform vendor PS team owns inside their box. What’s missing is somebody whose entire engineering practice is about what happens between the boxes, and who’s still around when one of them fails at 2 AM.

This is the gap Pivotree built our Integration Services practice around. We don’t sell another platform. We own the layer between them: the connections themselves, the validation, and the production monitoring that surfaces failures before customers do. Because one team has eyes on every integration in your stack, a pattern of small anomalies on one connection is often the early warning for a bigger failure somewhere else, and AI applied across that whole-stack view tends to catch problems before they cascade. It runs on top of whatever you’ve already bought, so the OMS vendor’s PS team can keep doing what they’re paid to do, and the same goes for every other platform vendor in your stack. We own what’s between.

If you’d like to see what that feels like in your environment, we run a free two-day Integration Sprint. We take one to three of your real integrations through our pipeline and hand back working code and a full test suite at the end. The point isn’t really those integrations. It’s a chance to see what it looks like when somebody’s actually accountable for the gap between your platforms.