AI Strategy for Sales and Marketing: Connecting Marketing, Sales and Customer Experience

By Katie King

9 min read

Why does it matter? Because the companies winning with AI aren't the ones with the best models — they're the ones people trust enough to share data with.

Every executive in this space has the same instinct: get better data, build a smarter model, move faster than the competition. It's reasonable. It's also the wrong frame. The companies extracting durable value from AI aren't winning on algorithm quality. They're winning because their customers trust them enough to share better data, their regulators trust them enough to lower compliance costs, and their employees trust them enough to actually implement rather than quietly route around. The technology commoditizes inside a decade; the organizational character that makes it work doesn't. Katie King spent years interviewing the people actually running these deployments — practitioners, not pitch-deck presenters — and what kept surfacing wasn't a model architecture. It was accountability. The question this book really answers isn't which AI to use. It's whether you're the kind of company that deserves to.

The Competitive Window Is Real — And Shorter Than Anyone Is Admitting

Somewhere over the North Atlantic, a Rolls-Royce engine is quietly generating data. Sensors track temperatures, pressures, and vibrations: trillions of readings annually, all flowing back to a team called R2 Data Labs. Caroline Gorski, its Group Director, turns that data into predictive maintenance algorithms that keep planes airworthy and clients locked in. From the outside, it looks like exactly the kind of proprietary moat every executive claims they're building with AI.

Then she tells you what it actually is. Almost every modelling technique her team uses is either open-source or comes straight from academic research. The algorithms are shared across the industry. "There is very little to wrap your arms around and define as exclusively yours," she says. What Rolls-Royce has isn't a secret weapon — it's a head start, and a shrinking one.

Most executives assume competitive advantage in AI lives in the model. It doesn't. The model is a commodity. What Rolls-Royce has is deployment experience in a domain tight enough that the combination still produces something unique — for now. The window is compute costs. Companies that can afford today's high-performance chips move faster. Gorski is blunt about the timeline: in ten years, chips will be cheaper. The differentiation evaporates with the price.

The countries that grasped this are already compounding their lead. China has filed 106,650 AI patents. The United States sits at 60,003. The entire European Patent Office has recorded 5,201. Samsung alone holds more patents than every European filer combined, and no European company appears in the global top twenty. For any company still deliberating, those numbers are the answer: the gap compounds, and waiting doesn't close it. The countries treating AI as a decade-long sprint are lapping the ones still running it as a pilot program.

Most companies facing an AI decision right now are asking the wrong question: which model to use, whether their data is good enough, whether to wait for better tools. Gorski's point cuts through all of it: the algorithm was never the advantage. Speed of deployment into a domain you actually understand is what closes before the debate is over. The problem is that most organizations are still trying to figure out which debate to have.

Most AI Projects Fail Because They Are Technology Projects

Most AI projects fail for an organizational reason: companies start with the technology and search for problems to attach it to.

Regit, the UK's largest online platform for drivers, had the reverse problem. Two and a half million registered users, no way to know which ones were about to change their vehicle. They found out after the sale, which made their call-centre lead generation effectively blind: ring enough people and some will be ready. They brought in Peak, a Decision Intelligence firm, and together built a system that pulled DVLA vehicle records, website behavior, and marketing signals into a single probability score — how likely each user was to switch vehicles soon. That score fed directly into the CRM. Agents stopped calling down a list. They called the people most likely to buy.

The sophistication of the model underneath isn't what made this work. What mattered was that someone started with a specific business question — who should we call next? — and worked backwards to the technology. The result: a 27% revenue increase within thirty days and a 35% reduction in operational costs. The mechanism is the point. Not a smarter algorithm; a sharper decision.

Richard Chiumento, who advises executives on leadership through transformation, has watched enough AI projects founder to name the pattern directly: "It's a people change programme that is required, not a technology change programme." The companies that embed AI into how real decisions actually get made (who to call, when, in what order) see returns. The companies that layer AI on top of existing processes and wait for productivity to follow see expensive pilots that never graduate.

The failure pattern isn't mysterious. A company invests in an AI platform (data infrastructure, tooling, vendor contracts) and assigns a team to find applications for it. The team finds applications. They build demos. The demos work. But the organization hasn't changed how decisions get made, so the capability sits adjacent to the work rather than inside it. Chiumento's point is structural: the technology is easy to acquire. The hard part is redesigning which decisions get made, by whom, with what information. That's the change programme.

