Updated May 2026. Rewritten end-to-end so the advice matches what we have actually seen ship (and stall) across roughly forty automation programs since the original article.

We are Osher Digital, an automation and AI consultancy based in Brisbane. Most of the automation roadmaps we get asked to review look fine on paper. They have phases, owners, KPIs, a Gantt chart with a confident slope. They also tend to stall in month four. The first two projects ship, sponsor enthusiasm peaks at the steering committee demo, and then the program sags under its own weight.

This guide is the document we wish someone had handed us before we wrote our own first roadmap. It covers what to actually put in one, what to leave out, and the structural choices that decide whether your second wave of projects ships or quietly disappears from the next quarterly review.

If you want background on the broader topic before reading on, our explainer on what AI automation actually is covers the vocabulary. For the n8n-specific operational angle, our piece on building AI workflows in n8n shows the kind of project a roadmap eventually has to deliver.

Why most automation roadmaps stall by month four

Three things happen, in this order, and we have watched them play out enough times that we now plan around them.

The first wave of projects is always the easiest. Someone picked them because they were obviously broken and obviously fixable. The team ships. Sponsors get excited. The roadmap looks vindicated. Then the second wave begins, and nobody picked those projects with the same care. They were slotted in to fill out a quarterly plan. Nobody owns the data, nobody can find the upstream system contact, and nobody has actually validated that the process map on slide twelve matches reality.

The second thing that happens is that the people who built the first wave are now busy supporting it. We have seen organisations build six automations in their first quarter and then stop building anything new for nearly a year, because the support and maintenance load swamps the team. Nobody planned for this. The roadmap had a build line and an outcomes line. It did not have a maintenance line.

The third thing is sponsor turnover. The CFO who funded the program gets a new portfolio, the new CFO has different priorities, and the next funding round is suddenly competitive. By month four to six, you need a roadmap that can survive a sponsor change. Most can’t.

What an automation roadmap actually is

The textbook definition is a strategic plan that sequences automation initiatives over time. That is technically true and operationally useless. The roadmaps we have seen survive year one share a different shape. They are a small, opinionated document that answers four questions: which problems are we solving in what order, who owns each one, what we will not do this year, and how we will know if it is working.

The “what we will not do” line is the one most roadmaps skip. Without it, every department head reads the document and assumes their pet project is implicitly in scope. Six weeks later you are reviewing twenty-eight intake requests and the team has lost two days to triage. Write down the exclusions. Be specific. “We are not automating anything in the legal team this year” is more useful than three pages of vague prioritisation criteria.

Audit before you plan: what we actually measure

Before we write a single line of a roadmap, we spend two to three weeks on a structured audit. The audit produces three artefacts: a process inventory with rough volume and effort numbers, a systems map with integration points marked, and a list of things people complain about that are not on the process inventory yet.

The complaint list matters more than people expect. The official process inventory will tell you what the team thinks they do. The complaint list tells you where the actual friction lives. We have lost count of the times a process owner described a workflow as “running smoothly” while the team responsible for it had a Slack channel full of invective about the same workflow. Talk to the people doing the work, not just their manager.

For the systems map, we capture three things per integration: who owns the source system, whether there is an API or whether you will have to scrape, and the last time anyone successfully changed something in that system. The third one is the diagnostic. If the answer is “we have not touched it since 2019”, you are looking at a frozen system that will resist automation. Plan around it.

Pick the wedge: the first three projects

The first three projects do disproportionate work. They build the team’s confidence, they build the sponsor’s appetite for further funding, and they teach you whether your tooling choices were correct. We pick them with three rules.

Rule one: at least one project that ships in under six weeks. This is the credibility purchase. It does not need to be transformative. A weekly report that used to take a person two hours and now takes the system fifteen minutes is fine. The point is to demonstrate motion, in front of the sponsor, before anyone has time to lose interest.

Rule two: at least one project that proves the integration spine. Pick something that touches your CRM, your finance system, and one piece of email or messaging. If you can move data through those three reliably, most future projects will work. If you can’t, you have a structural problem to solve before the roadmap goes any further.

Rule three: nothing in the first wave that requires a vendor procurement cycle. We have watched eight-week deployments turn into eight-month deployments because someone added a tool that needed a security review, a procurement sign-off, and a SOC 2 questionnaire. Use what you already have. The tool selection conversation comes later.

Build the prioritisation grid (and stop revisiting it)

The classic two-by-two of impact and effort is fine. The mistake is treating it as a continuous reprioritisation exercise. We score the backlog once a quarter, agree the next four to six projects, and then close the door. If a new request shows up mid-quarter, it goes into the next scoring round. No exceptions, including for the CEO. Especially for the CEO.

