How to Find Work Worth Automating With AI (2026)

You are reading Chapter 29 of 36 in the AI Bootcamp, AI Central's free course for professionals who want to use AI in their own work. The chapters build on each other, so if this is your first one, Chapter 1 is the place to start. All of them sit on the AI Bootcamp page, and three more arrive every week.

To find work worth automating, log every recurring task for one week with its real minutes, run each one through 5 questions (what a mistake costs, whether the input arrives in a consistent form, how often it happens, how long it takes, and how stable the steps are), then do one sum before you build anything: minutes removed per run, times runs a year, minus build time and a year of upkeep. This chapter walks through all three and then takes one 40-minute Monday job through the audit, the build and a test against a week you already did by hand.

It follows Chapter 28, where you built one small, read-only automation and learned that every automation is a trigger, an action and a result. Now you point the same shape at real work.

We publish AI systems like this for 300,000+ senior professionals at AI Central, and more of them live in the AI Central Library.

You already know which task you would automate. It is the one you complain about: the monthly thing with the awkward spreadsheet, or the report nobody reads.

Be careful with that instinct. Irritation measures what a task costs you to sit through - boredom, interruption, the dread on Sunday evening. It says nothing about whether the steps are stable enough for something to follow them without you. A lot of the most hated work in a professional week is hated because it is fiddly and different every time, and that is the same property that makes it a poor candidate.

This is where people waste a fortnight. They aim at whatever annoys them most, build it, use it for three weeks and quietly stop.

For one week, note every piece of work you did more than once, or that you know you will do again on the same day next week. Write the day, and write how many minutes it actually took, not how many it felt like. Aim for about 6 candidates by Friday. Anything you cannot remember doing by Friday afternoon was not costing you much.

Two things a log catches that memory misses. The jobs you forget are the small ones, and the small ones are the frequent ones. And frequency hides cost: a 6-minute job you do every working day costs you more per year than a half-day job you do quarterly.

Leave mail and calendar work off this list for now. Those two get their own chapter next, on purpose.

Almost all recurring office work takes one of 4 shapes:

Two tasks with the same shape behave the same way when you automate them, even when one is a sales report and the other is a compliance check. The shape predicts whether an automation keeps working on real tasks far better than the subject does.

Put two more marks beside each candidate. First, does it end in something you could show a colleague: a file, a message, a row in a sheet? Work with a visible finished object is easier to build for and easier to check. Second, where does the input come from? If a machine produced it, good. If a person typed it, that matters more than anything else on the list, for the reason in the next section.

Five questions decide whether a task is worth automating, and how irritating it is does not appear among them: frequency, minutes per run, how stable the steps are, what a mistake costs, and whether the input arrives in a consistent form.

If you add all 5 into one score, a large enough time saving can outweigh a failure you cannot afford. So 2 of them are pass or fail: a task that fails either one cannot run unattended, however much time it would save. Read this list top to bottom and stop at the first line that is true:

Most of the work you would most like to be rid of stops at line 2 or line 3. A list that shrinks here is the audit working.

Ask what happens on the morning the automation gets it wrong and nobody notices. If a number goes out to a client, a payment is coded to the wrong account, or somebody senior reads something untrue, you do not let that task run without you checking it this month. It can still be automated with a person approving each run, which is what Chapter 34 covers. What you must not do is treat a big time saving as a reason to skip that step.

This is the single most reliable predictor in the audit. An automation is only as steady as the material arriving at the top of it. A system-generated export with the same columns in the same order every week is close to ideal. A PDF a supplier types by hand, in a slightly different layout each month, is not, and nothing you do downstream fixes that reliably.

When you hit this one, go upstream. Ask for the export instead of the summary, or replace the emailed request with a short form. For most professionals the cheapest automation available is a form that makes the input consistent, and it needs no AI at all.

Test stability by writing the task as a numbered list a colleague could follow while you are on leave. If you reach step 4 and find yourself writing "it depends", you have found the last step that can be automated. Automate the steps above "it depends" and stop there. That is usually the right answer, not a compromise.

Frequency and minutes are easier, with one trap each. Count runs per year rather than per week, because the year is the unit the sum works in. And time one real run with a timer instead of estimating, because the estimate is always the version where nothing went wrong and nobody interrupted you.

Some awful work fails this audit and stays yours. The quarterly job with varying inputs and expensive mistakes fails 3 of the 5 questions at once, and it will fail them again next year. Expect 1 or 2 of your 6 candidates to survive. If none do, you have avoided a build you would have abandoned in March.

The sum fits on one line: minutes removed per run, times runs a year, minus the hours to build it, minus a year of upkeep. Write both sides down before you open any tool.

For runs a year, weekly is about 48, every working day is about 250, and quarterly is 4. Four almost never pays.

The number people quote when they pitch an automation is the gross sum: how long the whole task takes, times how often you do it. It counts the parts you will still do by hand, counts a clean run rather than an average one, and stops counting on the day you finish building. It is fine for putting a shortlist in order.

The net sum counts only the steps you stop doing yourself and carries an upkeep line. Almost the whole gap between the two is that upkeep line, which is the one nobody writes down before building.

Take the candidate everyone reaches for first: a quarterly pack that takes 3 hours, 4 times a year. Gross saving, 12 hours. The automation removes maybe half of it, so 6 hours. It is a complicated build against varying inputs, so call it 6 hours to make. And because 3 months pass between runs, something will have moved every time, so add 3 hours of repair across the year. First year: 3 hours in the red. Year two is barely better, because after a 3-month gap you have to relearn your own build before you can fix it.