Machine Learning Is the Wrong Tool for Your Most Important Decisions

What do you do when a wrong decision doesn't just cost you revenue — it costs someone their home?

When five of the six largest global accounting firms needed to automate tax decisions, they didn't reach for machine learning. They chose Rainbird, whose CEO James Duez draws a distinction most executives never make. "AI is a singularly unhelpful term," he says. What most people call AI is machine learning: pattern recognition trained on historical data. Rainbird works differently.

Duez calls his approach "human down, not data up." His team works directly with subject matter experts (senior tax partners, fraud analysts, credit decisioning specialists) and encodes their reasoning into a visual knowledge graph. Every rule, every conditional, every edge case is mapped explicitly. Rainbird makes decisions by following that logic rather than detecting statistical correlations in past outcomes. It can be audited. It can explain itself. When it flags a transaction as suspicious, it can tell you exactly which combination of rules triggered that flag.

The performance numbers look counterintuitive until you understand the mechanism: decisions arrive 100 times faster than the human experts who built the model, and 25 percent more accurately. The accuracy gain comes from consistency. Human experts make the same reasoning error repeatedly when fatigued or working from incomplete information. The knowledge graph doesn't tire.

The distinction the rest of AI enthusiasm tends to skip is structural. If a recommendation engine surfaces the wrong product trend, a marketer runs a suboptimal campaign — the cost is commercial. But when a bank's credit model rejects a loan or flags a customer for financial crime, the cost is personal, and in most jurisdictions, legally contestable. Regulators don't accept "the model said so." ML, by design, cannot explain what it said. Rainbird can, which is why five of the world's largest accounting firms use it for automated tax decisions and banks rely on it for fraud, credit, and know-your-customer compliance.

Trustworthy AI and Ethical AI Are Not the Same Thing — and Confusing Them Is Dangerous

An AI that reliably does what you built it to do is not, by that fact alone, a good AI. Caroline Gorski, Group Director of R² Data Labs at Rolls-Royce (whose engine monitoring work we saw earlier), draws a line most AI ethics discussions blur: trustworthiness and ethics are separate questions, and collapsing them is how organizations build something dangerous at scale.

The Aletheia Framework (named after the Greek concept of truth as disclosure) emerged from a decade of building jet engine health monitoring systems under oversight from EASA, Europe's aviation safety authority. Rolls-Royce's AI had to process more than twenty-six complex variables simultaneously and recommend whether planes in the air were safe to keep flying. The team eventually realized the rigor they'd developed, a checklist of trustworthiness checks, could be abstracted away from aerospace entirely. The same framework that governed safety decisions about airborne engines worked equally well for detecting bias in an HR system's candidate-screening algorithm. CEO Warren East published it open-source. Standards in emerging technology, he concluded, matter more to civilization than any competitive advantage they'd yield by keeping it private — regulators who can inspect your framework don't fight you at every audit, and customers who trust the system share more without demanding compensation in return. That trust compounds.

But here's what most organizations miss: Aletheia's trustworthiness checks answer one question — does this AI do what we designed it to do, reliably, consistently, in a way we can verify? That question is necessary. It is not sufficient. As Gorski puts it: you can build an AI that undermines democracy, and build it in a trustworthy way. Trustworthiness means it does its job. Ethics asks whether that job should have been assigned in the first place. A trustworthy AI executing an unethical purpose doesn't just commit harm — it scales it, repeats it without fatigue, and does so with the institutional credibility of a verified, auditable system.

For Rolls-Royce, wrapping trustworthiness checks inside explicit ethical principles isn't a philosophical exercise. It's an engineering requirement. What end should this AI serve? Who bears the cost if it serves that end faithfully? The framework demands answers before the build, not after deployment.

Five Rules From Someone Who Has Actually Watched AI Fail in Production

March 2020. Comcast's Elad Nafshi is watching dashboards absorb a 32 percent internet traffic surge — demand the company typically prepares for over 12 to 18 months. Schools are closed. Offices are closed. 59 million US households are suddenly all online at the same hours. There is no time to add capacity.

What held the network up wasn't capital investment in fiber. A piece of software called Octave was quietly checking more than 4,000 telemetry data points across 50 million modems every 20 minutes — adjusting each modem automatically when it detected inefficiency. Engineers compressed months of rollout into weeks. Customers experienced a 36 percent capacity increase at the exact moment demand spiked.

