How to use AI in customer success when your customer data isn't ready.

Does our customer data need to be ready before we use AI in customer success?

Most heads of customer success who have looked at AI for their team have hit the same wall, and it is usually raised by someone on their own side of the table. The CRM has two records for a third of the accounts. Product usage sits in a warehouse the team cannot query. Support tickets live in a tool that has never been joined to either. The health score that was supposed to bring it all together has been half-built for two years and nobody trusts it. The conclusion drawn in the room is that the team needs a data project before it can use AI, and the AI evaluation stops there.

TSIA's State of Customer Success 2026 describes the condition. Customer success automation only works when health scores, product telemetry and predictive models are accurate enough to support it, and the biggest barrier to a unified view of the customer is that the data sits in systems that were never joined to each other. Gartner's survey of 402 marketing and IT leaders found only 14% of organizations had achieved a 360-degree view of the customer. That figure is from 2021, and Gartner has not published a replacement.

So the wall is real. The question is whether a data project is the way through it, and the recent analyst evidence says a data project is the wrong first step, for a reason that also explains what the right one is.

Why the data project never finishes

Gartner's February 2025 research on AI-ready data is usually quoted for its warning: through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data, and 63% of organizations either do not have, or are not sure they have, the data management practices AI needs. Read on its own, that sounds like a mandate to fix the data first. The same research says something different about sequencing. Gartner's position is that data is AI-ready only for a specific use case, and that "there is no such thing as making data AI-ready in general or in advance." The data has to represent the use case it will serve, errors and outliers included, because a model trained only on the cleaned version has never seen the accounts it will be asked to judge.

That is why the general data project never finishes. A project to make customer data ready for AI, with no use case named, has no test for being done, so it runs until the budget does. McKinsey's June 2026 work on AI data readiness found only 7% of companies have fully scaled AI, and more than two thirds of the high performers named data as their primary obstacle. McKinsey's advice to those companies is the same as Gartner's: "the objective is not to achieve perfect data before starting, but to define what 'good enough' means for each use case."

There is a second reason the project fails to deliver what the team hoped for, even when it does finish. RAND Corporation interviewed 65 experienced machine learning leaders in 2024 and found that more than 80% of AI projects fail, twice the rate of IT projects that do not involve AI, with data problems the second most common root cause after misunderstanding what problem the AI was meant to solve. RAND's sharpest observation is about which data fails: data collected for reporting and compliance "carries too little context to train a model on," and leadership assumes the data is good because the reports arrive on time. That is a description of most CRM data. The fields a customer success manager fills in at the end of the day exist so that a pipeline report can be produced, and cleaning them makes the report tidier without adding the context that predicts whether the account renews. A CRM cleanup is a real project with a real cost, and at the end of it the team holds a cleaner version of the data RAND says cannot carry the load.

Why starting on messy data fails too

The other extreme fails for the reason McKinsey gives: "AI often amplifies both the risk of insufficient data quality and the complexity of addressing the problem." A system that reads every account will read the duplicates, the stale renewal dates and the accounts still assigned to people who left, and it will act on them at a scale no manager would.

The failures that matter in post-sales are specific, though, and they are narrower than "the data is messy." The practitioner account in The CS Cafe (2026) names two. One is unreconciled account identities: the same customer is three records in the CRM, one in billing and one in product analytics, and nothing says they are the same company. The other is fuzzy signal ownership: nobody has decided which system is the source of truth for the renewal date, the seat count or the last contact, so a health score built on them becomes, in The CS Cafe's phrase, politics. Both are joining problems, and joining for one use case is a piece of work with an end: these systems, these accounts, this date.

What ready means for one use case

Put the two halves together and the path is clear. Pick the use case, decide what good enough means for it, join the records it needs, and let the system learn from what happens.

Take the use case most customer success leaders would pick first: catching accounts whose usage is falling in the months before renewal. The five sources that analyst and vendor literature consistently name for post-sales AI are CRM records, product usage, support data, billing, and the interaction record of transcripts, emails and notes. This use case needs four things from them, joined at the account level: one identity per customer across CRM, product and billing; the renewal date and contract value from whichever system owns them; usage by account over time; and the recent conversations with that account. That is the whole list.

