Why AI pilots stall when CRM ≠ billing ≠ plant
AI pilots stall after acquisitions because the data was never joined: the CRM, billing, and plant systems disagree about who the subscriber is, what they pay for, and what's installed. Models can't fix bad joins. Establish one system of record per domain and validate the data first — then pilot.
The usual stall pattern
Week one: the pilot deck promises churn prediction or a support copilot. Week three: the data scientists discover the CRM has 40,000 subscribers the billing system never heard of, and the plant records use a different address format entirely. Week six: the pilot is "paused pending data remediation." The problem was never the model.
The unglamorous prerequisites
- One customer key that resolves across CRM, billing, and plant
- One service inventory: what's installed, where, and whether it's billed
- One billable-event stream the model can trust
- A named owner for data quality per domain — not a committee
What to do instead
Sequence it: stabilize the systems, choose the system of record, validate the data — then run the pilot on data you trust. A pilot on clean data from one domain beats a pilot on dirty data from three. And if a vendor's pilot doesn't ask about your data joins in the first meeting, that's your answer about the vendor.
Pilot stalled?
We'll tell you straight whether it's a data problem or a model problem. It's usually a data problem.