That's what AI looks like when it's working: invisible, continuous, operating on behalf of the people using the system rather than the team that built it. The failure mode most executives imagine — wrong model, bad data — is not actually the most common one. The most common failure is building AI that serves the analyst or the IT department rather than the person the product is supposed to help.

Vic Miller, VP of Global Communications at Brandwatch — a platform that has indexed 1.5 trillion social conversations — sees the opposite failure constantly: AI built to serve the analyst's workflow rather than the customer's need. Her five rules are each a response to a specific failure she has watched happen in production.

Start by doing the work manually. Before you automate anything, do it yourself. Understand what inputs actually matter, what edge cases appear, where human judgment currently compensates for bad data. If you skip this, you cannot tell the difference between AI doing the task well and AI doing it confidently wrong.

Train on your own data, not someone else's. Generic datasets produce generic performance. A model trained on retail conversations will misread your healthcare customers' language. Accurate in general; wrong for you specifically.

Audit quarterly. This one surprises people: ML models don't only improve with time. As datasets diversify and language shifts, they can lose precision. The model you tested a year ago is not necessarily the model you have today.

Treat it as an assistant, not a source of truth. Check AI output against your own analysis. Catch errors before they become decisions. If the AI says something you wouldn't have concluded yourself, that's a reason to look harder, not defer faster.

Use it only where speed genuinely matters. Do it manually otherwise — you'll discover something the model compressed out. Usually it's a nuance: the edge case that appeared in three posts but never hit statistical weight, the customer phrasing that doesn't map to your sentiment categories, the signal a model trained last year has no vocabulary for.

These rules don't require a PhD in machine learning. They require organizational discipline — someone with authority to enforce quarterly audits, someone who insists on manual piloting before deployment, someone who treats the AI's output as a first draft. That person is the most important variable in any AI project. Most teams underspend there and overspend on the model.

The Algorithm Ceiling Is Already Dividing Your Workforce — and Courts Are Noticing

A Deliveroo rider in Milan misses a scheduled shift. He is sick, but the company's algorithm has no mechanism for context. What it has is a reliability index — a score that drops whenever a rider fails to cancel at least twenty-four hours in advance. A lower score means fewer priority slots in busy periods. Fewer busy slots mean less income. In January 2021, an Italian court ruled this system discriminatory. CGIL, Italy's largest trade union, backed the riders' case. The court's finding was precise: the algorithm wasn't broken. It was doing exactly what it was designed to do — and that was the problem.

What happened in Milan is already happening inside your company. Leila Seith Hassan, who leads data science at Digital UK, identifies the structural trap: AI is data plus math plus people. The data is what most organizations underestimate. Historical training data encodes the bias behind past decisions and teaches the model that this bias is predictive. Insurance algorithms that overcharged customers in certain zip codes learned that pattern from prior human decisions. The model didn't introduce the discrimination. It found it, treated it as signal, and scaled it.

Hassan calls it an algorithm ceiling. One portion of your workforce uses AI as a tool. It surfaces candidates, flags accounts, drafts outreach. For another portion, the relationship inverts: an algorithm schedules their shifts, monitors their pace, and can effectively terminate them without a manager reviewing the case. There's no appeal, no context, no accountable person between the worker and the system's decision. The divide is about who retains agency over their own working conditions and who doesn't. It widens as adoption deepens.

Courts are drawing lines. Uber drivers in the UK sued for access to their algorithmic performance data. The UK's Financial Conduct Authority found insurers using opaque models to identify customers unlikely to switch, then quietly raising those premiums each year. The common thread: systems built to optimize for the organization at the direct expense of the people passing through, with no one accountable for the result.

The choice isn't whether to use AI. That argument is settled by now. The choice is whether accountability is designed into the system before it produces a result someone contests in court. Or after. One of those options is still available to you.

What You Build Into the System Now Is the Only Part You Control Later

The book's unresolved tension is its most honest argument. Move fast. The window is closing. But move without accountability and someone else closes it for you, from the outside, in a courtroom in Milan or a regulatory finding in London or an employee lawsuit that redefines what your system was actually optimizing for. Caroline Gorski built the Aletheia Framework because the alternative — deploying AI over cities without a structured answer to "what could this do to people?" — was unacceptable before the first flight. Most organizations don't have jet engines. They have hiring systems, credit models, shift schedulers, and pricing algorithms. The question isn't whether someone will eventually force accountability onto those systems. They will. The only question left is whether you designed it in first.