Which repetitive business tasks should you automate first?

Most businesses come to an automation conversation with a task already in mind. It is almost always the task that annoys someone most: the Friday report, the invoice pile, the inbox that never empties.

Annoyance is a reasonable signal. It is not a good enough one on its own. The task that annoys you most is frequently the task that is hardest to automate, because the thing making it annoying is exactly the thing a machine struggles with: inconsistency, judgment, and exceptions.

This article is the test we actually run on a first call, in the order we run it. You can do the whole thing yourself, on paper, before you speak to anyone. If you do, you will either arrive at a much cheaper quote or discover that you do not need to buy anything at all.

Start by counting hours per year, not times per week

The first question people expect is "how often does this happen?" It is the wrong question, or at least an incomplete one, because it makes high-frequency tasks look important and low-frequency tasks look trivial.

What matters is the total time the task consumes in a year.

• A task that takes 30 seconds, 20 times a day, is about 43 hours a year.
• A task that takes 4 hours, once a month, is 48 hours a year.

Those are the same size problem. But the monthly one usually feels less urgent, because nobody is irritated by it twenty times a day. Meanwhile the thirty-second task feels enormous and might be genuinely hard to automate, because it happens inside someone's head while they are looking at three systems at once.

Write down every candidate task and put an annual hours figure next to it. Be honest, and include the time spent switching context, finding the file, and checking the result. That number is your upper bound on value. It is not what you will save, because automation rarely removes 100% of a task, but nothing you build can be worth more than it.

Then apply the consistency test

Here is the question that actually predicts whether a project will go well:

Does this task happen the same way every time?

Not "does the data look the same" — the data should vary, that is the point. The question is whether the steps are the same. Open this, check that, copy here, notify them.

A quick way to test it: ask two different people who do the task to describe it, separately, without looking at each other's answers. If their descriptions differ in ways that matter, you do not yet have a process. You have a habit, and habits cannot be automated until they are written down.

This is not wasted effort. Writing the process down is the single highest-value hour you can spend before an automation project, and about a third of the time it removes the need for the project entirely — because once written down, someone notices three of the seven steps exist only for historical reasons.

Bring five real examples, including one bad one

Anybody can automate the clean case. The clean case is a demo.

Before you scope anything, collect five real inputs from the last month. Not made-up ones, not the tidy template you wish everyone used. Actual files, actual emails, actual rows. And make sure at least one of them is a mess: the invoice from the supplier who scans things crooked, the form where somebody wrote their phone number in the name field, the spreadsheet with the merged cells.

Those five examples do more work in a scoping conversation than an hour of description. They reveal:

• How many formats actually exist, versus how many you think exist.
• Whether the key information is reliably in the same place.
• What a human silently corrects without ever mentioning it.

That last one is the expensive category. People absorb enormous amounts of mess without noticing they are doing it. The fix is not to pretend the mess is not there; it is to decide in advance what the system should do when it sees it.

Find the decisions, and name who owns them

Every process has moments where a person decides something. Automation projects go wrong when nobody identifies those moments until the build is nearly finished.

Go through your written-down process and mark each step as one of three things:

Mechanical. The step has a rule. If the total is over ten thousand, route it to the manager. These are cheap and reliable to automate.

Interpretive. The step needs something read and understood, but there is a defensible right answer. Pulling the line items out of a PDF invoice in an unfamiliar layout. This is where AI earns its place, and where you need to decide how good is good enough, and how you will check.

Judgment. The step depends on context the system does not have. Whether to extend credit to this customer given what happened last quarter. Do not automate these. Route them to a person, with everything they need to decide quickly.

Then, for every interpretive and judgment step, write a name. Not a role — a name. Who approves this? If you cannot answer, the automation will stall the first time something unusual arrives, because the work will land in a queue nobody owns.

Check what the systems will actually let you do

This is the step that most often changes the answer, and almost nobody does it first.

Your process touches software. Whether that software will cooperate determines a large part of the cost. Before committing to a task, check:

• Is there an API, and is it documented? A documented API is the difference between days and weeks.
• Can you get an account with the right permissions? Sometimes the API exists but only on a plan you do not have, or only an administrator can issue credentials and that administrator is a vendor.
• Can data get out in bulk? If someone currently exports a CSV manually, that export is often available on a schedule or through an endpoint.
• Is anything locked? Some systems will let you read but not write, which can turn a two-way sync into a one-way feed and change the whole design.

A task with poor system access can easily cost several times more than a comparable task with good access. If you have two candidates of similar size, the one with better API access is almost always the right first project.

Put it together: a simple scoring pass

You now have, for each candidate task:

You are not looking for a perfect score. You are looking for the candidate with no zeroes. One weak factor is manageable; two is where projects get expensive, and a zero on system access is often fatal regardless of how good everything else looks.

Notably, "how much this annoys us" is not on the list. Keep it as a tie-breaker, because a team that is sick of a task will engage properly with the project, and that genuinely matters. But do not let it choose for you.

What good first projects tend to look like

Across the work we have done, the projects that go well share a shape. They are usually:

A handoff, not a whole department. Something leaves one system and needs to arrive in another, in a different shape. Narrow, testable, and the success criterion is obvious.

A recurring document task. Documents arrive, information is pulled out, records get created. Well understood, and the failure mode is visible rather than silent.

A report that already has a fixed definition. If the report has been produced the same way for a year, the definition is settled and the build is mostly plumbing.

A repeated question with a written answer. If people keep asking things that are already documented somewhere, that is a retrieval problem, not a process problem, and it is often the cheapest useful thing you can build.

What they have in common is that you can tell, quickly and unambiguously, whether the result is correct. That property is worth more than size, glamour, or how modern the technology sounds.

What to avoid for a first project

Anything where being wrong is expensive and hard to detect. Not because it cannot be built, but because a first project is also how you learn to trust the process. Choose something where mistakes surface immediately.

A process still being redesigned. If the steps are changing every few weeks, every change is a change request. Let it settle.

Something that needs six teams to agree. The coordination will cost more than the build.

The thing that annoys you most, unless it also passes the tests above. Frequently it does not, and that is exactly why it is still being done by hand.

Before you ask for a quote

Bring these five things and you will get an accurate number instead of a range wide enough to drive a bus through:

1. The task, written down as steps, in order.
2. Five real inputs, including at least one messy one.
3. The annual hours it currently consumes.
4. A list of every system it touches, and what access you can obtain.
5. The points where a person must decide, with a name against each.

That is the same list we work through on a first call. If you have prepared it, the conversation moves from "what might be possible" to "here is what this specific thing costs", usually inside half an hour.

If you want a second pair of eyes on which of your candidates to pick, that is exactly what our free consultation is for — and if the honest answer is that a scheduled script or a setting in software you already own would fix it, we would rather tell you that than sell you a project.