When Gainsight and Salesforce disagree about the same customer

When Salesforce and Gainsight report different health for the same customer, the problem is bigger than a field mapping. It is a CRM data quality question about identity, freshness, source ownership, and which evidence a revenue decision should trust.

Gainsight says one number, Salesforce says another, and Stripe says a third. The obvious conclusion is that somebody along the way entered bad data...or maybe even just forgot to update it.

Usually, that isn't what's happening.

Salesforce may be holding the ARR a rep entered when the deal closed. Gainsight may reflect what customer success has maintained now that they are a customer. And Stripe may know what is actually being billed right now, including any changes that happened after the contract was signed. They're not necessarily conflicting versions of the same fact...they're different observations about the same customer.

And that's why the usual answer, "syncing the systems", doesn't really hold water. Often times, the question that matters isn't which system is wrong. It's which number you're supposed to say out loud.

Syncing makes things match. It doesn't make them true.

The natural instinct when two systems disagree is to sync them. Pick a source, map the fields, push the values across, and make everything line up.

I've built a lot of integrations over the years, and this almost always goes sideways. You can make these syncs incredibly sophisticated with field-level ownership, conditional updates, bidirectional mappings, and even conflict remediation rules. But eventually every sync has to make a decision about what gets written where. Once you write a value into another system, something important can get lost: why were the values different in the first place?

It becomes a game of whack-a-mole.

The difference between contracted ARR and billed ARR isn't necessarily bad data. Maybe the customer expanded...or contracted. Maybe the contract says one thing and billing says another. Maybe one system simply hasn't caught up yet.

The disagreement is information.

And, flattening it can destroy signal that you actually care about.

There are really three problems hiding underneath this

When people tell me their customer data is messy, I usually see some combination of three things.

First, the same customer has different identities everywhere. "Acme Corp" in Salesforce, acme-corp in Gainsight, a customer ID in Stripe, and an "acme.com" in Zendesk. Before you can even begin to reason about the data in those systems, you first have to know they're talking about the same company. A material amount of operational work still comes down to reconciling some version of this by hand.

Second, every system knows something different. Sales knows what was sold. Billing knows what was billed. Customer success knows what happened in the relationship. Support knows about the critical issue(s) that opened yesterday. Product telemetry knows whether anyone is even actually using the thing. None of these systems necessarily has the complete picture, and that's actually okay. The mistake is expecting one of them to.

Third, facts age at different cadences. A close date from two years ago can still be perfectly valid. A health score from two weeks ago might already be stale. A green account health score means something very different when you also know the customer's champion left 41 days ago and a P1 escalation opened yesterday.

The values alone aren't enough. To reason effectively you need to understand the context that exists between them.

Resolve the customer, not the systems

This is the distinction that led me to build SixDegree. Instead of trying to make every operational system agree, leave them alone and resolve the entities underneath them.

Salesforce's "Acme Corp", Gainsight's "acme-corp", Stripe's customer ID, and Zendesk's "acme.com" become observations about the same customer. Contracted ARR can remain the CRM's claim. Billed recurring revenue can remain billing's claim. The health score can remain Gainsight's claim. You don't have to throw any of them away in order to manufacture agreement.

Instead, you can know what each value means, where it came from, when it was observed, and how it relates to everything else you know about the customer. When someone asks a question, you don't have to pretend there is one universally correct field sitting somewhere. You can resolve the correct operational answer for the question being asked.

That's a very different thing from syncing data.

What becomes answerable

Once the customer is one entity instead of four disconnected records, questions that used to require manual reconciliation become pretty ordinary:

• Which accounts look healthy in Gainsight but have an open P1 in support?
• Where does contracted revenue disagree with billed revenue, and why?
• Which renewals are inside 90 days on accounts whose usage dropped last month?
• Which customers lost their main contact, according to any system that would know?
• Which renewals need attention this week, and what changed since we last reviewed them?

None of those questions lives entirely in Salesforce, Gainsight, Stripe, or Zendesk. The answer exists in the relationships between them.

This gets much more important with agents

Today this work is accomplished, largely, through human reasoning. Someone (usually the de facto person "who knows that answer") is the glue correlating these signals into some meaningful insight.

They notice that two dashboards disagree. They open another tab, ask someone in Slack, check the billing system, and figure out what happened. Humans do this kind of context assembly constantly, often without thinking much about it. But it is laborious, slow, and inefficient. Worse, when this person leaves the company, their know-how leaves with them.

If we expect agents to take on these painful tasks, the context needs to be explicit. Answering questions, updating forecasts, identifying risk, recommending actions, and even taking those actions themselves, requires a lot more than just access to our systems of record.

An agent needs to know which customer it's looking at, where a value came from, how fresh it is, what else has changed, and whether another system disagrees. More importantly, it needs to understand which information actually applies to the question it's trying to answer.

That's the part I think gets missed in a lot of the conversation about enterprise AI. Adding more connectors to your Claude session doesn't give it more understanding. It just gives it more context to misinterpret. Almost all of the reasoning lives in the relationships, not the data itself.

AI outcomes are only as good as the relational context underneath them, and enterprise context doesn't live in one system.

That's what SixDegree is for

SixDegree derives a live graph from Salesforce, Gainsight, Stripe, Zendesk, and the other systems your organization has already invested in. It resolves identity across them, preserves provenance and operational context, and makes that picture available to both people and agents.

There is no requirement that Salesforce and Gainsight suddenly agree, and no need to turn another application into the destination for everything the company knows. The systems can keep saying what they know.

SixDegree understands how it fits together.

Frequently Asked Questions

Why do Gainsight and Salesforce disagree about the same customer?

Because they can be observing the customer from different parts of the business and at different points in time. Salesforce may contain what was sold and what the account team has recorded. Gainsight can combine a configurable set of customer health measures, including things like product usage, support signals, and subjective assessments. Billing, support, and product systems may know still other things. The disagreement isn't necessarily evidence that one system is wrong. Often it's evidence that each system only has part of the picture.

Should I sync Gainsight and Salesforce customer data?

Sometimes. Syncing is useful when an application genuinely needs a value written into it, and SixDegree isn't an argument against synchronization. But syncing and resolving are two different problems. A sync decides what value should be copied somewhere. Resolution preserves what the underlying systems know and gives you enough context to understand how those observations fit together. Effective reasoning requires both.

Which system should own ARR?

There may not be one answer until you define what you mean by ARR. Contracted ARR, billed recurring revenue, recognized revenue, and forecast revenue describe different things. And, often times, the answer needs to be bound to the context from which it was asked. The important part is knowing what a value represents, where it came from, and when it was true, rather than allowing whichever integration ran last to silently define the answer.

What data belongs in customer health?

Potentially more than exists natively in any one customer success platform. Support activity, product usage, billing status, CSM observations, meeting activity, relationship coverage, executive engagement, and changes such as a champion leaving can all matter. Those signals tend to live across multiple systems. That's the fundamental problem: the customer is one thing. The data that defines it is scattered across systems of record.