You already know automation would help. What you cannot work out is where to point it. The inbox, the follow-ups, the scheduling, the invoices, the CRM updates that somebody retypes twice, the review requests nobody remembers to send. Every article you open hands you a numbered list, and the lists do not agree with each other, so the decision keeps sliding to next week. That is not indecision. It is a reasonable response to contradictory advice, sitting on top of a specific fear: that you pick wrong, in front of a customer or in front of your team, and end up with another subscription nobody uses. The good news is that choosing well is a smaller job than the lists make it look, and you can do the whole thing yourself in an afternoon with a sheet of paper.
Key Takeaways
One opens with scheduling, one with invoicing, one with lead response, one with employee onboarding. The word first is being answered with whatever the publisher is nearest to selling.
Generating, sending and chasing invoices is a feature of software you can subscribe to. If a job is already somebody's product, buying it beats building it.
It happens often, a new hire could follow the rule from one example, the information is already digital, the exceptions are rare, and a person can check every result for a month.
If a mistake can charge money, change a price, make a promise, expose personal data, or touch a safety, employment, credit, health or legal decision, it is not your first one.
Write one sentence describing what correct looks like, name the person who inspects it for the first month, and keep a short list of the cases it could not handle.
Why does every list say something different?
Run the search yourself and look at the shape of the results rather than the advice. The first result is not an article at all. It is a discussion thread with 97 comments, which is Google saying, in the only way it can, that the published articles were not answering the question well enough. Below it sit four separate lists, and they open with four different tasks: appointment scheduling, invoicing, lead response, employee onboarding.
None of them is lying. They are answering a slightly different question, which is what tends to be worth automating in general, and each is standing closest to whatever it sells. Your business is not general. The task that eats your Tuesday is not the task that eats somebody else's.
There is a second, quieter reason the lists feel off. The U.S. Census Bureau, tracking business AI use, found the most common reason firms gave for not adopting it was simply that it was not applicable to their business. Not cost, not fear, not skill. Fit. A list of fifteen tasks cannot tell you about fit, because fit is a property of your process and not of the task's name.
So, the useful move is not to find a better list. It is to score your own candidates against criteria that hold regardless of who wrote the article.
Is your first automation already something you can rent?
Before you build anything, check whether the job is already a product. This is the cheapest question on the page and almost nobody asks it first.
The most commonly recommended first automation is invoicing, and the highest-voted reply in that discussion thread pushes back on exactly that: generating invoices, sending them and chasing them are already available as an ordinary subscription, and the person making the point had been running it that way for years without building anything. That is not an argument against automating invoicing. It is an argument against building what you can rent for less than the cost of the afternoon you would spend wiring it together.
The same logic covers a surprising amount of the list. Look at what small firms already run. In the UK government's Longitudinal Small Business Survey for 2024, among firms using business technology, 80% used accountancy software and 62% used electronic invoicing, while CRM use ran at 26% of micro firms, 42% of small firms and 54% of medium ones. That is UK data, and it measures adoption rather than anybody's first project, so read it as a rough map of what is already bought rather than as a benchmark you are failing. The pattern it shows is still useful: the back-office jobs are largely solved by products, and the gaps sit in the joins between them.
| If the task is | The honest first move | Why |
|---|---|---|
| A standard back-office job on its own, like invoicing or scheduling | Rent it | Somebody sells this as a product, maintained by them, for a monthly fee |
| The same information being retyped between two systems you already pay for | Connect it | This is a join, not a job, and joins are where the manual work actually lives |
| A decision your team makes the same way every time, from information you hold | Build it, narrowly | Nobody sells your process. This is the part worth your own time |
| Something the team does differently every week | Leave it | Automating an unstable process makes the instability faster |
What actually makes a task a good first candidate?
The published work on choosing automation candidates is unglamorous and it agrees with itself, which is more than page one manages. Researchers have tested rule-based methods for selecting these tasks, and the same properties keep coming out on top. It is worth knowing what they are, because once you have them, every list you read afterwards becomes easy to sort.
A study of rule-based selection for robotic process automation tested candidates on decision logic, data structure, stability, exceptions, frequency and duration. A separate study of automation projects lands in the same place: low complexity, standardisation, stability, digitised inputs and outputs, and volume. Strip out the vocabulary and you get five questions you can ask about your own work without any software at all.
Write down three to five tasks that annoyed you, got forgotten, or had to be retyped this week. Give each one a point for every yes.
The five questions, in the order worth asking them
- 1
Does it happen at least weekly?
Frequency is what turns a small saving into a real one, and it is also what gives you enough cases to test against in the first month.
- 2
Could a new hire follow the rule from one short example?
If you cannot write the rule down in a sentence, the automation cannot follow it either. This one question disqualifies more candidates than the other four combined.
- 3
Does the information already exist in digital form?
If somebody has to read a photograph, a PDF or a handwritten note to start the task, you have a data problem in front of your automation problem.
- 4
Are the exceptions rare?
Every process has awkward cases. The question is whether they are the exception or half the work, because ignored exceptions are the most common way a first automation quietly fails.
- 5
Can a person check every result for the first month?
Not forever. Just long enough to find out what it gets wrong before a customer does.
Then take two points off if a mistake can charge money, change a price, make a promise on your behalf, expose personal data, or touch a safety, employment, credit, health or legal decision. Start with the highest score that has not gone negative. It really is that ordinary.
Which tasks should you disqualify straight away?
Some candidates score well on every practical measure and still should not be first, because the cost of being wrong is carried by somebody other than you. That is a different question from whether the task is automatable, and it is the one most likely to be skipped when the demo looks good.
The consequence test is the one that matters. Anything that moves money, sets a price, promises a customer something, handles personal information, or feeds a decision about somebody's safety, employment, credit, health or legal position belongs later, with more care around it, and often with a person in the middle permanently. NIST's risk management guidance is built around exactly this idea: work out the non-monetary costs of an error, define where a human stays in the loop, test before deployment, watch behaviour in production, and keep a way to recover when something goes wrong.
The other disqualifier is instability. If the rule changed twice this quarter, or every second case needs a judgment call, the task is not ready. Automating it does not fix the ambiguity, it just applies the ambiguity faster and with more confidence, and the first person to notice is usually a customer.
And there is a failure worth naming plainly, because it costs more than the wasted setup: automating a process that should have been deleted. If two of the five steps exist because of a system nobody uses any more, remove them first. The cheapest automation in any business is the step that stops happening.
Should you automate your worst process first?
This is the loudest current argument, and it deserves a straight answer rather than silence. The case runs like this: builds that used to take months now take days, so starting with something small and easy wastes the opportunity, and you should point the first project at the process that hurts most.
Half of that is right, and it is the half that changed recently. The cost of trying genuinely has dropped. When a first attempt took a quarter and a budget, picking wrong was expensive and caution was rational. When it takes a few days, you can afford to be wrong, which means the argument for starting with something trivially safe is weaker than it was.
The other half does not follow. Cheaper building does not make an unstable process stable, does not digitise information that only exists on paper, and does not reduce the consequence of an automated mistake in a job that moves money. The properties in the selection research are about whether the task can be automated correctly, and those are unchanged by how fast anyone can now assemble the thing.
So, take the useful part. Do not pick something so trivial that nobody notices whether it worked, because you learn nothing and the team stays unconvinced. Pick the highest-scoring candidate on your own sheet, which is often the second or third most annoying task rather than the first. Your worst process is usually worst precisely because it is full of exceptions and judgment calls, and that is the definition of a poor first candidate.
How will you know it actually worked?
Decide what working looks like before you start, in one sentence, in ordinary words. Something like: every enquiry from the website is copied into the CRM and assigned to a named person, and anything it could not handle appears on a daily list. That sentence is the whole specification, and it does two things at once. It tells whoever builds it what correct means, and it gives you something to check against that is not a feeling about whether things seem smoother.
Then name the person who inspects the output for the first month. Not forever, and not nobody. Set and forget is the single most expensive assumption in this subject, and NIST's guidance says the same thing in more formal language: test before you deploy, monitor behaviour in production, keep a way to override, and have a plan for recovering when something goes wrong. For a small business that translates into three habits: read the exception list, check a handful of results each week, and keep a note of what it got wrong so the second version is better than the first.
One more thing worth doing, and it takes a week rather than an afternoon. Before you commit, actually track the repetitive tasks you do and roughly how long each takes. In that same discussion thread, one person did exactly that and found customer support was consuming far more of their week than invoicing, which everyone had told them to automate first. They automated support instead, and it was the right call for their business specifically. Your week will tell you something the lists cannot.
Which candidate would you start with?
1. Two tasks score equally on frequency and clear rules. One updates a customer's price, the other copies web enquiries into your CRM. Which goes first?
2. Your team handles the same task a slightly different way each week. What does that tell you?
3. The job you want automated is chasing unpaid invoices. What is the first thing to check?
Pick an answer to begin.
Frequently Asked Questions About Choosing What to Automate First
Q: What should I automate first in my business?
The task on your own shortlist that scores highest on five questions: it happens at least weekly, a new hire could follow the rule from one example, the information is already digital, the exceptions are rare, and someone can check every result for a month. Then subtract anything where a mistake would charge money, set a price, make a promise or touch personal data. The answer changes from business to business, which is why the published lists disagree.
Q: Is invoicing really the best first automation?
Often it is a job to rent rather than build. Generating, sending and chasing invoices is a standard feature of accounting and invoicing products, and paying for that is usually cheaper than wiring it together yourself. Where automation earns its place is in the joins: getting the information into the invoicing tool without anyone retyping it.
Q: Do I need AI for this, or will ordinary automation do?
Frequently the second one. If the rule is clear enough to write in a sentence, a plain rules-based connection is more predictable, cheaper to run, and easier to debug than a model. Reach for AI when the input is genuinely messy, like free-text messages that need sorting, and keep a person checking the output while you learn how often it is right.
Q: How many things should I automate at once?
One. The first project is as much about learning how your business responds to a change as it is about the saving, and the lesson from the first one usually rewrites what you thought the second one should be. Running three at once means that when something goes wrong you cannot tell which one caused it.
Q: What if the task I want to automate is the one everybody hates?
Score it honestly against the five questions before committing. Tasks are frequently hated because they are full of exceptions and judgment calls, which is exactly what makes a poor first candidate. If it scores well, take it. If it does not, take the second one and come back with more confidence and a working example behind you.
Q: How long before I know whether it worked?
A month of checking every result is a reasonable first pass, because that is long enough to meet the awkward cases. You should be able to answer three things at the end of it: did the expected output happen every time, what did it fail on, and did anybody quietly go back to doing it by hand. That last one is the honest measure.
Q: What if my information is spread across paper and spreadsheets?
Then the first job is not an automation. Getting the information into one digital place is a prerequisite, and it is often worth doing on its own merits. Automating on top of scattered or unreliable data produces confident output built on a shaky base, which is harder to spot than an obvious error.
Wrapping Up
The lists disagree because they are answering a general question and you have a specific one. Score three to five of your own candidates on frequency, a rule you can write down, digital information, rare exceptions and a person who can check the results, then take two points off anything where a mistake touches money, prices, promises, personal data or a consequential decision. Check whether the winner is something you can simply rent. Then write one sentence describing what working looks like, and name the person who inspects it for a month.
Do that once and you get more than an automation. You get a repeatable method, so the second choice takes an hour instead of a fortnight of reading, and a team that has watched a change land safely rather than one that has been surprised by one.
If you would rather have somebody walk the week with you and point at the join that is actually costing you, that is what our AI consulting work is for at Web Leveling, and where a build genuinely is the answer, our AI automation work covers it, with the accounts and the workflow in your name so nothing here holds you hostage. Plenty of the time our honest answer is that the job is a product you can rent, and we will tell you that instead of quoting you for it. We work with small and medium businesses across the country and overseas, wherever they are. Send us the shortlist you scored and tell us what your week looks like, and we will tell you which one we would start with.
Terms
The words that make this sound harder than it is
Tap a term to see what it means.
Workflow. The full path a piece of work takes from the thing that starts it to the thing that finishes it, including the awkward cases nobody documents.
Exception. A case the normal steps do not cover. Rare exceptions are survivable. Frequent ones mean the task is not ready.
Rules-based automation. A plain if-this-then-that connection with no model involved. Predictable, cheap to run, and the right answer far more often than it gets credit for.
Integration. A connection between two systems you already pay for, so information moves without anyone retyping it. Most first wins live here.
Exception list. The short daily list of what the automation could not handle. If nobody reads it, you do not have an automation, you have a hole.
Baseline. What the task costs you now, in time or errors, written down before you change anything. Without it, no improvement can be shown and no claim can be checked.
Human in the loop. A named person who reviews output before it counts. Standard practice wherever a mistake would be consequential, and not a sign the automation failed.