A first automation is a tool that takes one recurring task off a person's plate, start to finish, without anyone kicking it off each time, for instance copying a new enquiry from your website into your customer list and sending the first reply. "Automation" here covers the whole range, from a workflow tool (software that watches for something in one app and does something in another) to a custom tool built around a language model such as Claude, meaning the kind of AI that reads and writes text. The first one matters more than any that follow, because it decides whether your team trusts the next one.
What makes a task a good first candidate?
Three things, and all three are about the work rather than the technology.
It is done the same way every time. The same information comes in, the same steps happen, the same thing goes out. If two people on your team would do it two different ways, it isn't ready yet, and there's a section below on that.
The steps fit on one page. If you can't write the steps down in an afternoon, nobody can build them either, and the tool will do whatever the builder guessed. The page is also the test. Hand it to someone new and see whether they can do the job from it.
Somebody waits on it. A task that costs you an hour a week is a nuisance. A task that holds up a quote, a booking or an invoice until one particular person gets to it is a bottleneck, and a bottleneck is the step where work waits longer than it takes to do. The waiting is where the money is.
Beyond those three, the first candidate should be boring. A task where a wrong answer costs you a customer is a bad place to learn what your tools do when they're wrong. Pick the dull one and you get the quote out the same day, stop typing the same thing twice, hand the reminder to something that doesn't forget, and give the person everyone was waiting on their afternoon back. All of it from one task nobody will miss.
Where do businesses actually put their first automations?
In routine office work, mostly. Anthropic's Economic Index report of January 15, 2026 looks at how businesses use Claude through its API, meaning the connection a company's own software uses to send work to the model. It found that office and administrative support tasks made up about 13% of that business traffic in November 2025, up roughly 3 points since August, and it describes businesses "increasingly using Claude to automate routine back-office workflows" such as email, document processing, customer records (what the report calls CRM) and scheduling. The same report found that the longer a task would take a person, the less often the model got it right: in its words, "as the time it would take a human to do the task increases, Claude's success rate falls."
So the evidence points the same way as the three tests. The short, dull, repeated task is where automation is being used and where it works, and the ambitious tool that tries to do a whole job is the one that ends up switched off.
How do you find the candidate in your own week?
Keep a list for five working days. Every time you or someone on your team does a task for the second time that week, it goes on the list with three things next to it: how long it took, whether anyone was waiting on it, and whether it was done the same way as the first time. Don't try to be complete. Five days catches the weekly work, which is the work this is about.
At the end of the week, cross off anything that was done differently the second time, because that is a process problem and it isn't an automation candidate yet. Cross off anything nobody waited on, because that's a nuisance, and nuisances can wait. What's left, if anything, is your shortlist, and the one at the top is the one with the longest wait on it.
How does our free diagnostic decide?
The same way, with fixed rules doing the crossing-off. The Bottleneck Finder™ is our free diagnostic. It asks seven questions in plain English about how the work gets done, nothing about technology, and matches the answers against 42,000 tested combinations across 57 industries. Every one of those combinations lands in one of seven kinds of fix, from "don't spend anything yet" to "we run it for you every month", and two of the seven cost you nothing with us.
The part I'd want you to notice is who decides. A set of rules we wrote and fixed in code picks the kind of fix, what we'd build and what it would cost. The language model only writes the explanation for your industry. It can't add a service, move a price, or turn a "don't build this" into a maybe. So you can answer the same seven questions tomorrow and get the same answer, which is the test of whether something is a diagnostic or a sales pitch with a chatbot in front of it.
We built it that way for two reasons. A recommendation that changes when you ask again isn't a recommendation, and we wanted "spend nothing yet" to be a real outcome that the model couldn't talk anyone out of. I'm not going to put a number on how often it lands there, because I'd be guessing. That being said, it lands there whenever the answers say it should, and nothing in the wording step can move it.
When should you fix the process first?
When the task passes the waiting test and fails the same-way test. Automating a task with no agreed steps freezes one version of it, whichever version the builder saw, and everyone who did it the other way routes around the tool: a side spreadsheet, a "just this once" email, a phone call. Before long you have the old process and the tool, and the tool is one more thing to keep updated.
The fix is on paper. Get the people who do the task to agree one set of steps, write them on the page from the first section, and run the task that way by hand for a few weeks. If the page holds, automate the page. If it doesn't, you've learned for free what a build would have taught you at full price, which is that the task isn't one task.
When is the answer to build nothing?
In three cases, and the Bottleneck Finder is built to say so in each of them.
- The task costs less than the tool would. Every automation needs a named owner, a written list of what it depends on, and a review date, which we covered in why business automations stop working. If the task is a few minutes a week, owning the tool costs more than doing the task.
- The slow step is a decision. If work waits because a person has to approve it, price it or say no, automating the legwork around them only helps when the legwork is what's slow. Often the decision is the slow part, and the decision stays with a person.
- The business around the task is about to change. A new system, a product line you're dropping, a hire who changes who does what. Automate after the change, when you can see what the task has become.
In each case the answer is nothing. No cheaper tool, no smaller version. Nothing, and a date on the calendar to look again.
What can't this method tell you?
It only sees what you write down. A five-day list catches weekly work and misses the monthly and the seasonal, so if your worst week is quarter-end, keep the list in that week. It tells you where the wait is and nothing about what the wait costs; that figure is yours to find with the people who do the work. And it doesn't tell you which tool, which is a separate question, and the one our custom AI tools and automation work answers.
The Bottleneck Finder has the same limits in a different shape. It covers 57 industries, and it has never seen your business. It matches your answers against tested situations, and it doesn't read your books or your inbox. A person still decides whether to build anything, and the brief it hands you is a starting point, whoever ends up doing the work.
We sell the build work, so weigh that. If nothing in your week repeats, or your shortlist comes up empty, the honest answer is to spend the money somewhere else, and the diagnostic will tell you the same thing.
What did you do for the second time this week? If the answer comes easily, that's your first candidate, and if it doesn't, you may be in better shape than you thought.