When Gainsight and Salesforce disagree about the same customer

Gainsight says one number, Salesforce says another, and Stripe says a third. The obvious conclusion is that somebody has bad data.

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 since. Stripe may know what is actually being billed today, including 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 solve the problem. The question that matters in a QBR 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 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. You can make these syncs incredibly sophisticated with field-level ownership, conditional updates, bidirectional mappings, and conflict 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?

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.

Flattening it can destroy the signal 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 a domain in Zendesk. Before you can reason about anything those systems say, you have to know they're talking about the same company. A surprising 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 P1 that opened yesterday. Product telemetry knows whether anyone is actually using the thing. None of these systems necessarily has the complete picture, and that's okay. The mistake is expecting one of them to.

Third, facts age differently. 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 value isn't enough. You need the context around it.

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, Gainsight's Acme, Stripe's customer ID, and Zendesk's domain 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 just to manufacture agreement.

Instead, you 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 right 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

A person preparing for a QBR can notice that two dashboards disagree. They can 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.

An agent needs that context to be explicit. If we're going to let agents answer questions, update forecasts, identify risk, recommend actions, or eventually take those actions themselves, access to our applications isn't enough.

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. Giving a model access to more systems gives it more data. It doesn't necessarily give it more understanding.

AI outcomes are only as good as the 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 a company already runs. It resolves identity across them, preserves provenance and operational context, and makes that picture available to people and agents over MCP.

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 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. You often need 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. 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. Your software stack isn't.