Most teams don’t struggle to find places where AI could help. They struggle to choose one. Every department has a list, every vendor has a demo, and the first project ends up being whichever idea had the loudest sponsor.
That’s a risky way to start. Your first automation sets expectations for everything after it. If it drags on, or works in a demo but not in daily use, the next proposal gets a much harder hearing. If it delivers a visible result quickly, you earn the trust and budget for more ambitious work.
This guide is a simple way to make that first choice deliberately.
Start from the work, not the technology
Don’t begin with “where can we use a language model?” Begin with “where do our people spend time on work that is repetitive, rules-based, and slow?”
Walk through a normal week with each team and note the tasks that come up again and again:
- Reading incoming emails, forms, or documents and copying details into another system
- Answering the same internal questions about policies, pricing, or process
- Checking documents against a set of rules before passing them on
- Chasing missing information from customers or colleagues
- Drafting routine replies, summaries, or reports from information that already exists
For each task, capture four facts: how often it happens, roughly how long it takes, who owns it today, and where the inputs and outputs live. You’ll use these to score.
Score every candidate on four things
A shortlist of five to ten candidates is plenty. Score each from 1 to 5 on:
1. Value. How much time, cost, or delay would disappear if this worked? Frequency matters more than size: a five-minute task done 400 times a week usually beats a two-hour task done twice a month.
2. Feasibility. Can the task be described clearly enough that a new hire could learn it from a short guide? If experienced staff disagree on the right answer, AI will struggle too.
3. Data readiness. Are the inputs already digital and accessible? Is there a history of past examples to test against? A task fed by scanned faxes in a shared inbox is not impossible, but it is not a first project.
4. Risk. What happens when the system gets it wrong? A slightly awkward draft reply is cheap to fix. An incorrect payment, eligibility decision, or medical instruction is not. Score low-risk tasks higher.
Add the four scores. You aren’t looking for precision; you’re looking for the candidates that are clearly strong on every dimension rather than brilliant on one and weak on the rest.
Watch for the common traps
A few patterns make a candidate look better on paper than it will be in practice:
- No clear owner. If nobody is accountable for the process today, nobody will champion the change or judge whether it worked.
- Hidden judgment calls. Tasks that look mechanical often hide a handful of exceptions that only one senior person knows how to handle. Ask about the last ten tricky cases before you commit.
- Upstream mess. If the real problem is that information arrives incomplete, automating the next step just moves the bottleneck. Sometimes the first fix is a better form, not AI.
- Integration you can’t reach. If the result needs to land in a system with no API and no export, budget for that work or choose another candidate.
Keep a person in the loop at first
The best first projects don’t remove people from the process. They change the job from doing the task to reviewing it.
For example, instead of an assistant that sends replies to customers on its own, start with one that drafts the reply, cites the policy it used, and leaves it for a team member to approve. You still save most of the time, you keep control of quality, and you collect a record of every correction. Those corrections tell you exactly where the system needs work, and they’re the evidence you’ll need later to decide whether any step can run without review.
Define success before you build
Write down, in plain numbers, what “working” means before any development starts. Good first measures are:
- Time per item before and after
- Share of items the system handles without correction
- Turnaround time from request to completion
- Error or rework rate compared with the current process
Agree on a baseline by measuring the current process for a week or two. Without it, you’ll end up debating impressions instead of results.
Make the first scope small
Once you’ve picked a winner, narrow it further. If the task is “process supplier invoices,” the first version might cover one supplier type, one currency, and one approval path. A narrow scope that runs every day teaches you far more than a broad one stuck in testing.
A useful rule of thumb: if you can’t describe the first version’s inputs, outputs, and success measure on one page, it’s still too big.
A quick checklist
Before you commit to a first AI automation, you should be able to answer yes to most of these:
- Does it happen often enough that the time saved will be noticed?
- Is there a named person who owns the process and wants it improved?
- Are the inputs digital, and do you have past examples to test with?
- Is the cost of a mistake low, or can a person review every output?
- Can you reach the systems where results need to go?
- Have you agreed on a baseline and a success measure?
Where to go from here
If you have a list of ideas but no clear favorite, a short assessment is usually the fastest way to decide. We run an AI Readiness & Opportunity Assessment that does exactly this scoring with your team and turns the result into a roadmap. For a quick first read on your own, try the free AI Readiness Check: ten questions, about two minutes.
