AI Workflow Planning: A Practical Consulting Framework

Most AI workflow planning engagements produce a slide deck, a heatmap of "opportunities", and a vague roadmap that nobody executes. Six months later the client has spent £40k, shipped nothing, and hired a second consultancy to redo the work. The pattern is so common that BCG's 2024 research found roughly 74% of companies struggle to achieve and scale value from AI, with only a fraction moving beyond pilots.

This article is a practitioner's account of how AI workflow planning consulting should actually work: what a good engagement looks like, how to scope it, how to price it, how to sequence the resulting build, and the specific traps that kill most projects. It assumes you are on the buying side - a COO, CTO, or head of operations trying to work out whether to hire a consultancy, an internal team, or both.

What AI workflow planning consulting actually is

Strip away the marketing and there are three distinct services that get sold under the same label:

• Opportunity mapping. A consultant interviews stakeholders, audits existing tooling, and produces a prioritised list of processes that could be automated or augmented with AI. Output: a document.
• Technical architecture. A consultant designs the specific systems - workflow engine, data flow, model selection, integration points, security posture. Output: a specification detailed enough to build from.
• Delivery planning. A consultant sequences the build, resources it, sets acceptance criteria, and defines the operating model for who runs the system once it ships. Output: a plan with dates, costs, and named owners.

Most consultancies sell the first one and pretend it covers all three. It does not. An opportunity map without technical architecture will recommend things that cannot be built for the price quoted. Technical architecture without a delivery plan produces shelfware. A delivery plan without opportunity mapping automates the wrong things beautifully.

Good AI workflow planning covers all three, in that order, in a single engagement. If a proposal only offers the first, treat it as discovery rather than planning and negotiate accordingly.

Scoping the engagement: the two-week rule

The single most useful heuristic for AI workflow planning is that the planning phase itself should take no more than two to four weeks of elapsed time. Longer engagements do not produce better plans - they produce more expensive plans, with more stakeholders consulted, more slides, and more time for the operational context to shift underneath the analysis.

A tight two-week planning engagement for a mid-market business typically involves:

• Week one, days one to three: stakeholder interviews. Six to twelve people, 45 minutes each, structured around "what work do you do that feels repetitive, error-prone, or that you cannot get to?" Not "where should we use AI?" - that question produces useless answers.
• Week one, days four to five: tooling and data audit. What systems hold the data, what integrations exist, what governs access, what the current automation stack looks like.
• Week two, days one to three: shortlist and sizing. Ten to twenty candidate workflows, scored on value, feasibility, and dependency. Rough architecture for the top three to five.
• Week two, days four to five: synthesis and readout. A written document (not slides) with prioritised roadmap, costed build sequence, and a recommended first project.

Expect to pay £15k-£30k for this in the UK mid-market. Anyone quoting significantly more is either padding, or bundling in a build that has not been specified yet.

Prioritisation: the framework that actually works

Every consultant has a 2x2. Most of them are useless because they score impact and effort on unbounded scales that translate to "gut feel". A better approach uses four concrete dimensions, each with a defensible number attached.

1. Annual cash impact

For each candidate workflow, calculate the annual cost of doing it the current way. Time spent x fully-loaded hourly cost x frequency per year, plus error costs, plus opportunity cost of the team not doing higher-value work. If a workflow does not have a defensible annual number over £25k, it does not belong on the roadmap. Small automations bundle into a separate operational efficiency track - they do not need consulting-led planning.

2. Build cost (honest)

The honest cost includes discovery, build, integration, testing, change management, and the first six months of operation. For most automation projects this lands between £15k and £80k. RAG assistants with a defensible evaluation harness land between £40k and £150k. Multi-agent systems that actually work in production start at £100k and go up quickly. If the ratio of annual impact to build cost is below 1.5:1 in year one, defer the project.

3. Feasibility risk

Score each candidate honestly on: data availability (does the data exist in a queryable form?), integration complexity (how many systems must it touch?), and accuracy tolerance (does the business process tolerate a 5% error rate, or does it need 99.5%?). Anything requiring high accuracy on structured outputs from unstructured inputs is a research project, not a build. Treat it as such or drop it.

4. Change dependency

Some automations require the humans downstream to change how they work. Others slot in behind the scenes and require nothing. All else being equal, prefer the second kind for your first project - not forever, but for the first. You need a win, and change-heavy projects are where wins go to die.

Score each candidate on these four dimensions, then sort by ratio of impact to (cost + feasibility risk + change friction). The top three become the roadmap. Everything else is a backlog.

The document that comes out

A useful planning output is a written document of roughly 20-40 pages, not a slide deck. Slide decks compress badly and cannot carry the technical detail needed to build from. The document should contain:

