There are two kinds of automation
The first is the one everybody thinks of: a job you already do by hand. The monthly report, the follow-up emails after a call, pulling the numbers together for a Monday meeting. The aim is to get something close to what you’d have produced yourself, with much less of your time spent on it.
The second is work you’d never have started. Not because it wasn’t worth doing, but because it would have taken somebody days and you were unlikely to prioritise it.
Every business has a list of those. Reading back through a year of client feedback to see what people actually keep asking for. Checking every page of the website against what you now say you do. Writing up the thing everyone agrees should be written up. The list is real, and until recently the honest answer was that nobody was ever going to get to it.
A useful question, then: what have you avoided doing because it would have taken days, but might now be worth attempting because AI can reduce the effort substantially?
In the first month, most of what people get back comes from automating the jobs they were already doing. The work nobody was ever going to get to is where they’re genuinely surprised, and it usually comes later.
Every automation is: inputs, actions and outputs
They all have the same shape. Something goes in, some work happens, something comes out.
Usually more than one of each. Two or three things going in, a handful of steps in the middle, and an output in a couple of places, because the person who wanted it and the place it gets filed aren’t always the same. Writing those down clearly before you build anything makes the rest much easier.
- InputsWhat it starts from. A recording of a call, the emails that came in this week, a spreadsheet, a folder of past work, or just you talking.
- ActionsWhat happens in between. Reading, comparing, deciding, drafting, filing.
- OutputsWhat you get, and where it lands. A draft in your inbox, rows in your tracker, a document in the folder you work from.
Four things get you from one end to the other, and each has a name you’ll have heard.
Writing the job down once, so the AI can follow the same process each time, gives you a skill. Letting it reach into the apps the work lives in, Gmail or your tracker or Xero for instance, instead of you pasting things in and out, is a connector. Giving it the useful, up-to-date context it needs to do the work well, so you don’t have to start from scratch each time, is your second brain. And setting it to happen every Monday without you starting it makes it a scheduled task.
Most automations need two or three of those, not all four. Each has its own page here if you want it.
Pick one by writing down what you already do
Not from a list of ideas. From your own month.
Write down the jobs you do more than once. Not everything you do, the ones that come round again: the report, the chase, the write-up, the thing you do every time a project starts. Then put three columns against each one.
- 01How oftenTimes per month. Weekly beats quarterly, because the saving compounds.
- 02How longMinutes or hours each time you do it.
- 03How much it variesIs the overall process broadly the same each time, even if individual cases need different judgement?
Start with something frequent, slow and repetitive. One of them. Not the whole list.
Decide what you’re measuring before you build it
Do this before you build anything, because it gets much harder to establish a reliable baseline afterwards. Once the automation is running, nobody remembers how long the job used to take, or how often it slipped a week, and the best answer you’ll get is that it feels quicker.
So pick the thing that actually matters, and write down where it stands today. How long it takes you now. How many you get through in a month. How long it sits before somebody picks it up. How often it comes back wrong.
Then look at the same number a month later. That gives you evidence of whether the automation actually improved the job.
Build your automation from real examples
If you can, find around ten real examples of the job being done. Not a description of the job, the actual things: the inputs that went in, and the outputs you produced, matched up in pairs. Put two of the pairs aside before you start, and don’t use them for anything yet.
Give most of those pairs to Claude or ChatGPT and ask it to study them before producing anything new. What the tone is, how they’re structured, what sits where, what’s the same every time and what changes. Then ask it to question you about anything it couldn’t infer: the points where it can’t tell why a particular input led to a particular output. That conversation often surfaces rules and judgement calls you use without consciously writing them down.
When you’re happy with the instructions, save them as a skill so you don’t have to rebuild the process next month.
Then test it on the two pairs you kept back, one at a time. Give it the input only, let it produce its output, and then hand it the real one and ask it to compare the two. Fix what’s off, then do the same with the second pair. That comparison is a much better test of whether the automation works on new examples. If you build and test it on the same examples, the result can look stronger than it really is.