RevOps integration. Making the systems actually talk to each other.

The short answer on RevOps integration. It is a data-ownership problem first.

RevOps integration gets treated as a software problem, pick the right connector, map the right fields, and the rest follows. In practice, the technical part is the easy part. The decision that actually determines whether an integration works a year from now is which system owns each piece of data and what happens when two systems disagree about it. A CRM and a billing platform will eventually show a different number for the same customer. The integration either has a rule for which one wins, or it quietly produces two versions of the truth that nobody notices until a board report does not add up.

Zapier's 2025 State of RevOps Automation report, based on a survey of more than 450 US-based RevOps professionals, found that 86% use Salesforce, yet 22% also run HubSpot and 5% run Pipedrive inside the same organisations. Multiple CRMs in the same company is more common than most founders assume, and that is before marketing automation, billing, support and a BI layer are added to the picture. The report also found that most respondents solve operational problems by combining several types of automation tools rather than relying on one system to do everything, which is the reality any integration plan has to work with rather than wish away.

This matters commercially, not just operationally. Our revenue operations work exists because a growing company's systems stop talking to each other well before anyone decides to fix it on purpose, usually once there are enough tools that no single person set all of them up. By the time a founder notices the problem, it typically shows up as a trust issue rather than a technical one: the board stops believing the pipeline number, a new hire gets a different answer depending which system they check, and marketing and sales argue about which list of leads is current. Integration is the unglamorous fix underneath most of those arguments.

How it works in practice. Three layers, and where teams get stuck.

The system of record

One system is authoritative for each entity: the CRM for deal and contact data, the billing platform for revenue and subscription status, the support tool for ticket history. Our guide to RevOps and your CRM covers how the CRM specifically earns that role for customer data, but the same logic has to extend to every other system before integration can start, otherwise there is nothing for the connections to agree on.

The connective layer

This is where most teams get stuck, choosing between point-to-point connections built inside each tool's own settings, or a dedicated iPaaS layer such as Zapier, Workato or Make that centralises the logic in one place. Point-to-point is cheap and quick for one or two connections. Past four or five, it becomes a tangle nobody can map, because the logic for what triggers what lives in a different tool each time, and a single field rename can break three connections silently.

The reporting layer

A dashboard or BI tool should pull from the agreed system of record, not recalculate its own version of a number the CRM already owns. The second a spreadsheet or BI tool starts applying its own adjustment to a figure like ARR "to make it more accurate," you have two truths again, and whichever one a given stakeholder saw first is the one they will defend in the next meeting.

What it costs. Time matters more than the invoice.

The tools themselves are rarely the expensive part. A mid-market iPaaS subscription runs a few hundred dollars a month, and most CRM and billing platforms include a native integration with at least one other common tool at no extra cost. The real cost is the time spent agreeing data ownership before anything gets built, and the ongoing time spent maintaining the connection once it is live. Teams that budget for the build and skip budgeting for the maintenance are the ones whose integrations quietly stop working a year in, usually after a field gets renamed or a plan gets upgraded and nobody checks whether the old mapping still holds.

A realistic rule of thumb: for every week spent building a connection, plan for roughly the same amount of time, spread across the following year, keeping it working. That is not a reason to avoid integration. It is a reason to integrate the highest-friction gap properly rather than every gap cheaply, and to say no to a connection that saves ten minutes a week if nobody is going to own it.

What good integration looks like. Four signs it is actually working.

• One named owner per data type. Not a team, a person, who can say in one sentence which system wins when two disagree, and who is the first call when a number looks wrong.
• Near real-time, one-direction flow for anything that matters operationally. A new lead should land in the CRM within minutes, not overnight via a manual CSV export that someone has to remember to run.
• A written map of every connection. What triggers it, what it updates, and who to call when it breaks, kept somewhere other than one person's memory or an old onboarding document nobody has opened since.
• Someone reviews it when anything changes. A new tool, a renamed field, a plan upgrade, or a departing employee who built the original Zap should trigger a review, not a surprise six months later when a report quietly stops updating.

None of these four signs require a dedicated integrations engineer. On a founder-led team, this is usually one person's part-time responsibility, often the same person who owns the CRM, and the job is less about writing code than about noticing when a connection has gone quiet and knowing who to ask.

Where this goes wrong in practice. A stack that technically worked and still misled the board.

A founder-led SaaS company I worked with, illustrative rather than a named result, had three systems reporting monthly recurring revenue: the CRM, the billing platform and a finance spreadsheet that the finance lead quietly adjusted by hand each month "to true it up." Each number was defensible on its own. None of them matched, and the gap between the CRM's view and the finance spreadsheet's view ran as high as 18% depending on which week of the month someone pulled the figure. The fix was not a better integration tool. It was a decision: billing became the single source of truth for recognised revenue, the CRM's own revenue field was set to pull from billing rather than being entered separately by reps, and the finance spreadsheet's manual adjustment process was retired entirely. The sync itself took an afternoon. Agreeing which system got to be right took three meetings, which is the more usual ratio for this kind of project than most teams expect going in.

Pitfalls to avoid. Where integration projects usually go wrong.

• Integrating everything at once instead of the highest-friction gap first. The lead-to-CRM gap is almost always worth fixing before anything else, because it is the one manual step every rep feels daily, and fixing it first builds the case for funding the rest.
• Building the connection before agreeing which system wins on conflict. Skipping this step is why two-way syncs so often end up in update loops, where each system keeps "correcting" the other and a field value flips back and forth until someone notices.
• No owner once the initial build is finished. An integration with nobody responsible for it tends to survive the first system upgrade and fail quietly on the second, usually discovered only when a quarterly report does not match what the sales team already knew.
• Choosing two-way sync where one-way would do. Two-way sync is more fragile and only worth the added complexity when both systems genuinely need to write to the same field; most integrations do not.
• Treating the integration as a one-off project rather than a standing part of the RevOps function. Tools get added, upgraded and retired constantly on a growing team, and an integration map that is never revisited falls out of date faster than most founders expect.

None of this requires an enterprise budget. It requires sequencing: agree ownership, fix the highest-friction manual step first, document what you built, and name who maintains it. Teams that skip straight to tool selection usually end up rebuilding the same integration eighteen months later, for the same reason it failed the first time, having spent the time in between wondering why the dashboard and the sales team never seem to agree on the pipeline number.