How to automate business processes
Automation pays in a specific order: measure, fix, then automate.
What should you automate first?
Name three repeating tasks. You get back a written plan in the right order, with the first four weeks set out. Copy it and hand it to somebody.
Three is enough to get an order. Leave a row blank if you only have two.
Start with
Name a task or two
Worth getting back
The first four weeks
Show the order, and what to leave alone
Before anyone builds anything
Want the plan checked against how the work really moves?
We reply within one business day.
Then: Score the first task on the list before anyone builds anything →
Saved in this browser, nowhere else. See all your answers together · All twenty-five tools
Measure where the hours go for a week, fix the worst process by hand, document it, then automate only what has been proven manually. The right first candidate is high volume, rule based and stable, which is rarely the task people complain about most.
Is it a fit?
Repetition
It happens weekly or more. Once a quarter is a checklist, not an automation.
Rules
The awkward cases can be written down, which is the test most tasks fail.
Owner
Somebody still owns the outcome afterwards, or the work reappears somewhere else.
The plan
Do these six, in order
A time against each one and a way to tell it is finished.
Log a week of hours
Every recurring task for five working days: who runs it, how long it takes, how often.
10 minutes a day · Done when every task has an hours-a-month number next to it
Cut the process before you automate it
Take the heaviest task and remove the steps that exist only because of how it grew.
2 hours · Done when the task has fewer steps and the same output
Pick one high-volume, rule-based task
The one with the most repetitions and no judgment in it.
30 minutes · Done when you can write the rule as one if-this-then-that line
Connect the two systems it moves data between
Use the tools you already pay for before buying another.
1 to 2 days · Done when data lands in the second system with nobody retyping it
Make breaks announce themselves
A failure alert to one named person, and a log of every run.
half a day · Done when you break it on purpose and the alert arrives
Bank the hours, then take the next row
Re-time the task and write the hours freed beside it.
1 hour · Done when the hours are recorded and the next task is chosen
Most automation projects fail before a single tool is opened, because the thing being automated was never working properly in the first place. Automating a broken process does not fix it. It makes the same mistake faster, more often, and with fewer people watching it happen.
The sequence below is deliberately slow at the start and fast at the end.
01.Measure a week of hours first
Before deciding what to automate, find out where the time goes. Five working days, rough half-hour blocks, everyone who touches the workflow. You are looking for the tasks that repeat, the ones that get retyped, and the ones people describe with a sigh.
Rank what you find by hours per month, not by how annoying it feels.
02.Fix the process before automating it
Run the corrected process by hand for at least one full cycle. If the steps are unclear, the exceptions undefined, or two people disagree about who approves what, automation will lock in that confusion and make it much harder to see.
This is the step teams skip and the one that decides the outcome.
03.Start with one high-volume, rule-based task
The first automation should be boring and obvious. High volume, clear rules, low judgment, and something that goes wrong visibly rather than silently. Invoice creation, onboarding checklists, lead routing, report assembly, status updates.
Resist starting with the hardest workflow, however tempting the payoff looks.
Twenty minutes with a practitioner from our team, and you leave with a plan for your specific situation.
Talk to an expert04.Connect the tools you already have
Most businesses need far less new software than they think. The tools already paid for usually cover the job, and the gap between them is where the work goes. Look at what the current stack can already trigger, send, and receive before adding anything.
When a new tool is needed, justify it against the hours in your log, not against the feature list.
05.Add monitoring so breaks announce themselves
Automation fails quietly, which is what makes it dangerous. A rule stops firing, an integration silently drops records, and nobody notices for six weeks because nothing appeared broken. Build the alert at the same time as the workflow, not afterwards.
Two things are enough for most builds: a notification when something fails, and a weekly count of what ran.
06.Bank the hours and pick the next one
Go back to the hours log and measure the same workflow again. Not an estimate, the same measurement. If the time did not move, find out why before building anything else, because something in the design is wrong and it will be wrong in the next build too.
Then decide deliberately what the recovered hours are for.
Automating the broken process.
No documentation; the automation leaves when its builder does.
The big-bang automation project; sequence beats scale.
Questions we get
The ones that come up on almost every call.
What should we automate first?
Whatever is high volume, rule based, and low judgment.
Will this replace people on the team?
In small and mid-sized businesses it almost never does.
What happens when the automation breaks?
It will, usually because a tool changed something upstream.
Do we need a developer?
For most business workflows, no.
Can you automate a process nobody has written down?
You can, and it is the most common way automation gets expensive. What gets built is one person version of the process, which is the version with the exceptions handled in their head. Write down the last ten real runs first, including the ones that went wrong, and the exceptions turn into rules instead of surprises after go live. That takes a couple of days and it is the difference between automating the work and automating one person habits.
Where the automation in question is AI, preparing for AI is the readiness check. On how much to write down first, document it or automate it.
Most of this is doable in house.
Your results so far
Kept in this browser, sent nowhere.
By Shaheer Shaikh, technology and operations consultant · Updated October 3, 2026
Read next
The service behind this guide, the questions people ask, and the next thing worth reading.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built