For scoring, we use five factors and weight them deliberately. Manual hours saved per month, expressed as actual hours not “estimated FTE”. Error rate today and the cost of those errors. Strategic importance, capped at a 1.5x multiplier so it cannot dominate the maths. Implementation effort in calendar weeks, not story points. Maintenance effort once shipped, which is the factor most teams omit.

Manual hours saved (40% weight). Pull this from time-and-motion observation, not survey data. Surveys overstate by roughly 2x in our experience.
Error rate and cost (20%). A two percent error rate on invoices through a finance team is more expensive than it looks once you factor in supplier disputes and the people-time those generate.
Strategic importance (15%, capped). The cap is the important bit.
Implementation effort (15%, inverse). Shorter is better.
Maintenance load (10%, inverse). A workflow that needs weekly babysitting is worth less than a workflow that runs untended.

Pick technologies after the process, not before

The most expensive mistake in a roadmap is committing to a stack before you have written the first project. We have walked into clients who bought UiPath licences twelve months before they had a single automatable process well-defined. The licences sat. The team felt obliged to use them. They built RPA bots for problems that wanted API integrations.

Once you have your first wave defined, the technology choices follow. For most mid-sized organisations, the stack is some combination of an integration platform like n8n, Make, or Zapier; a low-code workflow tool like Power Automate or Pipedream; an AI layer (Claude or GPT-4.1 via API for the cognitive work, with structured outputs and validation); and a small amount of glue code where nothing else fits cleanly. Heavyweight RPA suites like UiPath or Blue Prism earn their place in narrow situations: legacy desktop apps with no API, regulated sectors that need centralised control, and large-scale repetitive screen work. We cover the boundary between n8n and traditional RPA in our piece on n8n for robotic process automation.

For the AI layer, current model identifiers we deploy are claude-sonnet-4-5 for most extraction and classification work, claude-opus-4-5 for harder reasoning tasks, and gpt-4.1 or gpt-4o-mini when the price/latency tradeoff favours OpenAI. Pin your model versions in your code. Do not use claude-sonnet-latest in production unless you genuinely want quality drift on rollovers.

Budget, headcount, and the second-wave problem

The single most predictable failure mode is underbudgeting maintenance. If you ship five workflows in your first quarter, by month six you are spending roughly a quarter to a third of your team’s capacity keeping them alive. This is not a sign of poor engineering. It is the cost of integrating with other people’s systems that change without warning.

For a typical mid-sized engagement, we model the year-one cost something like this. One internal automation lead at full time. One implementation engineer or a partner engagement at half to full time. A platform and tooling line of $1,500 to $4,000 AUD per month covering the integration platform, observability, and any hosted AI usage. A “things you forgot” buffer of 15 to 20 percent. The buffer is not optional. It will get used.

If you want a structured discussion about what your specific budget shape should look like, book a call and we will walk through it for your situation.

The change management work no one budgets for

Most roadmaps treat change management as a sentence on a slide. In reality it is the work of training people who used to do the task by hand, agreeing what happens when the automation fails, and writing down who is on the hook to fix it. None of this is glamorous and all of it is the difference between an automation that runs for years and one that gets quietly switched off after the first weird Tuesday.

One specific habit we recommend: write a one-page operations note for every workflow you ship. What it does, what to do when it breaks, who to call. Keep it next to the workflow itself, not in a separate wiki nobody opens. The single biggest debugging session we have lost time on was an invoice automation that had been running for fourteen months when the developer left. There was no operations note. The new team spent three days reverse-engineering the flow.

Measuring whether the roadmap is working

Pick three metrics and report them every fortnight. We use these.

Hours returned to the business per month, calculated from observed time-and-motion baselines. We do not include “soft” benefits in this number. They go in a separate narrative section. Mixing them dilutes the credibility of the headline.

Workflows in production versus workflows in maintenance. If the maintenance count is climbing faster than the production count, the team is heading for the second-wave stall.

Mean time to recovery when something breaks. We have a rough internal benchmark of under four hours for routine breakage, under one business day for upstream system changes. If recovery is taking longer, the workflows are too tightly coupled to systems you don’t control, and the architecture is the problem, not the people.

When a formal roadmap is not what you need

For organisations under about thirty people, a written roadmap is overhead. You do not need a Gantt chart to know that invoice processing eats half of finance’s week. Pick the worst process, automate it, ship the next one. The roadmap document becomes useful around the point where two or more business units want different things at the same time and you need a written tie-breaker.

