Most AI strategy documents open with a vision statement and a list of tools. Here's the order that actually works: decisions first, constraints second, and tools right near the end.
A real AI strategy is an ordered set of decisions about the business, not a technology pitch. Start with the 2-3 decisions the business has to make this year, then the constraints (data, budget, regulatory, skills) that already rule some options out, then what changes about the work, who owns each part, and how you’ll know it worked. Tools go last, once everything before them has already narrowed the field. This piece works through all six parts using one filled-in example, a 340-person company called Corvale, so you have a shape to copy rather than a blank outline.
A VP of Operations gets a message on a Tuesday afternoon: the board wants to see “the AI strategy” at next month’s meeting, and there isn’t one yet, just a folder of vendor demos and a Slack channel where people post ChatGPT screenshots. She isn’t being asked to run a pilot. She’s being asked to produce a document, in three weeks, that doesn’t exist yet, and nobody has told her what’s actually supposed to go in it. If that sounds like your inbox this quarter, you’re not alone. It’s worth saying up front that this is a composite situation built to show the shape of the problem, not a specific company, because the shape of it repeats everywhere.
Faced with a blank page and a deadline, most people reach for the same four ingredients. A vision statement about becoming an “AI-powered organization.” A list of tools somebody demoed at a conference. A headcount request for “an AI engineer or two.” And a document that, six months later, nobody can point to a single decision it actually changed.
None of that is unusual, which is exactly the problem. Grant Thornton’s 2026 AI Impact Survey of 950 senior business leaders across ten industries found that just 22% of operations leaders are working with a fully developed, implemented AI strategy.[1] The other 78% have something with that title on the cover and a lot less underneath it. A separate piece we’ve written, on why most AI strategies are just for show, goes deep on why that gap exists and what it costs a business that leaves it unaddressed. This one is about the fix: what actually belongs in the document, and the order to decide it in, so you’re not staring at that same blank page.
| What’s on the page | What it actually says | The fixed version |
|---|---|---|
| A vision statement (“AI will transform how we work”) | Nothing anyone can act on Monday morning | A named business decision the document exists to support: “cut proposal turnaround from 9 days to 3” |
| A tool list nobody has costed | Someone sat through some demos | Tools appear last, each tied to a named budget line and a named owner |
| A headcount claim with no basis (“we’ll need two AI engineers”) | A guess dressed up as a plan | The skills gap stated as a constraint, with a build-or-buy decision attached to it |
| No named owner anywhere in the document | Everyone’s responsible, which means no one is | Every section carries one person’s name, not a department |
The four tells of a performative AI strategy, and what replaces each one. Filled in with the worked example that runs through the rest of this piece.
Fixing all four comes down to one change: writing the document in a different order than most people start it in.
Start with the decisions, not the technology. Before anyone opens a laptop to compare tools, the document should name the two or three business decisions the company actually has to make this year, the kind that would still need making even if AI weren’t an option. That’s the test: if a “decision” would disappear from the list the moment AI wasn’t on the table, it isn’t a real business decision. It’s a capability looking for a use case.
Here’s a worked example, not a real client, built to show the shape rather than to report on one. Say you’re at Corvale, a 340-person B2B software company that sells route-planning software to mid-market logistics operators and pulls in around $58 million a year. Corvale’s leadership isn’t short of things to worry about, but three of them rise to the level of “the board will ask about this” this year: proposal turnaround is too slow, the support backlog won’t clear, and there’s a live question about whether to build or buy a chatbot for first-line support.
Notice what’s not on that list: nothing about “adopting AI” as an end in itself. Each item is a decision the business would have on its plate regardless of which technology might help with it. That’s deliberate. Naming AI as the goal is the vision-statement trap from the last section, restated with a different noun.
| Decision | Why it’s on the list this year | Whose decision it is |
|---|---|---|
| Cut proposal turnaround from 9 days to 3 | Lost two competitive deals this year on speed | Head of Sales Engineering, with the CEO signing off on the target |
| Clear the support backlog (400+ tickets, two quarters running) | Renewal risk flagged by the account team on three accounts | VP of Customer Support |
| Build or buy a tier-1 support chatbot | A headcount request for two more support reps is due at the next board meeting | CEO decides build-vs-buy; VP of Support owns the workflow once it’s decided |
The starting point of Corvale’s AI strategy: three business decisions, none of which mention AI by name.
Notice, too, that the CEO’s job here is to decide which three things matter enough to be on this list at all, not to write the paragraph about how the chatbot gets built. That’s a functional lead’s job, and it’s a different kind of decision entirely. Keeping those two roles straight matters more later, once the document gets to who owns what.
With the decisions named, the next section is constraints, not capabilities, and this is the part most people skip past because it feels like the boring administrative bit before the interesting technology conversation starts. It isn’t administrative. It’s the section that actually shortens the document, because a real constraint eliminates options before anyone spends a week evaluating them.
You don’t know what AI can do for the business until you know what the business can’t do.
Back at Corvale, four constraints turn out to matter more than any tool comparison would. Data: the standard contract with its two largest logistics customers bars sending shipment data to a third-party AI vendor without a security review, and adding a new subprocessor requires 30 days’ written notice. Budget: there’s $180,000 earmarked for AI-related spend this year, company-wide, not per department, which rules out anything that looks like a six-figure platform purchase on its own. Regulatory: two of those large customers are pharmaceutical distributors, so anything touching their data has to stay on infrastructure hosted in the US. Skills: there isn’t an ML engineer on staff, just one self-taught data analyst who also runs the BI dashboards, which rules out building anything in-house.
| Constraint | What it actually rules out | How it shapes the decisions above |
|---|---|---|
| Data (contract terms) | Any vendor that can’t be added as a subprocessor with 30 days’ notice and a security review | Proposal and support tools both get filtered down before a demo is ever booked |
| Budget ($180k, company-wide) | Six-figure platform deals; anything that isn’t a per-seat or per-workflow tool | Forces the proposal and support decisions to compete for the same pool |
| Regulatory (US data residency for two accounts) | Any vendor without a US-hosted option | Narrows the chatbot build-or-buy decision before cost is even discussed |
| Skills (no ML engineer on staff) | Building anything in-house | Turns the chatbot question into buy, not build, before anyone debates it |
Four constraints, applied before capability. Each one removes real options, which is what makes this section worth writing at all.
Skip this step and the cost shows up later instead of earlier. A sales engineering lead at a similarly sized company, another composite rather than a specific client, signed a proposal-drafting tool up for a free trial, got the team using it within a week, and only found out a month in that legal wouldn’t approve it: the vendor’s data-retention terms didn’t meet the same 30-day subprocessor clause Corvale has in its own contracts. The tool worked fine. The constraint killed it after the fact instead of before it, and that gap is most of why pilots stall before they scale.
The skills constraint deserves the same honesty. If nobody on the team can evaluate what a vendor is actually claiming, that’s a real gap, and building that literacy is worth doing regardless of which tool eventually gets picked. And if a constraint turns out to really be a governance question, who approves a new AI vendor, what the acceptable-use rules are, that’s a different document; our piece on the governance gap covers that ground properly rather than repeating it here.
Put the last two sections together and a pattern shows up: decisions first, then constraints, and only after that does anything resembling a capability conversation start to make sense. Here’s the full order, the one worth actually using.
The order this piece argues for. Everything before part 6 is what makes the tools section short and easy to write.
Tools are the last decision in an AI strategy, not the first.
Here’s what that looks like filled in, using Corvale’s three decisions all the way through to the tools section, so the shape is something you can actually copy rather than an outline with blanks in it.
| Part | What it contains | Corvale’s version |
|---|---|---|
| 1. Business decisions | The 2-3 things the business must decide this year | Cut proposal turnaround to 3 days; clear the support backlog; decide build-vs-buy on the chatbot |
| 2. Constraints | Data, budget, regulatory, skills | 30-day subprocessor clause; $180k total budget; US hosting for two accounts; no ML engineer on staff |
| 3. What changes about the work | The actual day-to-day difference | Sales engineers draft first-pass proposals inside the CRM instead of a blank doc; support agents triage tickets from an AI-generated first pass instead of reading each one cold |
| 4. Who owns what | One name per decision | Head of Sales Engineering owns the proposal workflow; VP of Support owns the ticket workflow; CEO owns the chatbot build-vs-buy call and reviews all three monthly |
| 5. How you’ll know | Use, persistence, impact | Use: reps opening the drafting tool on real proposals weekly. Persistence: still opening it unprompted at week 8. Impact: median turnaround actually down against the pre-tool baseline, checked by the Ops/Data lead |
| 6. Tools | Named, costed, owned, last | CRM-integrated drafting assistant, $38k/yr, US-hosted, owned by Sales Eng; ticket-triage tool, $22k/yr, owned by Support; in-house build rejected outright given the skills constraint |
The same six-part order, filled in with Corvale’s actual answers. Copy the shape and replace the middle column with your own.
A decision with no name next to it is a hope, not a strategy.
Three different jobs are doing three different things in that table, and it’s worth being explicit about which is which, because “leadership” isn’t a role, it’s several people with different accountability. The CEO’s job is parts 1 and 4 at the top level: deciding which business decisions make the list, and who’s accountable for each. A functional lead, the Head of Sales Engineering or the VP of Support here, owns parts 3 and 6 for their own workflow: what actually changes day to day, and which tool gets picked once the constraints have already narrowed the field. Whoever owns “how you’ll know,” often someone in ops or data rather than either of the above, owns part 5 alone, and that separation matters. The person measuring whether something worked shouldn’t be the same person who championed buying it.
Once this structure is filled in and signed off, the actual rollout, sequencing training, deciding who gets access first, what the first month looks like, is a different document. Our adoption checklist covers that part in detail; this one stops at the decision, not the execution.
By the time you reach the tools section, most of the actual thinking is already done, which is the whole point of the order. Evaluating a vendor against a constraint you already named, does this meet the 30-day subprocessor clause, is it hosted in the US, does it fit inside $180k, is a fast, almost mechanical check. Evaluating a vendor with no constraints named yet turns into a multi-week bake-off, because every feature looks equally plausible when nothing has ruled anything out yet.
For each of Corvale’s three decisions, the tools section ends up short: one or two live options that already clear every constraint, a cost, and a name. That’s a page, not a slide deck, and it reads that way because five other sections already did the hard part.
There’s a separate question worth answering honestly, because it comes up in almost every version of this exercise: can AI help write the strategy document itself? Yes, and it’s a reasonable use of the tool. It still isn’t the same thing as deciding what belongs in it.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts a first-pass summary of the decisions raised across several planning meetings | Deciding which two or three decisions actually make the final list | Reviewed by whoever owns the document (the CEO, in Corvale’s case) before anyone else sees a draft |
| Pulls the relevant clauses out of vendor and customer contracts to check a stated constraint | Deciding whether a given tool actually clears that constraint | Confirmed independently by whoever owns legal or procurement review, not assumed from the summary alone |
| Keeps the tools section formatted and current as vendors and pricing change | Deciding whether a tool still earns its place next quarter | Checked at the same review where “how you’ll know” gets checked, not left to update itself |
Where AI genuinely helps with the document itself, and where the decision stays with a named person.
Once a tool is actually running, working out whether it’s earning its budget line is a deeper question than this piece has room for. Our guide to measuring AI ROI covers that mechanics properly. What belongs here is narrower: does the tool clear the constraints already named, and does it have a name attached to who’s accountable for it.
Everything above is the order to write it in. This last part is how to check what you’ve already got, whether that’s a draft sitting in a shared doc right now or something that went to the board two quarters ago and hasn’t been touched since.
Run your own draft against these five. A document that survives all five is a strategy. One that only survives the first is a slide deck with a good title.
None of this is a document you write once and file away, and business strategy generally is already moving in that direction. A survey of 500 senior UK business leaders, conducted by Censuswide for the Association for Project Management, found that 49% now update their overall strategy every quarter or faster, naming AI, alongside general instability, as one of the two biggest reasons why.[2] An AI strategy specifically should move at least that fast on the parts that actually change: the decisions list and the tools section. The constraints and the ownership structure tend to hold longer, unless the business itself changes shape.
Pick the one decision on your own list that matters most this quarter. Write down the constraint that already rules out the most obvious tool for it. Put one person’s name next to it. That’s the first three rows of a real AI strategy, and there’s no reason they can’t be done before your next meeting, tools included or not.
Three things before anything about technology: the two or three business decisions the company actually has to make this year, the constraints that already rule some options out (data, budget, regulatory, skills), and a named owner for each part. Tools come last, after those three are settled, not first.
Short enough that someone new to the company could read the whole thing in one sitting, usually two to four pages once the tools section is genuinely short. If it’s running past ten pages, check whether the extra length is coming from real decisions or from restating the vision statement in different words.
Whoever owns the business decisions the document is meant to support, typically a CEO or a senior operator, not IT or a vendor. Functional leads contribute the sections about their own workflows, and whoever owns measurement contributes the “how you’ll know” section, but one person should own the final document so there’s someone to ask when a section stops making sense.
The strategy decides what belongs in scope and why: which business decisions matter, what’s off the table, who’s accountable. The adoption plan is what happens after that’s settled: training sequence, rollout order, who gets access first. Writing them as one document is usually where strategies turn into slide decks, because the rollout details crowd out the decisions.
The decisions list and the tools section should be checked quarterly, since both change fastest. The constraints and ownership structure usually hold longer, worth a full review annually or whenever the business itself changes shape, a new regulator, a new market, a shift in budget. A document that hasn’t been touched in over a year is a strong sign it stopped being a strategy the moment it was filed away.
The ordered structure, the performative-vs-real table and the Corvale worked example are Future Factors’ own synthesis, built from advising leadership teams on how to structure AI decisions, and presented as a practical framework rather than a research finding. Corvale is a composite used to show the shape of a real strategy document, not an actual client. Both statistics cited were checked directly against their primary source on 4 September 2026: the Grant Thornton figure against the publisher’s own 2026 AI Impact Survey report page, and the APM figure against the original Business Wire release of the Censuswide-conducted survey.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.