• Executive summary. One page. Three prioritised projects, expected annual impact, expected build cost, recommended sequence, first project start date.
• Current state. Systems inventory, data flow diagram, integration map, current automation stack.
• Opportunity longlist. Every candidate identified, scored on the four dimensions, with brief rationale.
• Shortlist detail. For each of the top three to five candidates: workflow diagram of the current process, workflow diagram of the target process, systems involved, data required, model or automation approach, acceptance criteria, rough build breakdown.
• Roadmap. Twelve-month view with quarterly milestones. Honest about dependencies.
• Operating model. Who runs each system after go-live. This is the section most consultancies skip.
• Risks and assumptions. Explicit, not buried.

If the deliverable is 60 slides with icons, ask for your money back.

Build sequencing: getting the first project right

The first project after planning is the one that decides whether the rest of the roadmap happens. Get it wrong and you spend the next twelve months rebuilding trust rather than building systems. Three rules for the first project:

Ship in eight to twelve weeks. Not six months. If the first project cannot ship inside a quarter, it is not the first project. Split it, or pick a different one. The Gartner prediction that 30% of generative AI projects will be abandoned after proof of concept by end of 2025 is largely driven by projects that overran their initial mandate.

Instrument for measurement from day one. Whatever the workflow does, log the inputs, outputs, latency, cost per run, and accuracy against a held-out evaluation set. Not later - from the first commit. Retrofitting instrumentation is expensive and always incomplete.

Design for the operator, not the demo. The person who will run this system after go-live needs a way to see what it did, intervene when it goes wrong, and roll back when needed. If the only interface is a Slack channel and a hopeful team, the system will drift and eventually be turned off.

Where planning engagements go wrong

Five failure modes account for most of the value destruction in AI workflow planning:

The "AI strategy" that is really a slide deck. No architecture, no costed build, no acceptance criteria. Reads well, builds nothing.

The everything-map. Twenty-seven candidate projects, all scored 4/5 on value and 3/5 on effort. Useless. A plan that recommends everything recommends nothing.

The tool-first plan. "We recommend implementing Microsoft Copilot across the organisation" is not a plan - it is a licence renewal disguised as strategy. Tools follow workflows, not the other way round.

Ignoring the operating model. Who fixes it at 2am? Who retrains the model when performance drifts? Who owns the evaluation set? Plans that do not answer these questions produce systems that quietly rot.

Underestimating GDPR and data governance. Any workflow touching personal data needs a lawful basis, a DPIA where required, and clear retention rules. The ICO's guidance on AI and data protection is unambiguous on this. Plans that treat compliance as a footnote hit an expensive wall in month three.

In-house vs consultancy: the honest comparison

The right answer is usually both, sequenced. Consultancies are good at planning and at getting the first two or three projects into production. Internal teams are good at running systems over years and building institutional knowledge. The failure modes are inverse: consultancies build things nobody can maintain, and internal teams plan things nobody can ship because they lack cross-industry pattern recognition.

A defensible pattern for mid-market businesses: hire a consultancy for planning and the first build cycle (roughly six to nine months). During that period, hire or promote an internal automation lead who works alongside the consultancy. At month nine, transition to the internal lead owning the roadmap with the consultancy on retainer for architecture reviews and the harder build work. By month eighteen, the internal team owns everything the consultancy shipped, and the consultancy is only involved on new capability areas.

This costs more in year one than pure in-house, and less in year three. It also produces working systems in year one, which pure in-house rarely does.

What good looks like: a worked example

A £30m-revenue professional services firm engages an AI workflow planning consultancy. Two-week planning phase, £22k fixed fee. Output is a 34-page document identifying three priority projects:

1. Client intake automation. Currently 45 minutes of paralegal time per new matter, running at 1,200 matters a year. Target state: 8 minutes with structured extraction from client-supplied documents. Estimated annual saving: £68k. Build cost: £42k. Ships in 10 weeks.
2. Knowledge assistant for fee-earners. RAG over the firm's precedent library and past matter files. Not measured in time saved but in matter quality and junior fee-earner ramp time. Build cost: £95k. Ships in 16 weeks.
3. Billing narrative generation. Automated first-draft billing narratives from time entries and matter context. Annual value: £140k in recovered write-offs. Build cost: £55k. Ships in 12 weeks.

The consultancy builds project one first (fastest payback, lowest risk, proves the model). Project three follows because it funds projects two onwards from its own savings. Project two ships last because it is the highest-risk build and benefits from the operating patterns established by the first two.

