Automation Readiness Assessment

What this tool does and who it is for

It scores your business across five pillars, gives you a number out of 100, and tells you which pillar to fix first. The point of the ordering is that readiness is not additive: the pillar dragging you down costs the least to move and unlocks the most.

It is for anyone about to spend money on automation for the first time, or anyone whose first attempt quietly stopped working after a few months. If you already know the process you want to automate and just want to price it, the ROI calculator is the better starting point. This assessment answers the earlier question: is anything here in a fit state to be automated yet?

The five pillars are process maturity, data quality, technology stack, team capability and leadership buy-in.

How to read the output, with a worked example

Take a nine-person professional services firm. The scores come back:

Total: 60 / 100 — partially ready. That is one point below the "ready" band, which is where the useful part starts.

Two ways to gain six points. Document five more processes and process maturity goes 12 → 18, total 66, into the ready band. Or work on buy-in, which is already 16, and the most you can gain is 4, total 64, still stuck. The lowest pillar is almost always the cheapest points, and the highest pillar is almost always where people want to spend. That is the whole reason to score rather than to guess.

Now the part most readiness checklists miss. That 14 out of 20 on technology stack is generous, because "has an API" and "has enough API" are different questions, and the second one has a number attached.

Say the first automation is an order confirmation flow: twelve actions, running on 200 orders a day. Microsoft counts each action as a Power Platform request, including things as small as initialising a variable, and its documentation is explicit that "both successful and failed actions count toward these limits" and that "retries and requests from pagination also count as action executions". So 12 × 200 is 2,400 requests a day before any retries, and budgeting 3,000 is realistic.

On a seeded Office 365 licence the official allowance is 6,000 requests per user per 24 hours. One flow has taken half of it. A second flow of similar shape leaves nothing, and the allowance does not roll over — unused requests expire at the end of the 24-hour window. Power Automate Premium raises that to 40,000 per user per 24 hours, and a Process licence attached to a single flow raises it to 250,000. Same automation, same business, three different verdicts on whether it is affordable to run.

That is what a technology-stack score should be measuring, and it is why a readiness assessment that only asks "do your tools have APIs" tells you almost nothing.

The method: what each pillar is actually testing

Process maturity tests whether the process is stable and specified, not whether it is good. Automation encodes a decision; if the decision changes monthly, you are buying maintenance rather than leverage. "Documented" also means more than a screen recording. BPMN has been a formal OMG standard since 2011 and at version 2.0.2 since January 2014, and its stated purpose is to be "precise enough to allow BPMN diagrams to be translated into software process components". A diagram at that level of precision can be handed to a developer. A Loom video cannot.

Data quality tests whether the automation will be able to find things. Duplicate contacts mean an automation that updates the wrong record; empty phone fields mean a reminder flow with a silent failure rate nobody measures.

Technology stack tests API availability, then API budget, then what happens when the budget is exceeded. Throttling is the usual answer, and a throttled flow looks exactly like a broken one to the person waiting for the email.

Team capability tests maintenance rather than building. Building an automation is a day. Noticing three weeks later that it has been silently failing since a field was renamed is the actual skill.

Leadership buy-in tests whether there is a named owner. Automations without an owner do not get switched off when they break; they get worked around, which is worse.

What your score means

The bands are deliberately blunt. A score of 58 and a score of 62 are the same business; the value is in which pillar is lowest, not in the total.

Common mistakes

Automating the process you dislike most rather than the one you repeat most. Frequency times duration is the number that matters. A monthly two-hour reconciliation is 24 hours a year. A four-minute task done thirty times a day is 260 hours. The time waste calculator does that arithmetic properly.

Treating "we have an API" as the end of the technology question. It is the beginning of it. Ask for the rate limit, the daily allowance and the throttling behaviour before you design anything around it.

Documenting the process as it is supposed to work. The version in the SOP and the version that actually happens differ, and the difference is where the exceptions live. Watch it happen once before writing it down. The workflow visualiser is a quick way to get the real version out of somebody's head.

Scoring yourself generously on team capability because someone is technical. Being able to write Python and being willing to be paged when a webhook fails at midnight are different qualifications.

Frequently Asked Questions

What does automation readiness actually mean?

It measures whether your processes, data and systems can sustain an automation after it is built, rather than whether one can be built. Most first automation projects fail on the sustaining half: undocumented processes drift, dirty data causes silent errors, and nobody owns the thing when it breaks.

What is the minimum score worth acting on?

Anything above 40. Below that, documentation and data cleanup are the work, and doing it first is not a delay. Between 41 and 60, one narrow high-frequency process is the right size of first project. Above 60 you can plan a programme rather than a project.

Which pillar should I fix first?

The lowest one, almost always. Six points gained in a pillar scoring 8 costs far less than four points gained in a pillar scoring 16, and the low pillar is usually the one that will break the automation.

How do API limits affect readiness?

They decide whether an automation is affordable to run, as opposed to possible to build. Platforms meter by request, not by automation, and every action counts, including failures, retries and pagination. Multiply your action count by your daily volume and compare it against the allowance on the licence you actually hold, not the one in the marketing material.

Do I need documented processes before automating anything?

For anything that crosses systems or has a consequence when it goes wrong, yes. The developer has to encode a decision, and an undocumented process means they encode their guess at it. For a single-step task inside one tool, the tool's own automation features are usually enough and documentation is overkill.

What to do with the result

Take the lowest pillar and the highest-frequency process, and start there. If the lowest pillar is process or data, the business process analyser digs into where the friction actually is. If it is the technology stack, the work is reading rate limit documentation before choosing a platform, which is dull and saves months.

Where this tool stops is the join between the two. Scoring a business is straightforward; deciding which of seven candidate processes is the one that will survive contact with real data, and building it so that its failures are visible rather than silent, is not. That is the part I get called in for: n8n and Make.com builds, custom FastAPI services when the off-the-shelf connector does not exist, and the monitoring that means a broken flow announces itself instead of being discovered a month later.

If you have a score and no idea what to do with it, that is a good message to send. I am on Upwork and Fiverr, or at iam.mbilalvirk@gmail.com. For background reading, what workflow automation actually is covers the vocabulary, and API automation for businesses goes further into the limits question above.