At some point in almost every enterprise software sales cycle, a slide appears. It shows logos. SAP. Salesforce. NetSuite. Shopify. QuickBooks. Rows of familiar icons arranged in a grid, sometimes connected by thin lines to a central logo in the middle. The subtext is clear: this product speaks the same language as everything else you already run.
That slide is one of the most misleading things in software sales, and everyone on both sides of the table quietly knows it.
What an integration actually is
When a sales deck says "integrates with SAP," what it typically means is one of three things. First, there is a connector built by a third party that moves data in one direction, on a schedule, with a mapping file that was last touched in 2021. Second, there is a Zapier workflow someone set up during the trial period that has been running unmonitored ever since. Third, there is a webhook that fires on one specific event type, which was the only thing the prospect asked about during the demo.
What it almost never means is: there is a maintained, versioned, bidirectional data contract between these two systems, with error handling, retry logic, schema validation, monitoring, alerting, and a named owner inside the vendor organisation who is responsible for it when things break.
The gap between those two descriptions is where most enterprise software implementations go wrong.
The failure mode nobody talks about
Features fail loudly. If a button stops working, users notice immediately. Support tickets open. Someone pages an engineer. The failure is visible, datable, attributable.
Integrations fail quietly. An API version is deprecated upstream. An authentication token expires and is silently rejected. A field that used to contain a numeric value starts arriving as a string, and the receiving system's parser handles it by storing zero. A rate limit is hit at 2 AM during a batch sync, some records are skipped, and the job completes with a status of "success."
The data is wrong. Nobody knows. The ERP shows one inventory count; the warehouse management system shows another. A report gets pulled on Thursday. The numbers do not match what anyone expects, but they are plausible enough that the discrepancy is attributed to timing. It takes three weeks and a manual reconciliation exercise to establish that the integration has been silently dropping records for six weeks.
This is not a hypothetical. It is a description of something that happens constantly, in companies of all sizes, across every category of enterprise software.
The ownership vacuum
The deepest problem is not technical. It is organisational.
When a feature is broken, there is a product manager who owns it, an engineering team responsible for it, and a roadmap item tracking it. When an integration is broken, it often lives in no one's backlog. It was built by a consultant during the implementation. The consultant is gone. The vendor's support team says the connector is a third-party component. The third-party component's maintainer says the issue is with the upstream API. The upstream API's documentation was last updated when the previous version was current.
Integrations are infrastructure. They are not features. They do not belong on a product roadmap alongside "add dark mode." They belong alongside "keep the database running" — essential, invisible, unglamorous, and catastrophic when neglected.
The companies that have figured this out treat every external data dependency as a first-class engineering concern. They version their integration contracts. They write tests that run against real external systems on a schedule. They alert on data volume anomalies — because if a feed that normally delivers 4,000 records per hour suddenly delivers 40, something is wrong, and that is detectable without reading the records themselves. They assign an owner. Not a team — a person.
What to actually ask about
When evaluating software that will need to exchange data with your existing systems, the logo slide is the wrong thing to look at. The questions that matter are blunter.
What happens when the connection goes down? Does the system queue and retry? Does it fail silently? Does it alert someone? Is there a manual reprocessing path, and who runs it?
Who owns this integration inside your organisation? Not "who built it" — who is responsible for it being correct next year? If the answer is a shrug, that is the honest answer, and you should treat it accordingly.
What does a schema change look like from your end? When the upstream system changes a field type or renames an endpoint, how do you find out, and what is the update process? "We issue a new connector version" is not the same as "we alert you 90 days in advance, provide a migration guide, and support both versions in parallel."
Can I see the error logs? Not a demo of the happy path — the error logs. Any system that has been running integrations in production for more than a year has error logs. What is in them, and how are those errors resolved?
The data contract is the integration
The mindset shift that actually helps is to stop thinking about integrations as connections between systems and to start thinking about them as contracts between data producers and data consumers.
A contract has a version. It has an owner on each side. It specifies not just the schema but the semantics — what does this field mean, what are the valid values, what happens if it is null. It has a test suite. It has a process for change. It has a way to tell the other party when it has been violated.
Building integrations as contracts rather than as connectors is more work upfront. It is substantially less work over a three-year horizon. And it is the only approach that scales past the point where a single person can hold the entire data topology in their head.
The logo slide is not going away. But the next time you see it, the question to ask is not "which logos are on there" — it is "what is each of those connections worth when something goes wrong at 2 AM on a Monday?"
That answer is the integration. Everything else is marketing.