Strategy
What should an AI strategy phase actually give you?
Clearmatic · 1 October 2026
What a strategy phase should leave you with: the processes mapped, the one to build first, the measure agreed, and the design for where a person decides.
The short answer
A strategy phase should leave you with a map of where the hours go, one process chosen to build first with the reasons written down, the measure you'll hold it to with today's reading, and a design for where a person decides. If it ends in a deck about possibilities, you don't have a plan yet.
Key takeaways
- Four deliverables: the map, the choice with reasons, the measure with today's reading, and the exception design.
- The map comes from the people doing the work, not the org chart or a list of tools.
- A good roadmap names the second and third process too, so there's a next.
- It should also say what can't be connected and what doesn't need AI at all.
- Savings figures nobody measured and tool recommendations before the process is understood are warning signs.
You've been offered an AI audit, a discovery phase or a strategy sprint. The names differ and the price is rarely small. Before you agree to one, it helps to know what should be in your hands at the end, so you can tell a plan you can build from apart from a well designed sales document.
The four deliverables below are the test, and the questions at the end tell you which you're being sold.
A map of where the hours go
The first deliverable is a plain record of how work happens today: which processes exist across sales, operations and customer service, who does them, how often they run, what arrives to start them and which systems they touch. It is built by sitting with the people who do the work, not from the org chart and not from a list of software you own.
A useful map is specific. Not "invoicing", but supplier invoices arriving in the shared inbox, matched by the finance assistant against purchase orders in the accounting system, with the exceptions emailed to the operations lead. That level of detail is what makes the next three deliverables possible.
Suppose the sales lead at a distributor says quoting takes too long and the answer is to automate quotes. Then the person who actually prepares them walks through yesterday's. The enquiry came in by email at ten. She looked up the customer in the CRM, found two records and picked one. She checked stock in the warehouse system, then pricing in a spreadsheet the owner updates, then the customer's agreed discount in an old email thread. She typed the quote into the accounting system and sent it at four. Six hours, of which perhaps twenty minutes was deciding anything.
The map records all of that: four systems, one spreadsheet, one email thread, and the moment where judgment was used. It also records that the discount lives in nobody's system, which is the real reason quoting is slow and the thing to fix before any quote is drafted by a system. That finding is worth more than the recommendation to automate quotes, and it only comes from sitting with the person who does the work.
One process chosen, and the reasons written down
From the map, one process is chosen to build first, and the reasons are on the page: how often it runs, how much judgment it needs, where its inputs come from and whether a measure exists. The four questions in What should you automate first? are one way to make that case; whichever way is used, you should be able to read the reasoning and disagree with it.
The second and third processes are named too, with less detail. That turns a single project into a roadmap, and it tells you what the first system is a foundation for.
The measure, with today's reading
The third deliverable is the number the first system will be held to, and its value today. Time from enquiry to first reply. Hours spent on invoice matching each week. Requests resolved without an escalation. Whatever it is, the strategy phase should take the reading before anything is built, from your inbox, your systems or a week of the team's time, so that after launch the comparison is honest. How do you measure whether AI automation paid for itself? goes into how to choose and take it.
The design for where a person decides
The fourth is the part that makes the system safe: which steps a person keeps, what they see when a decision reaches them, what the system may do on its own from day one, and how that widens. It should be concrete enough that your finance lead or operations lead can read it and say yes, that's how I'd want it. How do you keep a person in charge of an automated process? describes what good looks like.
What the systems can and can't do
Somewhere in the deliverables there should be a plain statement of what was checked about your tools: which can be connected and how, which can't, and what that means for the design. If your accounting system has no way to read invoices out of it, you want to know before the build, not during it. The same statement should say where ordinary automation or a simpler process change would do the job without AI, and recommend that instead.
Take the distributor above. Say the warehouse system turns out to have no way for anything outside it to read stock levels, so a quote drafted by a system would have had to guess at availability. An honest roadmap says so, and proposes starting with the step before the quote instead: the enquiry captured, the customer matched to one record, and the agreed discount moved into the CRM where a system can see it. Quoting comes second, once the warehouse vendor confirms a connection. That is a less exciting plan than automating quotes, and it is the one that works.
What it should not contain
- Savings figures nobody measured. A projected annual saving with no reading of today's cost is a guess with a currency sign on it.
- A list of forty workflows. Breadth is easy to produce and impossible to act on. One chosen process with reasons is worth more than forty named ones.
- A tool recommendation before the process is understood. If the platform was decided before the map was drawn, the map was drawn to fit the platform.
- A design that removes every person. The processes that last keep the decisions with people and remove the work around them.
Questions to ask before you agree to one
Four questions sort the strategy phases worth paying for from the rest.
- Who will you talk to, and how much of their time do you need? The answer should name the people who do the work.
- What will I be able to read at the end? The answer should be the four deliverables above, or something close.
- What happens if you conclude AI isn't the right answer for us? You want to hear that they'll say so, and what they'd recommend instead.
- Can I take the roadmap and build it with someone else? If the answer is no, you're buying lock-in.
What to do this week
- Write down the three processes you suspect cost the most time, in one line each, before anyone else maps them for you.
- Note which systems each one touches and whether you know how they connect.
- Decide who on your team would need to be in the room for a map to be accurate.
- Put the four questions above to whoever you're talking to.
If you'd like to put them to us, a first call is where we'd answer them, and where we'd tell you whether a strategy phase makes sense for your business or whether something simpler would do.
Questions
Is a strategy phase the same as an AI audit?
They overlap. An audit usually stops at the map and a list of opportunities. A strategy phase goes on to choose one process, agree the measure and design where a person decides, so it ends in something that can be built. If the audit you're offered ends in a list, ask what comes next.
Can we do this ourselves?
Much of it, yes. The map and the measure are things your team knows better than anyone. Where outside help earns its place is in judging what the systems can be made to do, designing the exception path, and having seen what went wrong elsewhere. If you do it yourselves, use the four deliverables as your checklist.
What if the strategy phase concludes that AI isn't the answer?
Then it has done its job. Some of the processes we map are better served by a form change, a rule in the existing system or a different way of working. A strategy phase that can't reach that conclusion isn't a strategy phase.
How do we know the roadmap is honest?
Look for the reasons. Every choice should have its reasoning on the page, in terms of your work: how often, how much judgment, where the inputs come from, what's measured. If you can argue with it, it's honest. If it can only be accepted, be careful.
More in this area
- How do you get your team to use an AI system?
Adoption is decided before launch. How to choose a first process your team is glad to hand over, keep their judgment visible, and make the new way the easy way.
- How do you keep a person in charge of an automated process?
How to design an automated process so a person still decides what matters: where they step in, what they see, and how the system earns the right to do more.
- Do you need to fix your data before you automate anything?
The data to fix before automating is the input to the one process you've chosen, not the whole business. How to tell the difference and what to fix first.