AI28 June 20265 min read

AI Workflow Planning: A Practitioner's Guide to Scoping, Sequencing and Shipping

How to plan AI workflow projects that actually ship: scoping, sequencing, build-vs-buy, governance, and what to expect from a consulting engagement

By AI Advisory team

Most AI workflow projects fail in planning, not in build. The technology works. The models are good enough. What kills delivery is a vague problem statement, the wrong sequencing of dependencies, and a roadmap that treats AI as a single capability rather than a portfolio of decisions about data, integration, governance and operations.

This guide covers how to plan AI workflow projects properly - what a consulting engagement should produce, how to scope opportunities, how to sequence them, and how to avoid the common traps that turn six-week pilots into two-year stalled programmes. It's aimed at operations and engineering leaders evaluating whether to bring in outside help, or trying to structure the work themselves.

What AI workflow planning actually is

AI workflow planning is the process of identifying which business processes benefit from AI or automation, in what order, with what tools, against what success criteria, and under what governance model. It sits between two things people more commonly buy: pure AI strategy (a slide deck about what AI could do for the business) and tactical automation work (build me this specific Zapier scenario).

The strategy deck without the planning layer produces aspiration with no buildable spec. The tactical work without the planning layer produces a shed full of disconnected automations that nobody owns and that quietly break. Planning is the connective tissue: it takes the strategic intent, breaks it into a sequenced backlog of specific workflows, and defines the technical, data and operational preconditions for each one.

A good plan answers five questions for every candidate workflow:

What is the current process, measured in hours, errors, or revenue impact?
What changes when AI or automation is applied, and how do we measure that change?
What systems, data, and permissions are required, and what's the gap to today's state?
What are the failure modes, and what controls keep them inside tolerable bounds?
Who owns the workflow after go-live, and how does it get changed when the business changes?

If a planning engagement doesn't produce defensible answers to those five questions for every workflow in scope, it hasn't done its job.

The shape of a consulting engagement

A credible AI workflow planning engagement typically runs two to six weeks depending on scope. Shorter than that and you're buying a templated audit; longer and you're paying for analysis paralysis. The deliverables should be concrete, not generic.

Week one: discovery

Structured interviews with 8-15 people across operations, engineering, finance and the executive sponsor. Read-only access to the relevant systems (CRM, ERP, ticketing, finance, data warehouse) so the consultant can see actual volumes rather than what people think the volumes are. A process map of the two or three most painful workflows, drawn from the data, not from a workshop.

The single most useful artefact from week one is a baseline measurement of the current state. How many support tickets per week? What's the median handle time? How many manual touches does an invoice get before payment? What percentage of leads get a response inside 24 hours? Without these numbers, no post-build claim of improvement is defensible.

Weeks two to three: opportunity mapping

From the baseline, you generate a long list of candidate workflows - usually 20-40 for a mid-market organisation. Each gets scored on impact (annual hours or revenue), effort (build complexity, integration cost, data readiness), and risk (regulatory exposure, customer-facing failure modes, model uncertainty).

This is where most engagements go wrong. They produce a 2x2 matrix that ranks everything as "high impact, low effort" because the consultants haven't actually estimated the build. A useful opportunity map has effort estimates anchored to specific tools and integrations, with named dependencies ("requires Salesforce custom object change," "depends on finance team approving a new GL code structure"). Vague effort scoring is worthless.

Weeks four to six: sequenced roadmap and architecture

The output is a 12-month roadmap with three layers:

The build backlog: ordered list of workflows with scoped specifications, effort in person-weeks, and go-live targets.
The platform layer: what gets built once and reused - the orchestration platform (n8n, Make, Temporal, custom), the retrieval layer for any RAG work, the observability stack, the secrets management, the human-in-the-loop interfaces.
The operating model: who runs this after go-live, how changes get requested and approved, how incidents get handled, how new workflows get added without re-doing the planning.

The platform layer is the part most easily missed. If you build six workflows on six different tools with six different ways of handling secrets and logging, you've created a maintenance liability that will eat the savings within two years.

Scoring opportunities: a practical framework

The matrix that survives contact with reality looks something like this. For each candidate workflow, capture:

Annual hours saved or recovered: measured, not estimated. Multiply by a defensible loaded cost per hour.
Revenue impact: if the workflow accelerates sales response, reduces churn, or unblocks revenue, quantify it. Be conservative - assume a fraction of the theoretical maximum lands.
Build effort in person-weeks: broken down by integration work, AI/model work, UI work, and testing. Include data preparation, which is usually 40-60% of the total on RAG and analytics projects.
Data readiness: is the data that this workflow needs already accessible, clean, and governed? If not, what's the prerequisite project?
Risk class: internal-only and reversible (low), customer-facing but reviewed by a human (medium), customer-facing and autonomous (high), regulated or financial (highest). Risk class drives the controls needed, not whether to build.
Dependency graph: what does this workflow require to exist first?

