Starting with a tool makes it hard to judge whether the purchase changed anything. Start with the business instead: find one frequent, costly and low-risk process, record how it works now and define what a useful test would show.
This guide is the wide view: how to stand back, see the whole thing, and pick a first move you will actually finish.
Do not try to do everything
Deciding to “do AI” across the business is not a testable plan. It creates too many moving parts to tell which change helped and which created more work.
A testable sequence does the opposite: pick one job, run a controlled trial, include review and correction time, then decide whether to continue.
So the whole game is choosing that first job well.
Step 1: Walk the work, not the software
Before you look at a single tool, look at your week. Grab a piece of paper and write down where your hours and your money actually go. Not the exciting parts. The repetitive ones.
Common candidates include:
- Chasing quotes, invoices and payments
- Answering the same handful of enquiries over and over
- Typing up notes, follow-ups and updates after every job or call
- Booking people in, and the back-and-forth to find a slot
- Re-keying the same information between your inbox, your calendar and your spreadsheet
Write down each one, roughly how long it eats per week, and how much it bothers you. You are building a shortlist from your own business. That list is worth more than any “top ten AI tools” article.
Step 2: Write a five-fact bottleneck brief
For each candidate, write one page with five facts. This is the brief AGMM uses before talking about software.
- Boundary. What starts the process, and what observable result means it is finished?
- Volume. How often does it happen, and how long does a normal run actually take?
- Handoffs. Who touches it, what information moves, and where is it retyped or chased?
- Exceptions. What percentage follows the normal path, and which cases need judgement?
- Consequence. What does delay, rework or a mistake cost when it happens?
Use records where you have them. Where you do not, label the number as an estimate and measure it during the test. A brief that says “we do not know yet” is more useful than a precise number nobody can defend.
Step 3: Rank the candidates by cost and controllability
Now weigh them. For each job on your list, ask two blunt questions.
How much does this cost me? Time it takes, times how often you do it, times what your hour is worth. A ten-minute job you do forty times a week is a bigger prize than a two-hour job you do once a month. Frequency is where the money hides.
How hard is it to fix? Some jobs are a checkbox you already pay for and have never switched on. Others need tools wired together and a bit of thinking. Be honest about the effort.
The job you want first is high on evidenced cost and low on implementation risk. It has a clear owner, mostly repeatable work and exceptions a person can review. Not the cleverest one. Not the one with the best demo. The boring, frequent, controllable process that quietly drains the week.
If you want to put real numbers to a candidate rather than guess, our savings calculator does the sum for you: price the task, work out the saving, and get a clear go or no-go before you spend anything.
What a strong first candidate looks like
Take a recurring quoting task. Write down every step, who supplies the information, where prices come from, what must be checked and how often the job happens. That gives you a real baseline without borrowing anybody else’s results.
Then separate the repeatable work from the judgement. Software can move information, apply approved rates and format a draft. A person still checks the scope and sends the quote. That is the shape you are hunting for: one frequent, expensive, fixable job with a clear owner.
Step 4: Define the smallest useful test
Once you have picked the process, protect the scope. Define one input, one useful output, one owner and one review point. Record the current baseline, the maximum test cost and the date you will decide whether to continue.
Run the test long enough to observe several normal cases and at least some exceptions. Measure the automated run, human review and correction together. If the result clears the rule you set in advance, expand it. If it does not, you have learned something before building around a bad assumption.
That is the whole method. Look wide, define the bottleneck, prove one change, then repeat. Each process you remove from the team’s workload creates the capacity to examine the next.
How this guide was produced
This is AGMM’s working method for early process conversations. It deliberately uses no industry saving percentage or borrowed benchmark. The right baseline is the one measured inside your business, and the right first automation is the one your own test can prove or disprove.
Not sure where your business stands?
If you would like a steer before you pick, our free AI readiness check takes a couple of minutes and shows the handful of things worth sorting first.
If you would rather work through that first move during the live session, bring the job to The AI Bottleneck Blueprint live webinar. See the event page for current booking details.
Before you go, the free resources shelf has a one-page readiness checklist to help you rank your own list. If the constraint needs a system rather than a tool setting, read what business process automation work actually includes.
Questions people ask before they start
Which business process should I automate first?
Start with a process that happens often, has a measurable cost, follows a repeatable path and is safe to test with human review. A boring process with clear inputs and outputs is usually a better first candidate than a clever one with many judgement calls.
Do I need AI to automate a business process?
No. Many valuable automations are simple rules, integrations or purpose-built software. Use AI only where the work genuinely involves interpreting language, images or messy information, and keep a person responsible for exceptions.
How do I know whether a process is ready for automation?
You should be able to name the trigger, inputs, owner, finish point, normal path and common exceptions. If the team cannot agree how the process works today, define it before you automate it.