Eighteen months in, the firm has three production systems, an internal automation lead running them, and a backlog of eight further projects prioritised on the same framework. Total consultancy spend: roughly £280k. Total annualised value: over £400k. That is what good AI workflow planning consulting produces.

FAQs

How much should AI workflow planning consulting cost?

For a genuine two-to-four-week planning engagement in the UK mid-market, expect £15k-£40k as a fixed fee. Anything under £10k is usually a sales exercise disguised as planning - the consultancy is losing money on the engagement to sell you the build. Anything over £60k for planning alone is padding, unless it explicitly includes technical proof-of-concept work. The economics change for enterprises above £500m revenue, where planning engagements legitimately cost £75k-£200k because of stakeholder complexity, but that is not the mid-market picture.

How long before we see results from AI workflow planning?

Planning itself takes two to four weeks. The first build resulting from the plan should ship in eight to twelve weeks after that. So from engagement start to first production system: roughly three to four months. Measurable business impact typically follows within another one to two months of operation, once the system has processed enough volume to produce reliable metrics. If a consultancy is telling you the first results will come in month nine or later, either the scope is too big or the sequencing is wrong.

Do we need our data to be "AI-ready" before we start?

Mostly no, and this concern is often used as an excuse to defer projects indefinitely. Good planning identifies workflows where the data is already good enough, and separates them from workflows that need data remediation first. Roughly 60-70% of automation opportunities in a typical mid-market business can be built on existing data with minor cleanup. The remaining 30-40% do need data work, but that work should be scoped and costed within the plan rather than treated as a blocking prerequisite. A consultancy that says "we need to fix your data first" for six months is selling data engineering, not AI planning.

How does GDPR affect AI workflow planning in the UK?

Materially, but not fatally. Every workflow touching personal data needs a lawful basis under UK GDPR, and any workflow using automated decision-making with legal or similarly significant effects triggers Article 22 protections. The ICO's guidance on AI and data protection is the authoritative source and should be referenced during planning. In practice, this means most customer-facing AI systems need a DPIA, clear retention and deletion patterns, and the ability to explain decisions. Well-designed planning bakes this in from the start rather than treating it as compliance overhead added at the end.

Should we use a general management consultancy or a specialist AI firm?

Should we use a general management consultancy or a specialist AI firm?

For AI workflow planning specifically, use a specialist that builds as well as plans. General management consultancies produce excellent strategy documents but rarely have the technical depth to specify systems that can actually be built for the price quoted. The gap between "we recommend an AI-powered intake solution" and "here is the n8n workflow, the extraction prompts, the evaluation harness, and the £42k build cost" is the gap between advice and a plan. If the consultancy cannot show you production systems they have built for clients of similar size, they are advising, not planning.

What happens if the priorities change mid-roadmap?

They will, and a good plan expects this. The roadmap should be re-scored quarterly against the same four dimensions used in initial prioritisation. About 30-40% of items typically shift position over a twelve-month period as business conditions change, new data becomes available, or the first builds surface unexpected patterns. What should not change quarter to quarter is the framework itself - if you find the consultancy re-inventing the scoring model every review, that is a sign the original model was not defensible.

How do we avoid becoming dependent on the consultancy?

Insist on three things in the contract. First, all code, prompts, evaluation sets, and documentation are owned by you and delivered in a repository you control, not the consultancy's. Second, the consultancy trains and works alongside a named internal owner from day one - not "knowledge transfer at the end", which never happens properly. Third, the operating model in the plan specifies internal ownership within twelve to eighteen months, with the consultancy's role reducing to defined advisory work. A consultancy that resists these terms is planning for lock-in rather than for your success.

What if we have already tried AI projects and they failed?

This is the norm, not the exception. Most mid-market businesses have at least one abandoned pilot on the shelf. Failed prior projects are actually useful input to planning - they reveal which failure mode your organisation is prone to (over-scoping, under-instrumenting, wrong tool choice, no operating model). A good planning engagement includes a short post-mortem on prior attempts before generating new candidates. Do not hide the failures from the consultancy; they are the most valuable diagnostic information available.

Where to go from here

The difference between AI workflow planning that produces working systems and planning that produces slide decks is whether the plan can be built from. Insist on written documents rather than decks, technical architecture rather than opportunity heatmaps, costed builds rather than "phase two" placeholders, and an operating model that answers who runs the system after go-live. Score candidates on annual cash impact, honest build cost, feasibility risk, and change dependency - not on unbounded 2x2s. Ship the first project in eight to twelve weeks or split it.

If you want to talk through your own AI workflow roadmap with a team that plans and builds under the same roof, AI Advisory offers two-week fixed-fee planning engagements for UK mid-market businesses. Get in touch to scope one.

Ready to put this into production? book a discovery call.