Most AI projects fail quietly. Not with a crash — just with a shrug. The tool works, technically. It answers questions. It generates stuff. But it doesn't change how the business runs. We've found the reason is almost always the same: the AI only knows what's in front of it. Cross-domain intelligence fixes that. It's what happens when a system draws connections across data sources that were never designed to talk to each other — and surfaces things no single person, no single dashboard, would have spotted alone.
This is a case study. One client. One build. Real numbers — including the part that didn't go to plan.
What is cross-domain intelligence, exactly?
It's when an AI system synthesises signals from multiple, unrelated data sources to produce insights that wouldn't be visible from any single source alone. Not a feature. An architectural choice — one that has to be deliberate from day one.
A CRM knows your sales pipeline. A support tool knows your ticket history. An analytics platform knows your traffic. None of them know what all three say together about a specific customer segment at a specific point in time. Cross-domain intelligence connects those layers. The result isn't just better reporting — it's a fundamentally different kind of question you can ask. Not "how did sales go last month?" but "which customer types are most likely to churn within 60 days, given their support history and engagement drop?" That distinction is everything.
What was the actual problem we were solving?
The client runs a B2B SaaS platform with around 400 business customers. Their team was smart, data-literate, and drowning. Three separate systems — Salesforce, Intercom, and a custom analytics dashboard — none of which shared a common identifier for accounts. Customer success managers were copy-pasting data between tools to build a picture of any single account. About four hours per account review. Per week. Multiply that by a team of six and you've got 24 hours of context-assembly work that produced insights already stale by the time they landed.
They'd tried a BI tool. It pulled data fine. But it still required a human to join the dots — to see that the account with declining logins also had three unresolved support tickets and a renewal coming up in 45 days. The BI tool showed each fact. It didn't connect them.
How did we approach the build?
We started where we always start: with the question, not the data. What decision does this system need to support? Here, that was: which accounts need attention right now, and why? That single question shaped everything — the data model, the ingestion logic, the output format.
We built a lightweight ingestion layer that normalised account identifiers across all three platforms. That part sounds boring. It was also the hardest part. Salesforce used one ID format, Intercom used email as the primary key, and the analytics dashboard used a UUID that bore no relation to either. Getting those to resolve to a single account entity took two weeks of mapping work we genuinely underestimated. I'd flagged this risk in the scoping doc and we didn't weight it heavily enough. Lesson absorbed.
Once entity resolution was solid, the intelligence layer was almost straightforward. We fed the unified account profiles — sales stage, support ticket velocity, product engagement trends — into a model that scored accounts on risk and opportunity. The output was a daily briefing: ranked accounts, plain-language reasons, suggested next actions. You can see similar thinking in how we structured the Telehance build — unified context, one output, clear next step.
What happened when it went live?
Account review time dropped from four hours to 12 minutes. That number surprised even us. The customer success team went from reviewing 15 accounts per week — because that's all they had bandwidth for — to reviewing their entire book, every week. Coverage went from roughly 22% to 100%.
But the more interesting outcome was what they found when they actually looked. Three account segments that had been invisible before became suddenly obvious: accounts with high product usage but low support engagement (healthy, safe to deprioritise), accounts with declining usage and no recent sales contact (high churn risk, needed immediate outreach), and accounts with heavy support load but strong renewal signals (expansion opportunities hiding inside complaints). None of those patterns existed in any single system. They only appeared when the systems talked.
Within the first 90 days, the team flagged 11 accounts that would likely have churned without intervention. They saved 7. At an average contract value of £18,000, that's £126,000 retained — against a build cost that was a fraction of that.
What went wrong and what would we change?
Entity resolution nearly sank the project. We'd estimated two to three days. It took two weeks. That delay compressed the testing phase, and we shipped with a known edge case: accounts created in Salesforce within the last 30 days didn't always resolve correctly against Intercom records, because the sync cadence hadn't propagated yet. We flagged it, documented it, and shipped anyway — the client needed the tool and the edge case affected less than 5% of accounts. In hindsight, we should have built the lag-handling logic first, not last.
The other thing I'd do differently: involve the customer success team two weeks earlier. We built the risk score logic based on what leadership thought mattered. The CS team had a completely different mental model of what "at risk" looked like on the ground. When we brought them in — which we did, eventually — we reweighted three signals entirely. The final model was better for it. But we lost a sprint doing that reweighting late rather than getting it right early.
If you're commissioning something like this, read our notes on the Forge build — we made similar mistakes there and wrote about it plainly.
What does this mean if you're in a similar spot?
If your team is doing manual context-assembly — pulling data from three tools to answer a question that feels like it should be automatic — you're not behind on technology. You're behind on architecture. The data exists. It's just not connected. And the gap between "data exists" and "data produces insight" is exactly where most AI investments go to die.
Honestly, cross-domain intelligence doesn't require a massive data platform or a six-month build. It requires clarity on one question — what decision does this system need to support? — and the patience to get entity resolution right before you do anything else. If you want to talk through what this could look like for your business, the contact page is the fastest route. No pitch decks. Just a conversation about what's actually slowing you down.
You can also read more on this and related builds over on the Nuclear Marmalade blog — we write about what we build, including the parts that didn't work first time.
Key Takeaways
- Cross-domain intelligence means connecting signals across systems that were never designed to talk — the insight only exists in the connection, not in any single source
- Entity resolution is always harder than you think. Budget real time for it, or it'll eat your testing phase
- The right question to start with isn't "what data do we have?" — it's "what decision does this system need to support?"
- Account review time dropped from 4 hours to 12 minutes; coverage went from 22% to 100% of the book. The numbers that matter are downstream: £126k retained in 90 days
- Bring end users into the model design early. Leadership and frontline teams have different mental models of risk — and the frontline team is usually more right