Once you have these for the long list, two patterns emerge. First, there's almost always a cluster of "obvious wins" - internal-facing, high-volume, low-risk workflows where the data already exists. These should be the first six months. Second, there's usually one or two strategic plays - typically customer-facing assistants or commercial automations - that need foundational work (clean data, integration platform, evaluation harness) before they can be built safely. These get scheduled around the foundation work, not before it.

Build, buy, or compose

The build-versus-buy question is now better framed as build-versus-buy-versus-compose. Most AI workflows are not built from scratch and not bought off the shelf; they're composed from a stack of platform components.

A representative composition for a mid-market workflow project:

Orchestration: n8n (self-hosted on a small VPS or Kubernetes), or Temporal for higher-volume durable workflows.
LLM access: OpenAI, Anthropic, or a self-hosted open-weight model via vLLM, depending on data sensitivity and cost profile.
Retrieval: Postgres with pgvector for most cases; a dedicated vector database only when scale or latency demands it.
Integration: native connectors in the orchestration layer where they exist; custom Python or TypeScript services for anything the connectors don't cover.
Observability: Langfuse or Helicone for LLM traces, plus whatever the rest of the engineering org uses for application logs.
Human interfaces: usually built into existing tools (Slack, Microsoft Teams, the CRM) rather than new web apps.

The planning phase should pick this stack once, document the choices, and reuse them. Letting each workflow pick its own tooling is the fastest way to build a mess.

Pure SaaS purchases still make sense for commodity capabilities - meeting transcription, email scheduling, basic sales engagement - where the vendor's product is better than anything you'd build and the lock-in cost is low. The planning engagement's job is to identify those clearly and exclude them from the build backlog rather than reflexively recommending custom work.

Governance, risk and the boring middle bit

The part of AI workflow planning that consulting decks usually skip is governance. It's also the part that determines whether the workflows survive contact with security, legal, and audit.

The UK regulatory context matters here. The ICO's guidance on AI and data protection sets clear expectations around lawful basis, data minimisation, and the right to human review of significant automated decisions. The UK government's pro-innovation approach to AI regulation places interpretation responsibilities on existing regulators (FCA, MHRA, Ofcom, ICO) rather than creating an EU AI Act equivalent, which means sector-specific requirements still apply.

For each workflow in the plan, define:

Lawful basis for processing any personal data, and a Data Protection Impact Assessment where the processing is high-risk or novel.
Human review thresholds: what types of decisions require human sign-off, and what the SLA is for that review.
Refusal patterns for any customer-facing AI - what the assistant will not do, and how it routes those requests.
Evaluation harness: a set of test cases that get run before every prompt or model change, with regression criteria.
Incident response: who gets paged when an automation produces bad output at scale, and how it gets rolled back.

These don't need to be heavy. A one-page governance summary per workflow is plenty for most internal automations. What kills projects is having no answer at all when the security team asks the question two weeks before go-live.

What it costs and how to budget

Realistic budget ranges for the mid-market - businesses between roughly 50 and 1,000 employees:

Planning engagement: £15k-£40k for a two-to-six-week structured engagement producing the roadmap, opportunity map, and architecture decisions.
First build wave: £30k-£120k for the initial three to six workflows, depending on integration complexity and whether any platform foundation work is needed.
Platform foundation (if not already in place): £20k-£60k for the orchestration platform, observability, secrets management, and shared retrieval infrastructure.
Ongoing operation: typically a retainer of £3k-£15k per month covering monitoring, prompt and model updates, small workflow changes, and capacity for new builds.

Industry benchmarks support these ranges. McKinsey's State of AI reporting consistently shows that organisations getting measurable EBIT impact from AI are the ones with dedicated capability and governance investment, not the ones running scattered pilots. BCG's research on AI productivity points to the same pattern: discipline in scoping and operationalising beats raw model capability.

The single biggest budgeting mistake is underfunding the operating phase. A workflow that goes live without an owner and a budget for change degrades within three to six months as the upstream systems shift. Plan for the operating cost from day one.

Signals you should bring in outside help

Internal teams can absolutely do this work. The question is whether the time cost of doing it internally beats the cost of bringing someone in. Bring in outside help when:

You don't have a clear view of which workflows to attack first, and the internal debate has been running for more than a quarter without resolution.
You have several pilots in flight, none of which have made it to production, and you can't articulate why.
The opportunity is broad but your team is small enough that taking three months out to do planning would stall the rest of the roadmap.
You need an external view because internal politics is preventing honest assessment of which processes are actually broken.
You're considering a major platform commitment (e.g. an enterprise AI platform, a workflow orchestration standard) and want a second opinion before signing.

