Guide
How to tell whether a workflow is ready for AI automation
By Mavrin Labs. Published . Last updated . How this guide was researched and checked.
A workflow is ready for automation when you can say what it does, how often it runs, what a good result looks like and who approves the steps that matter. This guide sets out the checks that answer those questions, and what to ask anyone who offers to build the system for you.
What is AI automation, and when is a workflow ready for it?
AI automation is a workflow that runs across the systems you already operate, with steps inside it that read, sort or draft the parts plain rules cannot handle. A workflow is ready when its steps are known, its input is available to software, and someone can say what a correct result looks like.
Readiness has little to do with how advanced the technology is. It depends on whether the work has a shape. A task that runs forty times a week along familiar steps is a safe candidate. You can test the build against real examples and measure the result afterwards. A task that takes a different route every time it runs is not, because nothing stable exists to build against and nothing tells you whether the finished system is behaving.
The practical test is a description test. If you can write the task down in a page, including where it goes wrong, the work is ready for a build.
If you cannot describe the task in a page, the first piece of work is the writing, and no software will do it for you.
Six readiness checks you can run this week
Each check below is something you can do without hiring anyone. Together they produce the written record a builder needs, and they often change which task you automate first.
What does a workflow need before it is automated?
A workflow needs four things before it can be automated dependably: a stable sequence of steps, input that software can reach, a field that identifies each item without ambiguity, and permission to read and write in every system involved. Missing any one of them turns a build into guesswork.
- The sequence of steps is stable, and every branch and exception is written down.
- The input arrives somewhere software can reach, such as a shared inbox, a form or a system with an interface for other software.
- One field identifies each customer, order or document without ambiguity across every system involved.
- Someone has granted permission to read and write in each of those systems, and you know who that is.
The sequence has to be stable rather than simple. Branches and exceptions are fine, as long as you can list them.
The identifying field matters more than most owners expect. If two systems hold the same customer under different spellings, every later step inherits that confusion, and the automation creates duplicates faster than any person could. Access is the item people discover last. Permission to write into the accounting or scheduling system usually belongs to someone who never attended the scoping meeting.
How do you hire a firm to build it?
Judge a firm on how it handles the measurement conversation. Ask how the result will be agreed before the build, how the baseline will be recorded, what happens to items the system cannot handle, and who you contact when it breaks. The answers separate builders from sellers quickly.
- How will the result be agreed, and what baseline will it be measured against?
- Which steps does the system take on, and which steps does a person approve?
- What happens to an item the system cannot handle with confidence?
- Who builds it, and who do I contact when it stops working?
- Where do the rules live, and what would a different builder need in order to take over?
- What changes in my systems, and does anything have to be replaced?
Ask the exceptions question twice if you have to, because the plan for exceptions is most of the real engineering, and a firm that waves it away has not done the thinking.
Compare approaches rather than reputations. Some firms sell a platform and fit your work to it. Some build on the systems you already operate. Some only advise. None of those is wrong, but they lead to different outcomes when your process changes, so the question to settle is which one matches how often your work changes.
At Mavrin Labs the measurable results method sets out how a target and a review date are agreed before a build starts, and how engagements work describes the stages.
Standards behind this guide
Two public references are worth reading before you commission any system with an AI step in it. The risk management framework for artificial intelligence published by NIST sets out a way to govern, map, measure and manage the risks of a system, and its structure is a useful checklist for deciding what you will watch after launch (the framework, checked Thursday, October 8, 2026).
For systems that use a language model to read or draft text, the OWASP list of top risks for large language model applications describes failure modes in plain engineering terms, including what can go wrong when untrusted text reaches a model that has permission to act (the risk list, checked Thursday, October 8, 2026).
Neither reference tells you which task to automate. Both are useful for deciding where a person stays in control, which is the readiness question most often skipped.
Next steps
If your readiness review points at a repeat task with a measurable baseline, AI automation is the service that matches it. If you are still deciding whether to build, buy, connect or automate, the systems decision framework works through that choice, and the custom AI agents guide covers the case where the work changes with every item.
Handled well, repeat work stops consuming the week, and the hours it was taking return to the people you already employ. Mavrin Labs builds these systems for businesses and nonprofits anywhere, meets clients in person across Sarasota and Manatee counties, and works by video everywhere else. The areas we serve page sets out the detail.
Frequently asked questions
How long should a readiness review take before a build starts?
A readiness review takes as long as it takes to watch the work happen and write down what you saw. For most small-business tasks that means sitting with the person who does the job, following a handful of real items from arrival to finish, and noting where each one waited. The useful output is a short written record: the steps, the people, the systems touched, the exceptions you met and how long the task took. If you cannot describe the task that way yet, the review is not finished, and starting a build would only move the confusion into software.
What if the task is not documented anywhere?
An undocumented task is normal and it is not a reason to stop. Write the steps down as you watch them, in the order they actually happen rather than the order anyone intended. Expect to find steps nobody mentioned, such as a quick check in a second system or a message sent to confirm something. Those hidden steps are usually where the hours go, and they are also where an automation built from a tidy description would fail. The written record you produce is the first deliverable of the work, whoever builds it.
Does my data need to be clean before automating anything?
Your data does not need to be clean everywhere, but it does need to be dependable in the fields the workflow reads and writes. Pick the task first, then look only at the records it touches. Check that the key field identifying a customer or an order is filled in and unique, that dates and amounts follow one format, and that duplicates are rare enough to handle as exceptions. A workflow that reads one reliable field can run while the rest of the records are still being tidied.
Which tasks should I leave alone for now?
Leave alone any task that changes shape every time it runs, that depends on a judgment you would struggle to explain to a new member of staff, or that happens too rarely to repay the setup. Also leave alone work where a mistake would be expensive to undo and nobody would notice it quickly. Those tasks are better served by making the manual version clearer first. The honest answer from a builder is sometimes that a task should stay with a person.
What should a proposal from an automation firm contain?
A proposal should name the task, the baseline it was measured at, the result you agreed to aim for, and the date you will both look at the numbers again. It should say which steps the system takes on, which steps a person approves, and what happens to an item the system cannot handle. It should name who builds it and who you contact when something breaks. A proposal that describes technology without naming a result is not yet a proposal you can judge.
What are the warning signs when choosing a builder?
The clearest warning sign is a promise of results made before anyone has looked at your work. Others are a refusal to record a baseline, no agreed review date, a plan that depends on replacing systems your staff already rely on, and a proposal that will not say where a person stays in charge. Vague language about intelligence and transformation, with no description of the task itself, is the same warning sign wearing better clothes.
Who should own an automation after it goes live?
One named person inside your business should own each live workflow. Ownership means that person is told when the system stops, knows how to run the task by hand in the meantime, and decides when a rule needs to change. The builder keeps the technical responsibility you agree in writing, but the owner is the reason a quiet failure gets noticed in days instead of months. Decide who that is during the readiness review, while it is still an easy question.
Who writes these guides
Mavrin Labs delivers client work as a team in mixed roles, led by our founder. The people who write these guides are the people who build the systems described in them, and every page is reviewed before it is published.
Which hours would you take back first?
Send Mavrin Labs one workflow that is costing you the most time, and the reply comes back by email from the people who would build the fix.
Start a conversation