Why we don't write AI strategy decks

Most “AI strategy” engagements end the same way: a deck, a roadmap, a polite handshake, and zero production code. The slides look great in a steering committee. Nothing ships. Six months later the same team is hiring another consultant to update the same deck.

We don’t do that.

What we do instead

When a client comes to us, the first thing we ask is not what AI tools should we use — it’s what numbers are you trying to move next quarter, and where is the bottleneck today. If the answer is fuzzy, we say so. If the answer is clear, we go look at the work.

That’s the audit week — step one of our process. One week, inside your stack: CRM, calendar, support inbox, ops platform, the spreadsheets nobody talks about in meetings. We map the actual flow of work, not the org chart. By Friday we know the three highest-leverage places to put an automation, and we tell you which one to ship first.

You get a written roadmap. If you decide to work with another partner after that, the document is yours — it’s not gated, not encrypted, not “valid only with FLEXINAI”. A good audit is useful even if we never build anything together. That’s the test.

A recent engagement made this concrete. The client was halfway through a six-figure budget with another agency: forty slides, three personas, two roadmaps, no working code. By Wednesday of our audit week we’d traced the actual bottleneck to a missing webhook between their CRM and their billing system — a 90-minute fix that recovered roughly 12 hours per week of manual reconciliation. The deck never mentioned it because the deck never sat inside the workflow.

Why decks fail

A strategy deck assumes the org will read it, internalize it, and act. In practice:

• The people on the call aren’t the people who write the code.
• The roadmap is built against a snapshot of the business that’s already out of date by week 3.
• The deck contains no instrumentation, no fallback, no logs — so even if someone implements it, nobody knows whether it worked.

A shipped system answers the inverse: the people closest to the work use it on Monday morning, the metrics it touches are visible on a dashboard, and the rollback plan is one feature flag away. That’s the only kind of “AI strategy” we believe in.

A common anti-pattern: the six-month deck project

Here’s a shape we see every quarter. A mid-market B2B company decides AI is a priority. They hire a strategy consultancy, often a brand name. The first six weeks produce a “current state assessment” — diagrams of departments, lists of tools, interviews with stakeholders. Useful as a snapshot, but already stale by week three because the business doesn’t stop while the deck is being written.

Weeks seven through twelve produce the “future state” — a glossy slide showing AI plugged into every layer of the org, with arrows that imply integration but reference no specific tool, API or data pipeline. Roadmap is presented in twelve-month phases. Budget for “Phase 1 implementation” lands at three to seven times what a working system would actually cost, because no one in the room knows what a working system actually costs.

Six months in, the implementation has not started. The deck has been presented to the steering committee, the executive committee, and the board. Each presentation generates more “alignment” but moves zero code into production. By month nine, leadership rotation kicks in — the sponsor leaves, the project loses momentum, the budget gets reassigned to whatever’s next on the agenda.

This isn’t a strawman. It’s the default outcome for AI engagements priced over €200k when the deliverable is “a roadmap.” The fix isn’t a better deck. The fix is to refuse the contract that starts with a deck.

What we ship in week 1

Concretely, by Friday of audit week the client team has in their hands:

• A short PDF (not a deck) — 8 to 12 pages, no animations, no rebranded stock illustrations — naming the three highest-leverage automation candidates with rough scope, integration list, expected impact and a “what could go wrong” paragraph for each.
• A working prototype of at least one of those three, behind a feature flag in their own environment. Not a Figma mockup. A live integration that calls real APIs and reads real data, even if rate-limited or restricted to a sandbox account.
• A two-paragraph runbook of what we did during audit week so internal engineering can repeat the diagnostic later without us in the room.
• An honest scope for the build phase, with cost, calendar and the names of the operators who’ll be on it.

That’s the test. If we can’t put a working prototype in your hands by Friday, the engagement was an audit, not a build, and we refund the second half of the audit fee. We’ve done that twice. It’s not common — but the option matters.

The honest tradeoffs

We don’t pretend everything is fast. Some workflows need a custom UI, an auth layer, multi-tenant data — that’s a 6 to 8 week build, not a sprint. Some lead pipelines need 4 weeks of behavioural data before the scoring is worth trusting. We tell you that on day one. Surprises in week 6 are the worst kind of surprise.

We also don’t pretend AI is the answer to every problem. About a third of the time, the actual bottleneck is a missing API integration, a broken handoff between two humans, or a CRM field that’s been mislabelled for two years. Fixing that gets you 80% of the result. We’ll say so — and we’ll often ship it under Process Automation rather than dress it up as an AI workflow.

What “shipping” actually means in our shop

The word “ship” gets diluted fast. In our practice it means: the system runs in production, reads or writes real client data, is monitored, has a rollback path, and is being used by an actual human or process on the client’s side within a defined window — never more than three weeks from kickoff.

It does not mean: deployed to a staging environment that nobody logs into. It does not mean: a demo recorded in Loom. It does not mean: a CI/CD pipeline that builds an empty React app and prints “Hello world.”

We started insisting on this definition after a project where we considered the work shipped — code in main branch, deploys green, dashboard accessible — but the client team had never actually opened the dashboard. Six weeks later they asked us “where do we see the leads?” The system was technically running but operationally invisible. Now part of shipping is a 15-minute Loom from a member of the client team using the system end-to-end. If that recording doesn’t exist, the work isn’t done.

A note on AI strategy decks that do work

To be fair: there’s a kind of deck that works. It’s not the one that ends with a Gartner Magic Quadrant or a vendor scoring matrix. It’s the one a strong internal CTO or VP Engineering builds in a weekend, twelve to fifteen slides, no consultant involved. That deck identifies three to five operational pain points, lists the tools they’d test, names the people who’d own each, and sets a deadline measured in weeks. It’s a planning artifact, not a deliverable. It costs nothing because the person writing it is also the person who’ll execute.

We’re not against thinking before building. We’re against six-month “thinking” that produces nothing buildable. The difference is whether the document is a tool for the operator or a deliverable for the consultant.

Where to go from here

If you have an automation idea that’s been sitting in a Notion page for six months — or a pipeline that’s leaking leads and you can’t tell where — book an audit week. We’ll either find the leverage and ship the first system, or we’ll write you a roadmap honest enough to use elsewhere.

Book a call →