The short answer: Choose the process that happens often, follows rules you could write down, runs on information you already hold, has a clear point where a person checks the result, and does little harm when it goes wrong. Score each candidate against those five tests and start with the one that scores best, which is rarely the one that annoys you most. Keep the first project to a single process.
What is an AI agent? ended with a six-line checklist for choosing a first process. This is the working version: five tests, a scoring sheet you can copy, and the mistakes that make first projects stall. It applies whether the software turns out to be an agent or something simpler.
Start with a list of jobs
Many first projects go wrong at the naming stage. "Automate our admin" isn't a process. "Log each website enquiry and send it to the right person" is.
Ask the people who do the work to write down the jobs they repeat, each as a verb and a thing: match, log, chase, check, draft, summarise. Aim for five to ten, and don't filter yet. You want candidates to compare, because the first idea anyone has is usually the most irritating job in the office, and irritating isn't the same as suitable.
The five tests
1. Volume
How often does it happen? Frequent work gives software more to do. It also gives you plenty of real examples to test against and a quick answer to whether the thing works. A job done four times a year takes a year to prove.
Warning sign: nobody can say how often it happens. Count for a fortnight before going further.
2. Rules you could write down
Could you explain the job to a new starter on a page or two? It doesn't have to be written down today, but it has to be writable. Software can cope with messy material. It can't follow a rule nobody has stated.
Here's a quick way to find out. Give the same awkward case to two experienced people, separately. If they handle it differently, you've found an unwritten rule. Settle it and write it down, which is worth doing whether or not you automate anything.
Warning sign: the honest description of the process is "ask whoever has been here longest".
3. Information you already hold
The material the job runs on has to exist, in digital form, somewhere software can reach it: documents, emails, records, transcripts. If the knowledge lives in someone's head or in a filing cabinet, your first project becomes a data-collection project, and those take longer than anyone expects.
Warning sign: the same information is kept in three places, and they disagree.
4. A clear point where a person checks
Look for the moment where someone already looks at the result before it's used: the manager who reads the quote before it goes out, the bookkeeper who approves the payment run. That's your review point. A process that has one built in is much safer to start with, because the software's work lands in front of someone who knows what good looks like.
The check has to be quick, and it has to belong to a named person. Where a person should stay in the loop covers how to place these points.
Warning sign: the result goes straight to a customer and nobody sees it first.
5. Low cost of a mistake
Assume the software will sometimes be wrong, as people sometimes are, and ask what happens then. Who sees the mistake? Can it be undone? Does it cost money? An internal note with an error in it gets corrected the same morning. A wrong figure sent to a customer is harder to take back.
For a first project, pick work where mistakes stay inside the building.
Warning sign: you can't say what a mistake would cost, because nobody has thought about it.
The scoring sheet
Score each candidate 0, 1 or 2 on each test.
| Test | 0 | 1 | 2 |
|---|---|---|---|
| Volume | A few times a year | Weekly or monthly | Daily, or many times a day |
| Rules | In one person's head | Mostly agreed, exceptions unwritten | Written down, or could be in an afternoon |
| Information | On paper, or in people's heads | Digital, but scattered | Digital, in one place |
| Review point | None: the result goes straight out | Someone checks some of them | Someone already checks every one |
| Cost of a mistake | Reaches a customer, costs money or can't be undone | Awkward, but fixable | Caught internally and fixed quickly |
Then read the pattern as well as the total:
- A 0 on the review point together with a 0 on the cost of a mistake rules a process out as a first project, whatever it scores elsewhere.
- A 0 on rules or on information means there's groundwork to do. That groundwork may be the real first project.
- Mostly 2s with a single 1 is as good as candidates get. Don't wait for a perfect score.
- If two candidates tie, pick the one with a willing owner.
The sheet filled in
Here it is for three jobs that turn up in most small firms. The scores are examples to show the method, not measurements.
| Candidate | Volume | Rules | Information | Review point | Cost of a mistake | Total |
|---|---|---|---|---|---|---|
| Log each website enquiry and send it to the right person | 2 | 2 | 2 | 1 | 2 | 9 |
| Write the monthly report from the job sheets | 1 | 1 | 1 | 2 | 2 | 7 |
| Decide which complaints get a refund | 1 | 0 | 1 | 0 | 0 | 2 |
Logging enquiries is the one to start with. It's unglamorous, it happens all day, the rule fits on a page, and a wrongly routed enquiry gets forwarded by whoever receives it.
The monthly report is a decent second project. Its 1s show where the preparation is: agree what the report should contain, and get the job sheets into one place.
Refunds are the job the owner most wants off their desk, and the worst candidate on the sheet. There's no written rule, every case is a judgement, and a wrong answer goes straight to a customer.
Software can still help with refunds, though. Inside that process sits a smaller job: gather the order, the messages and any earlier complaints for each case, and put them in front of whoever decides. That job would score well. When a process scores badly, look inside it for the reading and gathering, and leave the decision where it is.
Five ways first projects go wrong
- Picking the most painful job. Pain often comes from ambiguity, and ambiguity is what software handles worst. The rules test catches this.
- Picking the most impressive job. The project that would look best in a presentation is seldom the one with the tidy data and the patient reviewer.
- Starting three at once. You learn from the first one how your systems, your data and your people behave. That learning makes the second one cheaper, but only if it comes second.
- No owner. Someone on your team has to answer questions about the process, review the output and say when it's good enough. If nobody will, stop.
- Automating something that should be changed or dropped. If a step exists only because of a system you replaced years ago, remove the step.
What ours have in common
The agents we run at Freestart show the same pattern. TrainingHub's reference library is built from our training material and CallHub call transcripts, which is information we already hold. In ProspectHub, every new prospect is classified on import, and companies that don't fit the campaign are flagged for the team to reassign or exclude, so the review point is part of the design. The first article in this series describes each of them.
Write it on one page
Before you talk to any supplier, including us, put the winning candidate on a single page:
- The process, named as a verb and a thing.
- How often it happens.
- The steps today, in order.
- Where the information lives.
- Who checks the result, and how.
- What a mistake costs.
- Who owns it.
That page makes the first conversation shorter. It's also most of what a supplier needs before they can say anything sensible about cost, which is the subject of the fourth article in this series.