The May 28 post was about the all-in-one trap — the pitch that one platform should do everything, and why that promise decays into a platform that does everything badly. The mirror-image pitch deserves the same scrutiny. “We integrate with everything” sounds like the opposite of the all-in-one trap. It’s frequently the same trap wearing a different shirt.

Here’s the tell: “we integrate with everything” is a statement about the future dressed up as a statement about the present. What the salesperson usually means is we have an API, and given a signed contract and a professional-services engagement, we could in principle connect to your production system, your plant, your underwriter. That’s not an integration. That’s a permission slip to build one — with you funding the construction and absorbing the schedule risk. A delivered integration is a different object entirely: it exists, it runs in production at real customers, it has an owner, and it has a history of surviving both sides’ upgrade cycles.

The gap between those two objects is where implementation projects go to die. You’ve seen this movie: the contract gets signed in March on the strength of the integrations slide, and by October the “plant connector” turns out to be a statement of work, the “Qualia integration” is a CSV export, and your staff are swivel-chairing data between systems the demo showed talking to each other.

Three Questions That Expose the Difference

You don’t need a technical team for this diligence. You need three questions and the discipline to insist on specific answers.

One: show me this integration running in production, and name the customer. Not a demo environment — production, at a shop that resembles yours in volume and workflow. Delivered integrations have referenceable customers, and vendors are proud of them; ask, and a healthy vendor’s eyes light up. A vendor who can’t name a single live site is telling you that you’d be the first. Sometimes being first is worth it — but “you’d be the first” should be priced and scheduled like the development project it is, not sold like a checkbox.

Two: what syncs, exactly — which fields, which direction, how often, and what happens on a conflict? “Integrates with” spans everything from real-time bidirectional sync down to a nightly one-way file drop, and the pitch deck won’t distinguish them. Ask for the field map. A real integration has one, because it couldn’t have been built without one. While you’re there, ask about the ugly cases: the same record edited in both systems, a write the other side rejects, where errors surface and who’s expected to notice. Vendors with delivered integrations answer instantly, because they’ve lived these. Vendors with API promises improvise, and you can hear the difference in the room.

Three: when either side changes their API, who fixes it, on what timeline — and when did that last happen? Almost nobody asks this one, and it’s the most important, because an integration isn’t a thing you build. It’s a thing you keep alive. Both systems will change — the other vendor will version their API, deprecate an endpoint, tighten an auth requirement, on their schedule, not yours. Somebody has to notice, patch, test, and redeploy, every time, forever. Ask for the last real example: what broke, how it was detected — did the vendor’s monitoring catch it, or did a customer’s closing miss? — and how long to fix. A vendor with real integrations has war stories and a maintenance commitment in the contract. A vendor without them offers reassurance, and reassurance is not a maintenance plan.

Why These Questions Work

Notice that none of them is technical. They’re evidentiary. You’re not evaluating API design; you’re establishing whether the integration exists, whether its behavior is specified, and whether its upkeep has an owner. Those are the same three questions you’d ask about any operational dependency — because that’s what an integration is: an operational dependency with two vendors’ release schedules attached.

And notice the family resemblance to the all-in-one trap. Both pitches are ways of deferring the hard question of how your systems will actually work together. The all-in-one vendor says the question doesn’t exist. The integrates-with-anything vendor says it’s already been answered. In both cases the truth lives in specifics, and vendors who’ve done the work volunteer specifics without being cornered.

Graded on Our Own Test

I’m writing the questions down knowing they’ll get asked of us, which is the point. ElectraOne’s integrations are delivered and running at customers we’ll name, with field maps we’ll show you and maintenance commitments we’ll put in the contract. Where something you need doesn’t exist yet, I’ll tell you it’s a project and price it like one — because the alternative is becoming the October movie above, and that costs more than the deal was worth.

Ask all three questions of every vendor at the table. The ones who’ve done the work will thank you for it.

Ask ElectraOne the three questions →