Every integration project starts with the same promise: this will finally connect everything. The data will flow. The teams will have visibility. The manual updates will stop. Six months later, there’s a new system that sales doesn’t fully trust, ops has a parallel process running alongside it, and nobody is sure which number is right.
I’ve been inside enough of these projects to have some opinions about why they go wrong and what actually works instead.
Why new tools become new silos
The reason integrations fail isn’t usually technical. The connectors work. The data moves. The problem is that the new system was designed around an ideal workflow, not the one people are actually doing.
Sales teams have their own language for deals, their own shortcuts, their own reasons why something got logged a certain way. Ops has different visibility needs and a different rhythm. When you build a system that doesn’t account for how each team actually works — not how you want them to work — you get adoption problems. People work around it. They maintain their own records. You now have two sources of truth instead of one, and the new one is the less trusted one.
What reduces friction instead of adding it
The integrations that work share a few properties.
They start with the team that has the most friction, not the team that has the most data. The goal is to remove a painful manual step for a real person, not to achieve theoretical completeness in a data model.
They define what “connected” actually means in specific terms — which number is authoritative, whose system of record wins when there’s a conflict, who is responsible for resolving a discrepancy. These feel like obvious questions but they almost never get answered before the build starts.
They leave room for the human layer. A good integration doesn’t try to eliminate judgment calls. It makes the information available so the person making the call has what they need. The goal is better decisions, not automated decisions.
If you’re planning an integration between sales, ops, and data systems, spend the first two weeks on process documentation before touching the tooling. Map the actual workflow — including the informal steps nobody wrote down. The places where people say “and then I usually just check with X” are exactly where the integration needs to fit.