An Automation Maturity Model for Operations Teams, Level by Level

Almost every operations team I meet describes its automation as "pretty mature" or "still early". Both phrases are useless. Maturity is not a feeling, it is an inventory. A team is at a given level because it produces certain artefacts and cannot yet produce others. This model gives you five levels defined by observable evidence, a twenty-statement instrument to score yourself, the resourcing reality most plans ignore, and a twelve-month path if you are stuck at level two.

Why evidence beats adjectives

Adjective-based maturity models fail because everyone rates themselves one notch above where they are. Ask a manager how governed their automation estate is and they will say "reasonably". Ask them to produce the bot register and the data-loss-prevention policy, and the room goes quiet. So every level below is anchored to a single question: what can you put on the table? If the artefact does not exist, you are not at that level, no matter how good the demo looked. If you want the buyer-side view of choosing tooling before you govern it, my workflow automation buyer's guide is the companion piece to this one.

Level 1: Ad hoc individual flows

Automation exists, but it lives with people, not the organisation. One analyst has a macro that reformats the weekly report. Someone in finance built a flow that emails a reminder. These things work, which is exactly why they are dangerous: they are invisible until the person who built them leaves or changes desks.

Observable evidence:

• No central list of what automations exist
• Flows run under personal accounts, not service accounts
• When a build breaks, only its author can fix it
• Nobody can answer "how many automations do we run?" without asking around

This is not failure. It is where everyone starts. The risk is staying here while the count grows into the dozens.

Level 2: Departmental automation, no shared standards

A department has decided automation is worth doing on purpose. Finance or HR or operations has a handful of builds, maybe a citizen developer or two, and a shared folder of flows. The work is real and it delivers value. What is missing is any standard that travels beyond the team. Naming is inconsistent, error handling is whatever each builder felt like, and the next department over is solving the same problem a different way.

Observable evidence:

• A team-level list of automations exists, but no enterprise one
• Naming, logging, and error handling differ between builders
• No shared connection or credential strategy across departments
• Two teams have unknowingly built the same automation twice

Most teams that call themselves "advanced" are actually here. Level two is comfortable, and that comfort is the trap, because the estate is quietly accumulating risk with no owner.

Level 3: Governed platform with an owner

Now there is a platform, a named owner, and an environment strategy. Builds move through development, test, and production rather than being edited live. Access is granted through roles, not favours. There is a data-loss-prevention policy that says which connectors can touch which data, and it is enforced, not aspirational. Microsoft's own Power Platform governance guidance is essentially a manual for reaching this level and it is worth reading regardless of your vendor.

Observable evidence:

• A single register of production automations, kept current
• A DLP policy that classifies connectors and is enforced
• Separate development, test, and production environments
• Builds run under service accounts with role-based access
• A named platform owner who reviews and can decline new builds

Level three is where automation stops being a collection of clever tricks and becomes an estate you can defend in an audit. It is also the level teams are most tempted to skip.

Level 4: Measured portfolio with a benefits register

At level four you manage automation as a portfolio and you can prove its value. Every production build has a recorded expected benefit (hours saved, errors avoided, cycle time cut) and an actual measured against it. An exception dashboard shows which flows are failing and how often. Decisions to build, retire, or rebuild are made on numbers, not enthusiasm.

Observable evidence:

• A benefits register with expected versus actual value per automation
• A live exception dashboard covering run success and failure rates
• Retirement decisions for automations that no longer earn their keep
• A prioritised backlog scored on value and effort, not who shouted loudest

The benefits register is the artefact that separates a team that believes it saves money from a team that can show it. Without it, every budget conversation is a matter of faith.

Level 5: Process-led operating model

At level five, automation is a design output rather than a project. When a process is designed or redesigned, the question "which parts of this should be automated?" is asked at the drawing board, not bolted on afterwards. Process owners hold accountability for outcomes, and automation is one of the tools they wield. This is the territory Gartner labels hyperautomation , and the label matters less than the operating model behind it.

Observable evidence:

• Named process owners with role descriptions that include automation outcomes
• Automation considered during process design, evidenced in design documents
• A pipeline that connects process change to automation change
• Cross-functional automations that span systems, often riding on real enterprise system integration

The artefact that proves each level

You are at a level when you can produce its artefact. This is the whole model on one page.

The assessment instrument

Score each statement: 0 if false, 1 if partly true, 2 if fully true and you can prove it with an artefact. Be strict on that last word. Add your total at the end.

Foundation (level 1 to 2):

1. There is a written list of the automations my team runs.
2. Automations run under service accounts, not personal logins.
3. More than one person can fix any given automation.
4. We have a naming convention builders actually follow.

Governance (level 3):

5. A single register lists every production automation across departments.
6. A DLP policy classifies connectors and is technically enforced.
7. We have separate development, test, and production environments.
8. Access is granted through defined roles, not ad hoc requests.
9. There is a named platform owner with authority to decline builds.
10. New builds pass a review before reaching production.

Measurement (level 4):

11. Each automation records an expected benefit before it is built.
12. We measure actual benefit against that expectation.
13. An exception dashboard shows run success and failure rates.
14. We retire automations that no longer earn their keep.
15. The backlog is prioritised on value and effort scores.
16. Leadership sees automation value in numbers, not anecdotes.

Operating model (level 5):

17. Process owners exist with role descriptions naming automation outcomes.
18. Automation is considered during process design, not after.
19. A pipeline connects process change to automation change.
20. Cross-functional automations span systems by deliberate design.

Scoring key (max 40):

The resourcing reality nobody budgets for

Here is the number that plans leave out. Level three needs roughly one named part-time owner for every fifty production automations. That owner keeps the register current, reviews new builds, maintains the DLP policy, and chases down the flows that break. At a hundred production automations you are looking at close to a full-time equivalent split across governance and platform care.

Almost nobody budgets for this. Automation is sold as headcount you get back, so asking for headcount to govern it feels like admitting the pitch was wrong. It was not wrong, it was incomplete. The savings are real and so is the maintenance load, and an ungoverned estate of two hundred flows with no owner is not an asset, it is a liability waiting for its first incident. If your business case for automation has no line for governance, it is not finished.

A twelve-month plan from level two

Say you scored fifteen. You are a solid level two with real builds and no shared governance. Here is a realistic year.

Quarter 1 → Consolidate the register.

Merge every team list into one enterprise register of production automations. Move builds off personal accounts onto service accounts. This alone surfaces the duplicates and the orphans.

Quarter 2 → Name an owner and set boundaries.

Appoint a part-time platform owner. Write one DLP policy and enforce it. Stand up separate development, test, and production environments. This is the level-three foundation, and it is deliberately unglamorous.

Quarter 3 → Start measuring.

Add an expected-benefit field to every new build and backfill the top ten by usage. Stand up an exception dashboard so failures are visible the day they happen, not the week someone complains.

Quarter 4 → Turn data into decisions.

Run your first portfolio review. Retire the automations that no longer earn their keep, rebuild the fragile ones, and prioritise next year's backlog on value and effort. You end the year at a defensible level three edging into level four, which is a far stronger place than a level-five slide with nothing underneath it.

A note on independence

I sell integration and automation delivery, so treat this as a practitioner's opinion, not neutral research. I have named Microsoft and Gartner because their material is genuinely useful for this topic, not through any commercial arrangement. Whatever platform you run, the levels and their artefacts hold. Score yourself honestly, fix the level below the one you want, and let the vision wait until the foundation can carry it.