How to Choose Your First AI Automation Workflow

Most failed AI automation projects were not built badly. They were chosen badly.

The build is the part everyone plans for. Selection is the part that gets decided in a meeting, by whoever spoke last, based on which department complained loudest. Then four months later the workflow is technically working and nobody uses it, because the process it automated ran nine times a month and the person who asked for it has moved teams.

So here is the model we score candidates against before we recommend building anything. It is our working delivery model, not a validated industry benchmark. Use it to pick, and more importantly, use it to say no.

The ten factors

Score each factor for each candidate workflow. Do not average them. A single hard failure disqualifies a candidate no matter how well it scores elsewhere.

1. Volume and frequency

Good signal. It runs daily or many times a day, and the work queues up. Someone can tell you roughly how many arrive in a week without looking it up.

Warning sign. It runs a handful of times a month. Low volume workflows can still be worth automating when each instance is slow and painful, but the case has to be argued rather than assumed, and it rarely deserves to be first.

2. Input variation

Good signal. Every instance means the same thing but arrives looking different. Different layouts, different phrasing, different senders. This is where a model earns its place.

Warning sign. The input arrives as clean structured fields in a known schema. You do not need a model. You need a rule, and the rule will be faster, cheaper, and testable.

3. Data availability and quality

Good signal. The context needed to decide is reachable through an API or a query, and two systems asked the same question give the same answer.

Warning sign. The deciding context lives in someone's head, in an unshared spreadsheet, or in a policy nobody has written down. This is a hard failure. Automating on top of missing data does not produce a smarter system, it produces a faster wrong one.

4. Cost of an error

Good signal. A wrong output is caught downstream and corrected cheaply. That gives you room to launch, learn, and tighten.

Warning sign. A wrong output moves money, creates a legal position, or reaches a customer unreviewed. Not a disqualifier, but it makes the human approval gate mandatory, and that changes the economics you should expect. Automating a process that still needs full review of every output buys you a better draft, not a removed cost. Decide whether the better draft is worth it.

5. Need for human judgment

Good signal. The judgment involved is interpretation of a known policy against a varied input. That is delegable.

Warning sign. The judgment requires relationship context, negotiation, or accountability. If your best person makes this call by weighing things they could not fully articulate, the model will produce something plausible and wrong. Automate the preparation for that decision instead, and leave the decision alone.

6. Integrations

Good signal. The systems involved have real APIs, and someone in your company can grant credentials this quarter.

Warning sign. A critical step lives behind a system with no API, a shared login, or a vendor whose access request takes six weeks. Count the integrations honestly. Each system in the chain is a source of failure, a permission conversation, and a maintenance cost. Two systems is a build. Six is a programme.

7. Process stability

Good signal. The process has run roughly the same way for months, and the people who run it agree on what the steps are.

Warning sign. The process is mid redesign, or three people describe it three different ways. Do not automate a process you are about to change. Stabilise it first, even manually. Automating an unstable process locks in a version nobody agreed to.

8. Security and access sensitivity

Good signal. The data involved is ordinary business data, and the access required is scoped to the systems in the workflow.

Warning sign. The workflow touches regulated data, payment credentials, health information, or personal records at scale. Also a warning sign: the only way to give the automation access is to give it a privileged account that can do far more than the workflow needs. Solve the scoping problem before the build, not after.

9. Ability to measure the before and after state

Good signal. You can state today's numbers in some usable form. Cycle time, queue depth, manual hours, error rate, anything with a baseline.

Warning sign. Nobody can describe the current state except as "it takes ages." This is a near hard failure, because without a baseline you will never resolve the question of whether the automation helped, and that question will be asked. If the baseline does not exist, spend two weeks measuring before you spend two months building.

10. Named owner after launch

Good signal. A specific person, by name, wants this and will still be accountable for it in a quarter. They will read the alerts. They will approve the promotions from human review to automatic. They care whether it works.

Warning sign. The owner is a team, a shared inbox, or "operations." This is a hard failure. Unowned automations are not maintained, and unmaintained automations get switched off quietly after the first bad week. Of the ten factors, this is the one that predicts survival most reliably.

How to score without pretending it is science

Score each factor as strong, acceptable, or failing. Then apply three rules.

1. Any hard failure disqualifies the candidate. Missing data and no named owner are always hard failures.
2. Factors two and five decide what you build. High input variation plus delegable judgment means a model belongs here. Low variation means it does not, regardless of how the other eight score.
3. Factors one, six, and seven decide whether to build it now. High volume, few integrations, and a stable process is your first build. Everything else waits.

Do not build a weighted spreadsheet and present the total to a board. The score is a conversation structure, not a valuation. Its real purpose is to make disagreement specific, so that the argument becomes "we cannot get that data" instead of "I do not think this will work."

What to build instead

Half of a good selection process ends in something other than an AI build. These are the honest alternatives.

Ordinary rules. Structured input, stable policy, deterministic outcome. Cheaper to run, trivial to test, and it does not drift when a model version changes. Most of the workflows presented to us as AI candidates are this.

Robotic process automation. A step lives inside a system with no API and no prospect of one, and the interface is stable. Accept that it will break when the screen changes, and build the monitoring accordingly.

An AI model inside a workflow. Input variation is high, the judgment is bounded, the actions are enumerated, and the code around the model does the fetching, enforcing, writing, and alerting. This is the shape most business problems actually need and the shape we build most often.

An agent. The sequence of steps genuinely cannot be known in advance, and the available actions are reversible or gated. If the actions are irreversible and ungated, you do not have an agent candidate. You have a risk you have not priced.

A human process, left alone. Low volume, high judgment, high error cost, relationship dependent. Some work is correctly done by a person. Deciding that on purpose is a result, not a failure.

How to reject a bad candidate

You will need this more often than the selection itself, because the loudest candidate is rarely the best one.

Three hard stops, each of which ends the conversation on its own:

1. The data does not exist. The workflow needs context that is not recorded anywhere reliable. The answer is a data project, not an automation project.
2. Nobody will own it. No named person is accountable after launch. The answer is to find the owner, and if none exists, that tells you what the workflow is worth to the business.
3. The process is being redesigned. Whatever you automate will be wrong within a quarter.

Two soft stops worth arguing about:

1. The volume is too low to matter. Fix it with a checklist, a template, or a rule, and revisit if volume grows.
2. Every output needs full human review anyway. You are buying a better draft. Sometimes that is genuinely valuable. Often it is not worth a build.

The sentence to say out loud is this: "This is a good workflow and it is not our first one, because we cannot get the data and no one has agreed to own it." Naming the blocker rather than the verdict keeps the stakeholder on your side, and it turns a rejection into a list of prerequisites they can actually go and clear.

What to do with the workflow you rejected

Rejected does not mean dead. Write down which factor failed and what would have to change. Missing data becomes a request for a field to be captured at source. No owner becomes a question for whoever asked for it. An unstable process becomes a reason to finish the redesign.

Keep that list. In our experience the second and third automation a company builds usually comes off it, because clearing one prerequisite tends to fix several candidates at once.

Where to start

If you have a shortlist, score it against the ten factors this week. You will probably disqualify most of it, which is the point.

If you do not have a shortlist, or you have one and no agreement on it, that is what the Business Audit is for. We map the workflows, score them against this model, and tell you which one to build first, including the cases where the answer is ordinary software or nothing at all.

If you want to see how the chosen workflow gets designed, built, and maintained afterwards, read how we approach AI automation.