How Do You Decide What to Automate First?

How Do You Decide What to Automate First?

Start with the work that is high volume, low stakes, and easy to check. Those three conditions together are what make an AI automation pay off quickly and fail safely. Most teams pick the opposite: the painful, judgement heavy task nobody enjoys, which is exactly where automation disappoints.

We get asked to build these pipelines regularly, and the brief is usually a list of annoyances rather than a list of candidates. Annoyance is a poor selection criterion. Some of the most annoying work is annoying precisely because it needs a person.

Here is the framework we use to sort a list into an order.

Why Does the First Choice Matter So Much?

Because it sets the organisation's opinion of the whole idea. A first automation that works quietly for three months buys you permission to build ten more. A first automation that produces confident nonsense in front of a customer ends the programme, whatever the roadmap said.

There is also a compounding effect on skill. The team learns how to write prompts, how to evaluate outputs, how to monitor a pipeline. That learning transfers. Starting somewhere forgiving means the learning happens without a cost attached.

So the first choice is a political decision as much as a technical one, and it is worth treating that seriously rather than dismissing it.

What Is the Single Most Useful Question?

What does it cost when this is almost right. Not wrong, almost right, which is the characteristic failure of language models and the one people underestimate.

The 2025 Stack Overflow Developer Survey puts a number on how familiar that experience is. It found the top frustration, reported by 66% of developers, is AI solutions that are almost right but not quite. Not failures that announce themselves, near misses that require someone to notice.

So run the question on each candidate. An almost right meta description is a small edit. An almost right invoice is a finance problem. An almost right message to a customer is a relationship problem. Sort your list by that answer alone and you already have most of the framework.

Can Somebody Check the Output Quickly?

This is the second filter, and it is about economics rather than safety. If verifying the output takes as long as producing it, automation has moved the work rather than removed it.

Good candidates have outputs that are fast to scan and obvious when wrong. A list of extracted fields against a source document. A draft that a human was going to edit anyway. A classification with a confidence signal attached. Bad candidates produce outputs whose correctness can only be established by redoing the task.

A useful test: could a competent person check 20 outputs in 10 minutes. If yes, you can build a review step that actually gets used. If no, your review step will be skipped within a fortnight, and skipped review is the same as no review. This is where the design of human in the loop workflows is decided.

Does It Happen Often Enough to Matter?

Volume is what pays for the build, and teams are consistently bad at estimating it. Something that feels constant often happens eleven times a month, while something nobody mentions happens four hundred times.

Count before you build. Actual counts from a log, a CRM, an inbox or a ticket queue, over a real month. The candidate list usually reorders itself once real numbers appear, and the winner is frequently something nobody had nominated.

Volume also decides your architecture. High volume, unattended work should run as a batch job, because both OpenAI and Anthropic price asynchronous batch processing at 50% of standard rates. If the winning candidate is high volume and nobody is waiting, that choice halves the running cost before you write a prompt.

Is a Model Even the Right Tool?

Often not, and this is the cheapest saving available. If the task has clear rules, a script or a rule in your existing tooling will be more reliable, faster, cheaper and easier to debug than anything involving a model.

The dividing line is ambiguity. Language models earn their cost where the input is messy and the rules are fuzzy: free text, varied formats, human phrasing, judgement about tone or category. Where the input is structured and the rules are stated, deterministic code wins on every axis.

We push hard on this because the failure is expensive in a slow way. A model doing work a regular expression could do is a permanent bill and a permanent source of variability, and it is the distinction we draw in choosing between an AI agent and a script.

What Does Automation Do to a Bad Process?

Magnifies it. The 2025 DORA report on AI assisted software development frames this well, finding that AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses.

That is the most useful sentence we have read on the subject. If your content process has no editorial standard, automating it produces more unstandardised content. If your lead routing rules are wrong, automating them routes more leads wrongly, faster.

So before automating anything, write down how the task is done well today. If nobody can, the first project is not an automation. It is defining the standard, and doing that will improve the output even if you never build anything.

Who Owns It After Launch?

Ask before you start, because an AI automation is not a finished artefact. Models get retired on published schedules: Anthropic commits to at least 60 days of notice before retiring publicly released models, while OpenAI commits to at least 6 months for generally available models and roughly 2 weeks for preview models.

That means every automation you build carries a maintenance obligation with a date attached. Somebody has to notice the notice, test the replacement, and ship the change. If no name goes next to that responsibility, the automation will fail silently at some point in the next year.

Factor this into the first choice. A workflow owned by a team that can maintain it beats a more valuable workflow owned by nobody.

How Do You Know It Worked?

Decide the measure before you build, and make it something other than "it feels faster". Time saved per run multiplied by runs per month is the obvious one. Error rate compared to the human baseline is the honest one.

That second measure needs a baseline, which means measuring the current human process first. Teams skip this and then cannot answer whether the automation is better or worse than what it replaced, which turns every future argument into opinion.

Build a small set of real examples with agreed correct answers before you start. Ten is usually enough. It becomes your test for launch, your test after a model change, and your evidence in the meeting where somebody asks whether this is working. That set is the backbone of evaluating an automation before production.

What Are the Usual Good First Candidates?

In marketing and web operations, a recognisable short list keeps coming up. Drafting meta descriptions and alt text at scale, where the output is short, checkable and was going to be edited anyway. Classifying and routing inbound form submissions. Summarising calls or tickets into a standard format. Extracting structured fields from documents into a spreadsheet. Turning a long piece of source material into first draft variants.

What these share is the pattern: frequent, checkable in seconds, and cheap when almost right. None of them are the most interesting problem in the business, which is precisely why they are good places to start.

The candidates to defer are the ones touching money, contracts, customer communications sent without review, and anything where a mistake is discovered by a customer rather than by you.

What Would We Do in the First Two Weeks?

Write down every candidate task with four columns: how often it happens, what it costs when it is almost right, how long checking takes, and who would own it. Fill it in with real counts, not estimates.

Then pick the highest volume task in the bottom half of the risk column, build the smallest possible version, run it alongside the human process for two weeks, and compare. Do not switch anything off until the comparison exists. The scepticism is warranted, and the wider profession shares it: the same Stack Overflow survey found only 3% of developers highly trust AI output while 46% actively distrust its accuracy, even as 84% use or plan to use these tools.

If you have a list of things you would like to automate and no confident way to order it, we are happy to work through the columns with you. You can find us at phoenix.studio.