How to Automate Business Processes: What to Pick First
Most advice asks what you could automate, which is nearly everything. The four tests that decide what you should automate first, a two-minute readiness check you can run on one process, and what an unattended integration was quietly putting in our own CRM.
Most advice about how to automate business processes starts in the wrong place. It asks what you could automate, which is nearly everything, rather than what you should automate first, which is usually one specific thing.
The difference matters because the cost of picking wrong is not a wasted project. It is a process that appears to work, quietly stops, and takes months to notice. We have done that to ourselves, and the example at the end of this article is our own.
Here is the decision framework, a readiness check you can run on one process in about two minutes, and the sequence that keeps the result honest.
What counts as a process worth automating
Four tests, and a process needs to pass all four. Failing one is not fatal, but it tells you what to fix before you build rather than after.
| Test | The question | Why it decides |
|---|---|---|
| Frequency | Does it run many times a day, or twice a month? | Build cost is fixed. Frequency pays it back. |
| Rules | Could a new joiner follow it from a written page? | Unwritten judgment becomes a model guessing. |
| Reach | Is the data behind an API, or on paper? | Most of the work is moving data, not the clever part. |
| Detection | If it silently stopped, would you find out? | Skipped most often. Doing nothing looks like working. |
That fourth test is the one worth dwelling on, because it is the difference between an automation you can leave running and one somebody has to supervise. A process that fails it has not been automated. It has been hidden.
Run the check on one process
Should you automate this process?
Pick one process you have in mind and answer for that one. Eight questions, nothing is sent anywhere, and no email is asked for.
0 of 8 answered
The order that keeps it honest
Teams usually sequence this by what is most impressive. The sequence that survives is boring and starts with measurement.
Five steps, in this order
- 01
Measure the process as it is
Hours spent, error rate, turnaround time. Pick one number and write it down with today's date. Without a before, nobody can argue about the after, and you will end up defending the project on vibes.
- 02
Write the rules down
Not a flowchart for a slide. The actual decision rules, including the edge cases the experienced person handles without thinking. This document is the specification, and the act of writing it usually finds the real problem.
- 03
Build the smallest version that works end to end
One real case, all the way through, writing to the real system. Not a demo on sample data. The last ten percent of any integration is where the surprises live, so reach it early while the project is still cheap to change.
- 04
Put the alert on before launch day, and watch it fire
Make it fail on purpose and confirm somebody is told. A monitor that has never gone red is proven quiet, not proven working, and the two look identical until the day you need it.
- 05
Compare against the number from step one
Then decide whether to widen it or stop. Most automation programmes never do this step, which is why so many of them run for years without anyone being able to say whether they helped.
What this looks like when it goes wrong
Our own CRM takes contacts from a WhatsApp integration. It had been running for months and nobody had looked closely at what it was producing. When we audited it this week, most of what it had created were not leads at all.
What one unattended integration was actually putting in our CRM
- A synced phone address booknot enquiries at all56%
- Genuine inbound messagesreal, and untagged44%
View as a table
| Record type | Share |
|---|---|
| A synced phone address booknot enquiries at all | 56% |
| Genuine inbound messagesreal, and untagged | 44% |
Two separate things were arriving through one pipe. Real people messaging the business, and a team member's phone contacts syncing in through WhatsApp Business coexistence. The giveaway was the names: a real sender's record carries whatever their WhatsApp profile says, while the synced ones carried notes a person had typed, things like "previous client" and "lead" appended to the name. Nobody's profile name says that.
Nothing failed. No error, no alert, no broken integration. The automation did exactly what it was configured to do, and what it was configured to do was wrong in a way that only shows up if you go and look.
The cost was not the junk records. It was that genuine enquiries were sitting in the same undifferentiated pile, carrying a label that said they had subscribed to a newsletter, invisible to anything that filtered by source.
The three things worth automating first
If the readiness check gave you a middling score and you want somewhere safer to start, these three tend to pass all four tests in most businesses.
Safe first candidates
What these have in common is not that they are simple. It is that you can tell at a glance whether they worked, which means a failure surfaces in days rather than months.
Build or buy
Buy a platform if your process is one that thousands of businesses run the same way. Invoicing, scheduling, email sequences. You will not beat the products on price or time to launch, and the integrations are already written.
Build when the process encodes something specific to how you operate, when it has to write into systems with awkward APIs, or when the process is the product rather than support for it.
The cost people underestimate is identical in both directions, and it is not the licence or the build. It is the instrumentation: knowing it ran, knowing it was right, knowing when it stopped. Budget for that whichever way you go, because it is the only thing standing between an automation and a liability.
The short version
Pick the process that runs often, whose rules you can write down, whose data you can reach, and whose failure you would notice. Measure it before you touch it. Build the smallest end-to-end version. Put the alarm on before launch and watch it fire once. Then compare.
The step everyone skips is the alarm, and it is the one that decides whether you have automated a process or just stopped watching it.
Key takeaways
- Steps that produce nothing demonstrable, the baseline measurement and the alert, are the first cut under deadline pressure and the only two that make the result provable later.
- Judgment that nobody has written down becomes a model guessing, and without a written rule there is no way to tell when it guessed wrong.
- Build the smallest version that runs one real case end to end against the real system, because the last ten percent of an integration is where the surprises live.
- Outbound contact brings consent, timing and opt-out rules that internal automation does not, so treat it as a separate category.
- Buy when thousands of businesses run the process the same way. Build when it encodes something specific to how you operate or when the process is the product.
- The underestimated cost in both directions is instrumentation, not licences or build time.
Questions people ask about this
Sourced from client conversations, Search Console, and AI-search citation monitoring.
- Replacing the manual steps in a repeatable piece of work with software that performs them inside your existing systems, using rules for the deterministic parts and a model only for the steps that need reading or deciding. A good automation is mostly ordinary integration work: API calls, scheduling, error handling and data mapping.
- The one that runs most often, whose rules you could hand to a new joiner on a written page, whose data sits behind an API, and whose failure you would actually notice. Intake and routing, reconciliation between two systems, and time-based reminders usually pass all four tests, and you can verify each at a glance.
- Score it against frequency, rule clarity, data reachability, cost of an error, whether you have measured it today, whether an alert would fire if it stopped, who owns it after launch, and whether it contacts customers. The readiness check in this article does exactly that and takes about two minutes.
- Because a system that only counts what it receives cannot tell the difference between no work arriving and work arriving then vanishing. Both look like a quiet day. Unless something compares two systems against each other or asserts that output appeared, a broken automation can run for months with every status light green.
- Yes, and it is the step most often skipped. Record one number, such as hours spent, error rate or turnaround time, with the date. Without a before there is nothing to compare the after against, and the project ends up being defended on impressions rather than evidence.
- Traditional automation follows fixed rules and breaks when the input varies. AI automation uses a model for the steps that require reading, classifying or deciding, which handles variation but introduces a new failure mode: it produces a confident answer when it is wrong rather than an error. That is why written rules and detection matter more, not less.
- Expect one workflow in production within a month, chosen because it is easy to verify rather than because it is impressive, with monitoring on it from the day it goes live. A plan promising six automations in the first month will deliver six demos.
- Buy when the process is one thousands of businesses run identically, such as invoicing or scheduling, because you will not beat the products on price or launch time. Build when it encodes something specific to your operation, has to write into systems with awkward APIs, or when the process is the product rather than support for it.
Keep reading
Related articles.
More on the same thread, picked by tag and category, not chronology.
Judging an AI Automation Agency
Half the results for this term are selling automation and the other half are selling a course on how to sell automation. Here is the real work, how it is priced, and the one question that separates a useful firm from a demo.
Samrina Khan
AI Automation for Small Business: Where to Start in 2026
Practical AI automation guide for small businesses. Start with high-impact, low-cost automations that save 10-20 hours per week. No technical team required.
Faizan Ali Khan
AI Automation Mistakes: 10 Costly Errors and How to Avoid Them
Avoid the 10 most common AI automation mistakes that waste budget and stall programs. Practical fixes for each mistake based on real enterprise deployments.
Faizan Ali KhanReady when you are
Want Cubitrek to run AI Automation for you?
We install ai automation programs for growing companies across the US and Europe. Book a call and we'll come back with a one-page plan in 72 hours.