For organisations under serious regulatory load (APRA-supervised entities, healthcare providers managing My Health Records data, anyone who has to answer to the Office of the Australian Information Commissioner about Australian Privacy Principle compliance), the roadmap also has a different shape. The first six months get spent on data flow mapping, audit trail design, and access controls. The shiny automation work comes later. Get this wrong and a single audit can wipe out a year of program credibility.

A six-month template you can adapt

This is the cadence we have settled on after iterating with multiple clients. It is not the only correct shape, but it is one that consistently survives the four-month wall.

Weeks 1 to 3. Audit. Process inventory, systems map, complaint list. Sponsor sign-off on what is in and what is out.
Weeks 4 to 6. First wedge project ships. Something small, fast, and visible.
Weeks 7 to 12. Second and third projects in parallel. Integration spine project running alongside one more visibility project.
Weeks 13 to 16. First retrospective. Tighten the prioritisation grid. Decide what tooling to standardise on. Bring in a second engineer if volume warrants it.
Weeks 17 to 22. Second wave begins. Maintenance discipline tested for the first time.
Weeks 23 to 26. Quarterly review. Hours-returned number reported. Roadmap updated for the next two quarters.

If the second wave does not ship between weeks 17 and 22, that is the diagnostic. Either the audit was wrong, the team is too small for the load, or the second-wave projects were chosen the way roadmaps usually choose them: poorly. We have written more about the kinds of projects worth picking in our overview of AI agent development for businesses.

Frequently Asked Questions

How long should building the roadmap actually take?

Two to three weeks for the audit, one week to write the document and get sponsor sign-off. Anything longer than four weeks total and you are over-engineering the document at the expense of shipping. The roadmap is a working artefact, not a finished product. It will change.

What does an automation program cost in the first year?

For a mid-sized Australian organisation we typically see year-one program costs of $80,000 to $250,000 AUD covering internal headcount, tooling, and partner engagement. The high end of that range usually reflects regulated environments where audit and compliance work front-loads cost. ROI typically lands in the second half of year one if the roadmap is well-sequenced.

What is an automation prioritisation matrix and how do we use it?

It is a scoring framework that ranks candidate processes by impact and feasibility. Use it once a quarter to set the next four to six projects. Do not use it as a daily intake tool. The point is to make a decision and then commit to it for a quarter, not to perpetually rerank a queue.

What does “quick wins rollout” actually mean in practice?

It means the first wave of projects you pick deliberately for visibility and speed, not for strategic significance. A weekly report automation that shaves two hours off a finance lead’s week is a perfect quick win. The purpose is to buy credibility for the harder projects in the second wave.

Should we build a Centre of Excellence or buy a partner engagement?

For organisations under about 200 people, a partner engagement is usually faster and cheaper for year one. A CoE makes sense once you have a steady pipeline of more than ten new automations a year and the maintenance load justifies dedicated headcount. Building a CoE prematurely creates an internal team with nothing to maintain, which becomes a political problem within twelve months.

Where does AI fit on an automation roadmap?

AI belongs in the cognitive parts of workflows: classification, extraction from unstructured documents, summarisation, drafting, and decision support that needs natural language reasoning. Leave the deterministic plumbing (moving data between systems on a schedule, applying business rules) to traditional integration tools. Mixing the two layers in the same workflow design works well; trying to make an LLM do work an integration platform is better at is a common failure pattern.

How do we handle legacy systems with no API?

Three options, in order of preference. First, find an undocumented API. Most modern enterprise software has one even when the vendor pretends otherwise. Second, screen-scrape with RPA tooling and accept the maintenance overhead. Third, replace the upstream system, which sounds extreme until you cost out three years of brittle scraping. We tend to push clients toward option one harder than they expect.

How do we measure ROI without overstating it?

Use observed time-and-motion baselines, not survey data. Discount soft benefits in the headline number; report them separately as a narrative. Be honest about maintenance cost: the savings figure should be net of the engineering time you spend keeping the workflow alive. Programs that survive board scrutiny are the ones with conservative, defensible numbers, not the ones with the splashiest claims.

Where to from here

A good automation roadmap is not the document. It is the small set of opinionated choices the document forces you to make: what you will not do, who owns each piece, and how you will know when something has stopped working. If yours has phases and Gantt bars but no exclusion list and no maintenance budget, that is the work to do this week.

If you would rather not write the document yourself, or if you have one and you can already feel the second-wave stall coming, get in touch. We have done this badly enough times to know what we would do differently.

An Automation Roadmap That Survives Year One