The churn model was supposed to be one of the easy ones. Not an autonomous agent, not a redesigned workflow, not a customer-facing assistant. A prediction model built on the company’s own customer and account data, showing which customers were most likely to leave and where sales leaders should focus before revenue was at risk.
The demonstration began well. The dashboard was easy to follow, the risk scores were plainly explained, and the account list looked credible. Several leaders leaned in.
Then a sales leader paused over a customer near the top of the high-risk group.
“I don’t think that account is active anymore.” He shook his head. “This is why I don’t trust this AI stuff.”
It was the wrong conclusion drawn from the right observation, and it is the most expensive mistake in the room.
The Model did Exactly What It was Asked to Do
Nobody could answer immediately. Sales opened the CRM. Finance pulled a different account view from the ERP. Technology checked the feed that had supplied the model. The first differences looked small, the kind of discrepancies people explain away as timing issues or mapping problems between systems. The longer they looked, the harder those inconsistencies were to dismiss.
Several accounts flagged as high risk had closed months earlier. A few customers showed different revenue figures depending on whether the number came from Sales reporting or Finance’s ledger. One account appeared under two slightly different names. Another had been assigned to the wrong region after a territory change.
None of it looked dramatic on its own. Together, it changed the meaning of the output.
Notice what did not happen. The model did not crash, throw an error, or return something visibly absurd. It took the available information, treated it as reality, and produced a confident recommendation. The charts were polished. The rankings looked useful. The problem was not that the answer looked broken. The problem was that it looked believable.
By the end of the meeting the conversation was no longer about customer retention. It had become a quiet argument about which source the business actually trusted. Sales defended the CRM. Finance defended the ledger and called it the source of truth. Technology explained the feed. The vendor described what the model had received and stood by its performance. Everyone sounded reasonable. The implication was unavoidable: the company had asked AI to reason from information the company itself had never reconciled.
The Question Diane Asked that Night
Alex called Diane, the chief financial officer whose judgment he trusted when numbers looked cleaner than the business behind them, and walked her through all of it. The dashboard, the customer list, the conflicting sources, the inactive accounts, the duplicate names, the revenue mismatches. She listened without interrupting, then asked one question.
“Which version of the truth did the model use?”
“That’s exactly what we couldn’t answer,” Alex said.
“Then I wouldn’t start by blaming the model,” Diane replied. “A model can calculate from the information you give it. It can rank, predict, and organize. What it cannot do is resolve a business disagreement the business has never resolved.”
Alex admitted what had bothered him most. The output looked credible.
“Of course it did,” Diane said. “That is why this matters. Bad information does not always create an obvious failure. Sometimes it creates a better-looking wrong answer.”
Then the line worth carrying into your own review. If Sales and Finance do not agree on the customer, AI will not settle that for you. It will make the uncertainty look more polished. Before you ask whether leaders can trust the model, ask whether the model can trust the company.
Trust Needs an Owner
The distinction that follows is not technical, and it cannot be delegated to a data team.
Technology can move information, and a model can rank accounts. Only the business can decide what counts as an active customer, which revenue number matters for a sales action, and who has authority to resolve a disagreement between two official systems. Trust needs an owner, and that owner sits in the business. There is a second layer underneath the system fields, and most programs miss it entirely. Alex pushed his team past the repositories with one question: what does a knowledgeable employee know that the system does not? The room stopped naming systems and started naming situations.
A customer assistant needs approved language, warranty rules, service exceptions, and escalation guidance. A churn model needs the context behind the numbers: recent conversations, disputed status, known exceptions, and account commitments that never reached the official record. The practical standard is plain enough for a business owner to apply without a checklist. Is this context current enough for the decision, approved by someone accountable, and usable by the people and systems doing the work?
The Ninety-Day Project that Took a Hundred and Eighty
Bob, a three-time chief information officer, told Alex a story that explains why this surprises so many teams.
His project was scoped at ninety days. It took a hundred and eighty. Nothing about the technology failed, and nobody had underestimated the build. The data was not ready, and the way it was not ready took two months to even find.
The balances were right. Every account opened where it should have and closed where it should have, and the reconciliation passed the way it had passed for years. What was missing sat between those two points. The movement. The additions, the subtractions, the adjustments, the reason a number changed. Some of those fields were empty. Others held values nobody had maintained since the system was implemented. For reporting, none of it had ever mattered, because reporting only asks for the endpoints.
AI needed the middle. And when the middle was not there, the system did what these systems do. It produced an answer anyway.
The exercise surfaced errors the company had been carrying for a decade. Once they could be seen, fixing them was the fast part. The delay was in the discovery, not the repair.
Clean What the Use Case Touches
The wrong lesson is that a company must fix all its data before it can use AI. An enterprise data cleansing effort can become a multi-year commitment with little visible return until late, competing for funding against work that pays back sooner. Start there and the work stalls before it produces anything. The right lesson is narrower.
Clean the data the chosen use case actually touches. Not the customer master in its entirety, but the fields the assistant reads when it answers a customer. Not every product record, but the attributes the quoting process depends on. The scope sets the work, not the data model.
This is more than scheduling convenience. Data cleaned for one use case does not stay confined to it. Fix customer identity for the service assistant and sales inherits it. Fix product attributes for quoting and marketing and the catalog inherit them. Each use case pays for a piece of foundation the whole company then stands on, and the second is cheaper than the first because part of its ground is already laid.
Done deliberately, that is how a company arrives at an enterprise data foundation without ever running an enterprise data program.
What changes with AI is not the list of data problems. Duplicates, empty optional fields, decayed contact information, codes reused after the first purpose became obsolete — those have been measured for decades. What changes is the consequence. A duplicate customer record used to produce a slightly wrong report. It now produces a confident answer to a customer built on half their history.
Adapted from Feasible, Not Achieved: Why AI Transformation Stalls and the NINE Decisions That Finish It, by Weston A. Jones, MBA and Jacob C. Roxon, PhD (JRNine Press).
The Jones-Roxon Nine™ is the Operator’s System for AI Transformation.