Automation Advisory: How to Buy It Without Wasting Six Months

Most automation advisory engagements produce a deck, a heatmap, and a roadmap. Six months later the roadmap is stale, the champion has moved teams, and nothing has been automated. This is not a rare failure mode. It is the default outcome when advisory is bought as a standalone product rather than as the front end of a build.

This guide covers what automation advisory should actually deliver, how to scope it, what to pay, how to tell a good advisor from a good slide-maker, and how to structure the engagement so the output survives contact with your operations team.

What automation advisory is (and what it usually isn't)

Automation advisory is the work of identifying which processes in a business should be automated, in what order, using what tools, with what expected return. Done well, it produces a prioritised, costed backlog that engineering or an external build partner can execute against within weeks.

Done badly, it produces a maturity assessment, a capability model, a target operating model diagram, and a 40-slide readout that nobody opens after the presentation. The distinction matters because the market is split roughly down the middle between firms that do the former and firms that do the latter, and they charge similar rates.

The tell is in the deliverables clause of the statement of work. If the deliverables list ends at "strategy document" and "roadmap", you are buying the second kind. If the deliverables include process specifications detailed enough for a developer to build from, tool selections with justification, and a pilot scoped to production, you are buying the first.

A useful test: ask the advisor what the first automation they'd build for you would look like, and whether they'd build it. If the answer is a vague "it depends" followed by a suggestion to run a discovery workshop, they are selling discovery. If they ask three sharp questions about your CRM, your ticket volume, and where your team spends time, they are diagnosing.

The five things a real advisory engagement should produce

Ignore the standard consulting deliverables list. The outputs that actually matter are these:

1. A process inventory ranked by automation ROI. Not "opportunities to explore". A ranked list of specific workflows - order-to-cash, employee onboarding, invoice matching, lead qualification - with estimated hours saved per month, estimated build cost, and estimated payback period. If the numbers are ranges rather than point estimates, that is fine, but they must be numbers.

2. Tool decisions with reasoning. For each prioritised workflow, a recommendation: n8n vs Zapier vs Make vs custom code vs an off-the-shelf SaaS. Advisors who refuse to name tools are hedging. The choice matters because it determines who can maintain the system, what it costs to run, and whether you are locked into a vendor's pricing model. Zapier's per-task pricing looks cheap at low volume and becomes expensive fast; self-hosted n8n has a higher setup cost and lower marginal cost. That trade-off should be spelled out in the advisory output, not left as a decision for later.

3. A build specification for the first two or three automations. Enough detail that a developer or a build agency can quote against it. Trigger conditions, data sources, systems to integrate, failure modes to handle, who receives errors. Without this, the roadmap is just a wish list.

4. A governance and operations plan. Who owns each automation once built. Who monitors it. What happens when a source system changes its API. What the escalation path is when an automation fails silently at 2am. Most automation programmes fail here rather than in the build.

5. A realistic capacity plan. How many automations your organisation can absorb per quarter given current change-management maturity. This is usually far lower than the advisor's initial estimate and far lower than the client's initial ambition. Naming the constraint early prevents the common outcome where 30 automations are specified, 4 are built, and the programme is declared a failure.

How to scope the engagement

The right shape for automation advisory is short, cheap, and tightly bounded. Two to four weeks. Fixed fee. Small team - typically one senior practitioner leading, one analyst supporting, occasional input from a technical specialist for the tool selection sections.

Anything longer than six weeks is a red flag. The reason is simple: the marginal value of week seven is almost always lower than the value of shipping the first automation and learning from it. Long advisory engagements are usually padded with stakeholder interviews that do not change the answer.

A workable structure:

• Week 1: operations discovery. Shadow three to five teams. Pull data from the systems that hold the workflow evidence - your ticketing system, CRM, finance tools, HR system. Interview the people who actually do the work, not just their managers.
• Week 2: opportunity sizing. Turn the discovery into a ranked list with rough numbers. Test the top five with the process owners for feasibility.
• Week 3: specification and tool selection. Write build-ready specs for the top two or three. Recommend the platform stack.
• Week 4: readout and handover. Present the backlog, the specs, the governance plan. Agree what gets built first and by whom.

If the advisor proposes six months of "phased discovery", walk away. If they propose a three-day sprint, be sceptical - three days is not enough to gather the evidence needed to size opportunities credibly.

What it should cost

UK market rates for a four-week automation advisory engagement from a competent build-capable firm run £20,000-£45,000. Big Four and tier-one strategy houses will quote £80,000-£250,000 for equivalent scope and will produce more polished decks. Independent senior practitioners will do it for £12,000-£25,000 but with less bench depth if the analysis needs to go wide.

The important number is not the advisory fee. It is the build fee that follows. A £30,000 advisory engagement that produces a buildable specification saves easily 20-40% on the subsequent build cost because the ambiguity is removed before developers start work. A £30,000 advisory engagement that produces a strategy deck saves nothing and often adds cost, because the developers end up re-doing the discovery themselves.

Insist on a fixed fee. Time-and-materials advisory engagements have poor incentives - the advisor is paid to keep discovering rather than to reach a decision. Fixed fee forces scope discipline on both sides.

Advisor-only vs advisor-builder: the choice that matters most

The single biggest decision in buying automation advisory is whether to use a firm that only advises or a firm that also builds.

Advisor-only firms - the Big Four, boutique strategy houses, most management consultancies - produce independent recommendations. They will tell you n8n is the right choice without any commercial interest in that being true. The trade-off is that their recommendations are often technically shallow because their teams do not maintain production automations. They will recommend Zapier for a use case where Zapier's execution model will not work, because they have not actually built the thing.

Advisor-builder firms - specialist automation agencies, this includes us - produce recommendations biased towards what they can build. That bias is real and worth pricing in. The offsetting benefit is that the recommendations are technically grounded, the specifications are actually buildable, and the handover between advisory and build is seamless because it is the same team.

The right choice depends on the stakes. For a £2m enterprise automation programme with regulatory exposure, buying independent advisory and running a separate build tender is defensible. For a £150k first automation programme, splitting advisory from build usually costs more, takes longer, and produces worse outcomes than picking a competent advisor-builder and holding them to fixed-fee milestones.

If you go with an advisor-builder, contractually separate the advisory phase from the build phase. Fixed fee for advisory. Right to take the specification to a different builder if the recommendation is unpersuasive. Most credible advisor-builders will accept this because they know their build proposal is usually the strongest one once the specification is written.

Red flags to watch for

The advisory market is crowded and quality varies wildly. Specific things to watch:

• Maturity models as the centrepiece. If the pitch relies on placing you on a 1-to-5 scale, the engagement is likely to produce a diagnosis rather than a plan. Maturity models are fine as one input; they should not be the output.
• No named practitioners. If the proposal describes "our team of AI experts" without naming who will do the work, expect a bait-and-switch to junior consultants. Ask for the CVs of the people who will be on-site.
• Vendor-agnostic taken to an extreme. Advisors who refuse to make tool recommendations because "every situation is unique" are avoiding the hardest part of the job. Every situation has constraints that narrow the choice to two or three viable tools; the advisor should tell you which.
• No production experience. Ask how many automations the firm currently operates in production for other clients. If the answer is zero, they may still be useful for strategy work, but they will not spot the operational failure modes that only become visible once something has been running for six months.
• Deliverables denominated in slides. A 60-slide readout is not a deliverable. A specification document, a tool decision log, a governance plan, and a costed backlog are deliverables. Push back on any SOW where the primary artefact is a presentation.

What good looks like after the engagement ends

Six weeks after the advisory finishes, you should be able to answer these questions without opening the deck:

• Which three automations are being built first, and when do they go live?
• Which tools have been chosen for the stack, and why?
• Who owns each automation once it is in production?
• What is the expected annual saving from the first wave, and how will it be measured?
• What is the budget for the next twelve months and what is on the backlog for waves two and three?

If you cannot answer these, the advisory did not do its job, regardless of how good the readout was. The purpose of advisory is to remove ambiguity and enable action. Anything that does not measurably move the organisation closer to shipped automations is overhead.

The UK Government's own guidance on Generative AI adoption in the public sector is worth reading here even for private-sector buyers, because it captures the same operational discipline: define the use case, define the owner, define the evaluation criteria, ship a bounded pilot. The consultancies that ignore this discipline produce plans that never survive contact with reality.

Frequently asked questions

How long does automation advisory usually take?

For a mid-market organisation with 50-500 employees, four weeks is a good default. That is enough time to shadow three to five teams, pull data from the systems where the workflow evidence lives, size the top opportunities, and write build-ready specifications for the first two or three automations. Engagements shorter than two weeks tend to produce lists rather than specifications. Engagements longer than six weeks are usually padded and produce diminishing returns. If a firm proposes a multi-month discovery phase, ask what will change in month three that could not have been decided in week four.

What's a realistic budget for automation advisory in the UK?

For a competent build-capable specialist firm, expect £20,000-£45,000 for a four-week fixed-fee engagement covering a mid-market operations footprint. Big Four and tier-one strategy houses will quote three to six times that for equivalent scope, with better production values on the deliverables and less technical depth on the recommendations. Independent senior practitioners run £12,000-£25,000 but have less bench for wide-scope discovery. The advisory fee is usually 10-20% of the first-year build spend it produces; if it is more than 30%, the ratio is off.

Should we hire an advisor who also builds, or keep them separate?

For programmes under about £250,000 total build spend, using an advisor-builder is usually faster, cheaper, and produces better outcomes because the handover friction is removed. For larger or regulated programmes, independent advisory followed by a competitive build tender is defensible. If you go with an advisor-builder, contractually separate the phases: fixed fee for advisory, explicit right to take the specification to a different builder for the build phase. Credible advisor-builders accept this because their build proposal usually wins on merit once the specification exists.

Do we need automation advisory at all, or can we just start building?

If you have one clearly painful workflow and an in-house engineer who understands it, just build it. Advisory is overhead for a single automation. Advisory pays back when you have five or more candidate workflows, no clear priority order, no consensus on tooling, and no view on what a twelve-month programme should cost. In that state, spending £25,000 on four weeks of advisory typically avoids £75,000-£150,000 of wasted build spend on the wrong automations in the wrong order.

How do we know the recommendations will actually work in production?

Ask the advisor how many automations they currently operate in production for other clients, and what their monitoring and incident-response pattern is. Firms that only advise cannot answer this credibly. Firms that build and operate can point to specific systems, uptime figures, and failure modes they have seen and designed around. The second signal is whether the advisory output includes an operations plan - who owns each automation, how it is monitored, what happens when an API changes. If that section is missing, the advisor has not been on the hook for keeping automations running and their production judgement should be discounted.

What about GDPR and data governance during the advisory phase?

Advisory work involves shadowing teams and reviewing process data, which typically means access to systems containing personal data. Sign a mutual NDA before discovery starts, put the advisor on your standard data processing terms, and restrict access to anonymised samples where possible. The Information Commissioner's Office has published specific guidance on AI and data protection that applies to both the advisory analysis and the subsequent build. A competent advisor will raise GDPR implications in the tool selection section - some SaaS automation platforms process data in regions that trigger transfer obligations, and this should be flagged before selection, not after.

How do we measure whether the advisory was worth it?

Set two success criteria before the engagement starts. First, at the end of the four weeks, can you name the first three automations to be built, their expected annual saving, and the developer or agency who will build them? If yes, the advisory produced actionable output. Second, twelve months later, how many of the recommended automations are actually in production and delivering the estimated saving? A good engagement produces 60-80% delivery on the first-wave recommendations. Below 40% suggests either poor advisory or poor execution capacity - usually the latter, which is why the capacity plan matters.

Can internal teams do this instead of hiring external advisors?

Sometimes. If you have a senior operations leader with automation experience, a technical lead who has shipped integrations, and a week of protected time from both, an internal team can produce credible advisory output. The failure mode is political rather than technical - internal teams struggle to prioritise across departments because they are subject to the same incentives as the department heads whose processes are being evaluated. External advisors get short-term political immunity that internal teams do not. For cross-functional programmes, this is worth paying for.

Where to start

Before commissioning any advisory work, spend a week internally listing the ten workflows that consume the most operational time in your business, and the five that most frustrate the people doing them. This costs nothing, sharpens the brief you take to advisors, and gives you a baseline to test their recommendations against. A good advisor will find things on this list you had not thought of and will de-prioritise items you assumed were urgent. That is the value they add.

If you'd like a pragmatic scoping conversation about what a four-week automation advisory engagement would cover for your organisation - specific workflows, expected outputs, fixed fee - AI Advisory runs these on a no-obligation basis and can share sample deliverables from previous engagements.

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