A founder asked me a reasonable question last week: where does this project actually stand? Nobody in the room could answer it. Not because the data was missing, but because it lived in two systems and neither one owned the answer.
That question is the most expensive one in a growing revenue org, and the fix teams reach for is almost always the wrong one. They hear a request for visibility and they start scoping an integration. Six weeks later there is a sync running in both directions and the founder still cannot answer the question.
Why this is getting worse, not better
The reason you keep running into this is that the market has not settled where truth lives, so every company is quietly deciding for itself. Writing about Salesforce’s acquisition of Momentum in February, Forrester’s Anthony McPartlin framed the choice buyers now face: either a CRM-as-a-platform approach, which buys you “simplicity, centralized governance, and a single point of accountability,” or a best-of-breed truth platform, which buys you “faster innovation and advanced specialization.” His prediction is that the suites will keep absorbing those orchestration layers rather than letting specialists sit between the CRM and the workflow.
That is a vendor fight. Your version of it is smaller and more urgent. You have a CRM, you have a second system where real work happens, and you have an executive who wants one sentence about where things stand. Nobody has decided which system is allowed to answer.
The misdiagnosis
Here is the issue. When somebody asks for visibility, the instinct is to connect the systems: two-way sync, field mapping, mirrored records on both sides. It is a large amount of build, it is genuinely expensive to maintain, and the day the mirror drifts, you have added a new problem where two teams point at each other’s data instead of at the work.
It also solves the wrong thing. The executive asking for visibility does not want the other system’s records. They want three facts: what stage is this in, who owns it right now, and is it blocked. That is a reporting problem with a small surface area, and you can answer it without moving a single field.
I would apply the keep / edit / delete frame here before anyone writes an integration spec. Keep the data that answers the executive’s question. Edit the journey so ownership is explicit. Delete the assumption that both systems need to know everything the other one knows. Integration is one way to buy visibility, and it is the most expensive one on the menu.
Build a status layer above the journey
The thing that actually delivers visibility is a thin layer that sits above your customer journey and summarizes it. Not another pipeline. A small set of properties on whatever object is the real unit of work for you: the account, the project, the portfolio.
This is the part people skip, because a status layer looks too simple to be the answer to a problem that felt architectural.
Four fields carry most of the weight:
- Current milestone. One value from a short list, six to ten options, not every granular step.
- Current owner. The named human accountable for moving it, which changes as the milestone changes.
- Blocked. A boolean plus a one-line reason.
- Next action date. The date something is supposed to happen next.
That layer touches the core milestones and deliberately ignores the detail underneath them. If the operational system runs a fifty-step checklist, the status layer does not care about steps eleven through nineteen. It cares that you are in build, that a named person owns it, and that it is not stuck. Granularity lives where the work lives. Summary lives where the executive looks.
Every stage declares its system
The second half of the fix is documentation, and it is cheaper than the integration by an order of magnitude. Go through the journey stage by stage and write down, explicitly, which system people work in at that stage and what they do there.
Most cross-system confusion is not a data problem at all. It is that nobody wrote down where the work happens, so two teams each assumed the other was watching. Once a stage says “at this point you are working in the operations tool, and the only thing the CRM needs from you is the milestone value,” the ambiguity is gone and the sync you were about to build shrinks to one field.
Then work with the strengths of each platform instead of flattening them. Case routing, ticketing and inbound email belong in the CRM, where that machinery already exists. Execution belongs in the system built for execution. Accept that one person, usually a routing gatekeeper, will work across both. That is a role, not a defect.
Gate the handoff instead of syncing it
The handoff is where visibility actually dies, and the evidence on this is unusually blunt. A SaaStr panel on how the fastest AI companies rebuilt customer success named handover success as “the place most failure and data loss happens.” One company on that panel moved closed-won out of sales and into implementation as a threshold, so that a signed deal that never kicked off was never counted. Their churn went from 4% per month to roughly half a percent while they scaled from $8M to $200M in ARR.
That is not an integration story. It is a definition story. They changed what a stage means and who is allowed to declare it.
Do the same thing with your gates. A stage should have entry criteria, and you do not enter it until they are met. You never hand a customer to a new team while the previous team still has open items, because that is precisely the moment ownership becomes ambiguous and visibility disappears for everyone above the work. If you have binary go/no-go checkpoints buried inside a phase, and most technical verification processes have two or three of them, promote each one into its own named stage with its own owner. A checkpoint nobody can see is a checkpoint nobody is accountable for.
Parallel pipelines, parallel ownership
For teams where commercial and operational work genuinely run at the same time, one pipeline will not hold it. Run two: a commercial pipeline and an operational pipeline that opens alongside it, each with its own stages, both rolling up to the same status layer.
Ownership splits the same way. On the account, carry separate owner fields for the commercial relationship and the operational relationship, plus whoever owns onboarding and whoever owns the post-sale account. It looks like more fields. It is fewer arguments, because at any moment there is exactly one name against each kind of question.
What this looked like in practice
We are working with a small DACH team, under twenty people, doing two hard things at once: migrating off a legacy CRM and building their own internal operations tool. The founder’s stated success criterion for the whole program was a single view showing where every project sat, from first inbound lead through to live operation.
The proposal on the table was to connect the two systems. The founder pushed back that this would not be enough, and he was right, though not for the reason he thought. The problem was never that the data was in two places. It was that a multi-step technical verification phase was invisible to everyone outside the team running it, and nobody had written down which system owned a project’s status at any given moment.
What we scoped instead: eight milestones on the project record, one owner field per milestone, a read-only link from the CRM record through to the operations tool for anyone who needs the detail, and three verification checkpoints promoted from hidden sub-steps into named stages. The two-way sync came off the roadmap entirely. Total build, a fraction of the integration, and the visibility the founder was asking for arrives in weeks instead of a quarter.
The playbook
- Write down the question first. Get the exact sentence the executive wants to be able to say, in their words. Every design decision below is judged against it.
- Pick the reporting home. One system answers “where is this.” It is usually the CRM, because that is where the funnel view and the forecast already live. Decide it out loud.
- Define six to ten milestones. Core transitions only. If you need more than ten, you are describing tasks, not milestones.
- Put an owner on every milestone. A named person, and it changes hands as the milestone advances.
- Declare the system of work per stage. One line per stage in the journey doc: here you work in this system, doing this.
- Write entry criteria and enforce them. No stage advance while the previous stage has open items. Promote every hidden go/no-go into a visible stage.
- Link, do not mirror. A read-only pointer from one record to the other covers the detail case. Sync only the milestone value, and only in one direction.
- Review it weekly against step one. If the executive still cannot say the sentence, the layer is wrong and you fix the layer, not the integration.
Most teams can do all eight in a couple of weeks. The integration they were about to commission would have taken a quarter and still not answered the question.
If your leadership team is asking where things stand and getting a different answer depending on who they ask, you have a visibility gap by design, not a tooling gap. We can map the status layer over your existing journey, or if the second system is a CRM you are still moving off, start with the migration. Either way, tell us what your executive is trying to see and we will tell you whether you need an integration at all.
Sources
- Forrester. “What Salesforce’s Acquisition Of Momentum Means.” Anthony McPartlin, February 2026. forrester.com
- SaaStr. “Lovable, Harvey and Assembly AI: How the Fastest AI Companies Rebuilt Customer Success.” Jason Lemkin, June 2026. saastr.com