Now the one nobody gets excited about: 6 minutes, every working day, about 250 times a year. Gross, 25 hours. The automation removes 5 of the 6 minutes, so 21 hours. It is simple, so 2 hours to build and 2 hours of upkeep. First year: 17 hours saved, and better after that. The daily job beats the quarterly one by roughly 20 hours.

There is a second reason to favour frequent work. A job you do 250 times a year has been standardised by repetition, so its steps hold still. A job you do 4 times a year drifts between runs, because the business changed and the automation was built for the old version.

Zapier automatically switches off a Zap that errors 95% of the time and has run more than 20 times in the last 7 days. Microsoft Power Automate switches off a cloud flow whose trigger or actions fail continuously for 14 days, and any flow that has not been triggered for 90 days. Two of the largest automation platforms wrote standing policies for breakage and abandonment, which tells you how common both are.

Building has got cheaper: a low-code tool will now draft a workflow from a plain-language description. Upkeep has not got cheaper at all. Being able to make 5 automations in a morning is exactly why the sum matters more than it used to.

In 2025, METR randomised 246 real tasks among 16 experienced open-source developers. With AI tools allowed, they took 19% longer. Beforehand they had predicted a 24% speed-up, and afterwards they still believed they had been 20% faster. The study is about assisted coding, not scheduled automation, so take only the part that transfers: people are confidently wrong about their own time, in the flattering direction. That is why you time one real run instead of estimating it.

Here is the whole method on one real job. Every Monday you pull 3 standard exports, check the same 5 numbers against the previous week, write 4 sentences of commentary, and send it into the leadership pack. Timed properly, it takes 40 minutes, and you have done it most Mondays for 2 years.

A wrong number in a leadership pack is expensive, so this candidate nearly stops at line 1. It survives for a specific reason: an error would be visible to you in the output, the same morning, before anything leaves your hands. That is the condition to look for - not that mistakes are impossible, but that they are visible and cheap to catch where you already look.

The input passes easily. All 3 exports are machine-generated, with the same columns in the same order every week. That is the strongest signal in the audit.

Timed step by step, the job breaks down like this:

Pull and compare are completely fixed, with no exceptions in 2 years. Drafting is half fixed: the sentence pattern repeats even when the content does not. Judging is where no numbered list survives. So the candidate is not the whole task. It is the first 2 steps, and possibly a first draft of the third. Naming that boundary correctly is most of the skill in this chapter. Automating the judgement would save 5 minutes and remove the reason the job exists.

The automation removes the pull and the compare, 27 minutes, but adds about 3 minutes of reading and checking its output, so 24 minutes removed per run. Over 48 Mondays that is 1,152 minutes, a little over 19 hours. The build is about 2 hours, mostly describing the job in plain language and fixing the 3 things it gets wrong. Upkeep is half an hour a quarter plus an hour on the day one export changes shape, so 3 hours across the year. First year: about 14 hours net, and more in year two. That is a clear yes, at 24 minutes a week rather than the 40 you would have claimed.

The trigger is a time, early Monday. The action fetches the 3 exports and works out the 5 comparisons. The result is a short table of this week against last, plus a first-draft sentence for each number that moved more than a set amount, delivered to you and nobody else. Sending it on to the team is Chapter 31, and pulling in more systems is Chapter 33. Resist both this week: one automation, one output, one reader.

Run it over last Monday, a week you did by hand and still have the output for, and compare line by line. If the 5 numbers match, you have evidence rather than a feeling. Then run it in parallel for 3 more Mondays while still doing the job manually. That costs you 3 Mondays of doing the work twice, and it is the cheapest way in this track to catch errors before you rely on the output.

Write the build date on it and note which exports it depends on. The day one of them changes is the day it starts failing, and Chapter 35 covers how you find out.

Before this chapter, you could build an automation but had no way to choose what to point it at, so the choice defaulted to whatever annoyed you most. After it, you can tell a task worth automating from one that only feels like it is, price either in under 5 minutes, and take a survivor through a build and a test against a known answer.

You take two things into Chapter 30: your audited candidate with the sum you wrote for it, and a timed count of how many minutes a day you spend in mail and calendar. Chapter 30 runs the same 5 questions and the same sum on those two places, where most recurring work lives and where a careless automation does the most damage.

If you want the bigger picture of how multi-step AI systems are put together, our guide to building AI agents covers when to build one, and more guides like this live in the AI Central Library.

Log every recurring task for a week with its real minutes, then ask 5 questions of each: what a mistake costs, whether the input arrives in a consistent form, how often it happens, how long it takes, and how stable the steps are. The first two are vetoes. A task that fails either one stays manual or keeps a person approving each run, however much time it would save.

Multiply the minutes the automation actually removes per run by the number of runs a year, then subtract the hours to build it and a year of upkeep. Weekly work is about 48 runs a year, daily work about 250, and quarterly work 4, which rarely pays back.

Frequency multiplies the saving, and frequent work is stable work. A job done 250 times a year has standardised steps, while a job done 4 times a year drifts between runs, so the automation breaks and has to be relearned and repaired each time.

Usually not. Write the steps as a numbered list and automate only the steps before the first one where you would write "it depends". The judgement at the end of a task is often the reason the task exists, so it stays with you.

Run it against a week you already did by hand and compare the output line by line. Then run it in parallel with the manual version for a few more cycles before you stop doing the job yourself.