A Series B SaaS company we talked to last quarter almost lost a $180,000 renewal because three of their tools disagreed about the same customer. Salesforce showed the account as "Healthy, Expansion Target." Zendesk showed 14 open tickets, 4 of them Sev-1, going back six weeks. Linear showed a P0 integration bug on that customer's primary workflow, unassigned for nine days. The AE walked into the QBR with the Salesforce view and got ambushed with a churn threat he did not know existed.
Nobody at that company was lying. Each tool was telling the truth its team had put into it. The problem is that no team owned the version of the customer that the other teams needed to see.
This is the cross-functional customer visibility problem, and it is the single most under-invested operational gap in mid-market companies right now.
It is not a data silo problem. It is a workflow problem.
The default diagnosis when a CRM and a support platform disagree is "we have data silos, we need a data warehouse." That framing is wrong, and it is why most fixes fail.
Sales uses Salesforce or HubSpot because their job is to move a pipeline through stages. The data model is opportunities, stages, close dates, forecast categories. Support uses Zendesk or Intercom because their job is to resolve tickets inside an SLA. The data model is tickets, priorities, response times, satisfaction scores. Engineering and product use Linear, Jira, or Asana because their job is to ship. The data model is issues, sprints, cycle time, blockers.
Each tool is not storing a wrong version of the customer. It is storing the slice of the customer that its team actually acts on. The fragmentation is not a bug in the data. It is the operational reality of how the work gets done.
Which is why a data warehouse does not fix it. A warehouse pulls the three versions into one place and creates a fourth version nobody uses to do their job.
Why Customer 360 projects keep failing
Gartner called this in 2021 and the call has gotten sharper every year since. Their prediction: by 2026, 80% of organizations pursuing a 360-degree view of the customer will abandon those efforts, citing financial cost, near-impossible technical challenges, regulatory scrutiny, and data collection practices misaligned with what customers actually want (Gartner, via MarTech).
Two numbers tell the story in plainer terms:
- Only 14% of organizations have achieved a 360-degree view of the customer, despite 82% saying they aspire to one (Gartner Marketing Survey).
- 54% of customers say it feels like sales, service, and marketing at the companies they buy from do not share information, despite 76% expecting consistent interactions across those departments (Salesforce State of the Connected Customer).
The aspiration is nearly universal. The delivery is not even close. After two decades of trying, fewer than one in seven companies have built the thing every company says it wants.
This is not because the technology is missing. The CDP market alone is projected to grow from $5.1 billion in 2023 to $28.2 billion by 2028 (CDP.com Industry Studies). Tools are not the bottleneck. Tool sprawl is. Mid-sized companies (1,500-4,999 employees) ran on an average of 101 SaaS apps in 2025, and the typical enterprise now manages around 275 applications, with roughly 53% of licenses unused or underutilized (BetterCloud SaaS statistics).
Every additional system is one more place where the customer record can drift from every other system.
Warehouse vs. reconciliation layer
A warehouse project tries to create a new source of truth: one schema, one record, one canonical version of the customer that every team agrees to defer to. It takes 9-18 months, involves a procurement cycle across three or four functions, and at the end of it your AEs still open Salesforce, your CSMs still open Zendesk, and your PMs still open Linear. The dashboard the warehouse powers is the thing nobody has time to check.
A reconciliation layer does something much smaller and more useful. It pulls from the three tools your teams already live in, compares the records for the same customer, flags the disagreements, and pushes the important ones back into the tool where the relevant team will actually see them.
Concretely, for the SaaS company in the opening: a reconciliation layer would read the Salesforce account, the Zendesk ticket volume and severity, and the Linear issue backlog every morning. When it sees an "Expansion Target" account with 4 Sev-1 tickets older than 14 days and a P0 customer-blocking issue unassigned in Linear, it does two things. It writes a health flag into the Salesforce account record. It posts a Slack alert to the account team. The AE opens Salesforce tomorrow and sees the flag before they schedule the QBR.
No new source of truth. No warehouse. No team has to change where they work. The tools stay fragmented because the teams stay specialized. The reconciliation layer just makes the fragmentation stop being invisible.
The first reconciliation function to build
You do not start with a platform. You start with one disagreement that costs you money, and you build the function that catches it.
For most mid-market companies with a CRM, a support platform, and a PM tool, the first function is always the same: a churn-risk reconciler that runs on accounts marked healthy in the CRM. It reads three inputs:
- Open tickets from Zendesk or Intercom for that account: count, severity, age.
- Open issues in Linear, Jira, or Asana tagged to that account: priority and age.
- Product usage signal, if you have one: DAUs, key-feature adoption, trending direction.
It applies a simple rule. For example: any "Healthy" account with 3+ tickets aged 14+ days OR a P0 issue aged 7+ days OR a 30%+ drop in weekly active usage gets flagged. It writes the flag to the CRM account and pings the AE or CSM in Slack.
That is one function. It takes a week to build against the APIs the tools already expose. It catches the exact failure mode the SaaS company in the opening lived through. And it costs less than one seat of most CDPs.
Once that function works, you build the next one. Maybe a sales-to-support handoff reconciler that catches new customers closed in the CRM but not yet onboarded in the support platform after 10 days. Then a marketing-to-sales one. Each function is narrow, owns one disagreement, and can be replaced or retired without taking down the others.
This is the part most teams get wrong. They treat visibility as a platform decision when it is actually a pipeline decision. You do not need one tool that sees everything. You need a handful of small, targeted reconciliations that make the disagreements between your existing tools impossible to miss.
The question worth asking this quarter
Before the next "single customer view" vendor demo, pick the three tools your revenue teams live in. Pull up the same five accounts in each. Ask whether the three tools agree on what is happening with those accounts right now. If they do not, and for most mid-market companies they will not, count the number of decisions your teams made last month based on the wrong version.
That number is your reconciliation gap. It is almost never a warehouse problem. It is an operational layer waiting to be built.
If you are trying to figure out where your own reconciliation gaps are costing you revenue:
- Walk through the problem with us. No demo, no pitch. We map your stack and the three disagreements most likely to cost you a customer this quarter. Book a working session.
- Or see how we think about this for companies in your stage: /companies.