Conversely, don't bring in outside help if you already know what you want built and the team has the bandwidth to build it. Pay for build work, not for someone to confirm what you already know.

FAQ

How long does an AI workflow planning engagement take?

Two to six weeks for most mid-market organisations. A two-week engagement is appropriate when the scope is narrow - a single function like customer support or finance operations - and the systems landscape is well understood. A six-week engagement is appropriate when the scope is enterprise-wide, multiple business units are involved, or there are significant data readiness questions to answer. Engagements longer than six weeks usually indicate the scope was wrong at the outset, or the consultant is padding the work. The deliverable should be a buildable roadmap, not a research paper.

What's the difference between AI strategy and AI workflow planning?

AI strategy answers what AI should do for the business at the level of competitive positioning, capability investment, and organisational design. AI workflow planning answers which specific processes get automated or augmented, in what order, with what tools, against what success metrics. Strategy is the right deliverable for a board conversation; workflow planning is the right deliverable for an engineering and operations team about to build. Many engagements badged as "AI strategy" stop at the slide deck. Workflow planning forces the questions about integration, data, governance and operations that determine whether anything gets shipped.

Can we do AI workflow planning ourselves without consultants?

Yes, if you have the right people and time. You need someone senior who understands the business processes in depth, someone who understands the technical landscape (integrations, data, existing tools), and someone who has done enough AI build work to estimate effort credibly. If those three roles exist internally and have a clear month to focus, an internal team will produce a better plan than any consultant - they know the politics and constraints. The reason to bring in outside help is usually capacity, not capability: the internal team has day jobs that don't pause.

How do we measure success of an AI workflow project?

Against the baseline you measured before building. Hours saved per week, error rate reduction, response time improvement, revenue per rep, cost per ticket - whichever metric the workflow was designed to move. The planning engagement should define these metrics upfront and instrument them in the build, so success isn't a subjective claim after go-live. Beyond the per-workflow metrics, track portfolio-level indicators: percentage of planned workflows actually shipped, time from planning to first production workflow, and the ratio of ongoing operating cost to annual benefit. Projects that don't track these tend to overstate their impact.

What happens if our data isn't ready for AI workflows?

Then data readiness is the first project, not the AI workflows. The planning engagement should identify this honestly rather than pretend AI can paper over the gap. For most mid-market organisations, data readiness means three things: the systems containing the relevant data are accessible via API or warehouse, the data is reasonably clean and consistently structured, and there's a governance owner for it. If any of those is missing, fix it before building workflows that depend on it. The cost of building on bad data is higher than the cost of cleaning it, and the workflow will fail in ways that erode trust in AI generally.

How do we avoid vendor lock-in when planning AI workflows?

Pick an orchestration layer you control. Self-hosted n8n, Temporal, or a custom orchestration service keeps the workflow logic portable. Treat LLM providers as interchangeable behind an abstraction - most workflow code should not care whether the model is OpenAI, Anthropic, or a self-hosted open-weight model. Keep prompts, evaluation cases and retrieval data in your own repositories, not in vendor-specific tooling. The places where lock-in is acceptable are commodity SaaS (CRM, helpdesk, email) where switching cost is industry-standard anyway. The places where lock-in is dangerous are orchestration, prompts, and proprietary fine-tunes.

Who runs the workflows after go-live?

Either an internal owner with explicit time allocated, a retainer with the agency that built them, or a hybrid. The worst answer is "the team that built it will look at it when something breaks," because that team has moved on to the next project and won't notice the slow degradation. A typical mid-market arrangement is an internal product owner (usually in operations or engineering ops) responsible for the workflow portfolio, with an agency retainer covering technical maintenance, model and prompt updates, and capacity for small changes. Larger organisations bring this fully in-house once the portfolio justifies a dedicated team.

What's the biggest risk in AI workflow planning?

Planning everything and shipping nothing. The single most common failure mode is an engagement that produces a beautiful 80-page roadmap, a 2x2 matrix, and an architecture diagram, and then stalls because no one has the appetite to start building. Mitigate this by insisting the planning engagement names the first three workflows to be built with full specifications, identifies who will build them (internal team, agency, or hybrid), and books the build start date before the planning engagement closes. If the plan doesn't have a build attached, it's a deck, not a plan.

Closing

AI workflow planning is unglamorous compared to model demos and architecture diagrams, but it's the layer that decides whether projects ship. Get the scoping, sequencing and governance right and the build phase is straightforward. Get it wrong and no amount of model capability will rescue the project. The work is the work: measure the baseline, score the opportunities honestly, pick the platform once, name the owner, and book the build date before the planning engagement closes.

If you'd like a structured second opinion on your AI workflow roadmap, or you want a planning engagement that produces a buildable backlog rather than a deck, AI Advisory runs two-to-six week planning engagements with the build team in the room from day one.