How much history is enough is a question the research answers with a negative result: no credible published benchmark specifies how much historical data a churn model needs, and any claim that a team needs a set number of months before starting is unsourced vendor content. The test is Gartner's, whether the data the team has represents the use case. If the accounts that churned last year show a usage decline in the data that already exists, the data is ready for this use case, and the system can start learning what that decline looks like at this company.

The part of the record most teams overlook is the one McKinsey says the AI depends on most. AI systems rely on unstructured content such as documents, emails and call transcripts, and the readiness problem McKinsey describes is linking that content to the structured records that define the customer and the contract. Unstructured content is, by the long-standing IDC and Gartner estimates, 80 to 90% of what an enterprise holds. For a customer success team that is the renewal call where the sponsor mentioned a reorganization, the email thread where the champion went quiet, and the support conversation that turned sharp. It sits in the recording tool and the inbox, outside every CRM field and every health score. It is the context RAND says reporting data lacks, it already exists, and readiness means attaching it to the account it belongs to.

Can you find churn risk without a health score?

The question comes up because the health score is the artifact that demands the full data project. A single blended score needs every input reconciled, weighted and trusted before the number means anything, which is why it turns into politics when ownership is fuzzy. A specific signal needs far less. "Usage in this account fell 40% over eight weeks and the renewal is in ninety days" needs one identity, one usage feed and one date. Each signal the team adds pulls in the data it needs and nothing more, and the account view assembles itself one use case at a time, which is the sequence the analysts describe.

How Trig does the joining work

Trig is built on the premise that the joining is the system's job. When Trig connects to a company's systems, it maps customer identities across them, merges duplicate records and organizes them into a coherent data model, so that every person, account and event is tied together even when the source data is scattered. It connects to the systems a customer success team already runs, including Salesforce, HubSpot, Snowflake, BigQuery, Segment, Mixpanel and Amplitude, and can reach other sources through MCP without engineering work when a feed is missing.

The result is what the Trig Context Engine calls a living profile of every customer. CRM, product, support and billing data are unified into one record per account, and the interaction record is kept alongside it: meeting transcripts, emails, notes and support conversations, so that Trig knows why a customer bought and what they think about the product, which is the unstructured context McKinsey describes. Journey Intelligence then measures each customer's progress at every stage of their journey against peers at the same stage, with no health score required. Revenue Signals flag changes in behavior for each account and rank them by revenue impact, which is the specific signal above, produced across the whole book.

The learning is also per use case. Trig uses renewal outcomes as the ground truth, whether each customer expanded, stayed flat, contracted or churned, and works out which behaviors in the months before renewal predicted each outcome for this company's customers. That is Gartner's per-use-case readiness in operation: the data that represents the use case is the company's own renewal history, errors included, and the model learns from it as more renewals occur.

Consider a customer success team of seven covering 600 accounts, with accounts in Salesforce, usage in Mixpanel, billing in a separate system, and eighteen months of call recordings nobody has gone back to. Around sixty of those accounts exist as two or more Salesforce records. On connection, Trig resolves the duplicates and matches the Mixpanel and billing identities to the Salesforce accounts, so the 680 rows become 600 customers. The first Signals, on usage decline ahead of renewal, are running within a few weeks, and the recent conversations with each flagged account are part of the context Trig holds on it. The unified account view is the byproduct of the first use case, and it is already in place for the second one, expansion signals in the accounts adding seats, when the team decides to switch it on.

What this means for the team

A head of customer success who is told the data is not ready now has a different answer. The general data project has no finish line and, per RAND, produces the kind of data that cannot carry the load anyway. Starting on unjoined data at scale amplifies the errors. The path the analysts describe runs between the two: name the first use case, decide what good enough means for it, join the records and conversations that use case needs at the account level, and let the system learn from the company's own renewal outcomes. The data does become unified along the way, one use case at a time, which is the only way Gartner says it ever happens.