- Readiness has almost nothing to do with which tool you pick. It comes from repeatable processes, reachable data and a specific task worth automating.
- Good first candidates are frequent, similar each time, currently manual, and easy to check.
- Avoid anything where a wrong answer is expensive and hard to spot. Early projects should fail visibly.
- Measure the hours before you start, or you will never be able to prove whether it worked.
I am the one doing the digging round here, so I have opinions. The short version is that the tool matters far less than picking a task worth automating in the first place.
There is a pattern to small businesses that get real value out of AI, and it has very little to do with which product they bought. They had a specific job that happened often, followed roughly the same shape each time, and was eating hours that nobody enjoyed spending.
The businesses that get nothing tend to have done the opposite: bought a subscription because it seemed necessary, and then looked for something to do with it.
This guide is about telling the two apart. The AI readiness scorecard will score your own position in about two minutes.
Readiness is not about tools
Three things decide whether an AI project produces anything, and none of them is the model you use.
Data does not need to be perfect. It needs to be reachable. Messy but digital and searchable is enough to start with. Data that exists only in email threads, filing cabinets or memory is the actual blocker, and no tool solves it.
If you cannot describe the task precisely enough to train a new starter on it, you cannot automate it either.
What makes a good first candidate
Four tests. A task that passes all four is worth trying. A task that fails two or more is worth leaving alone for now.
| Test | Why it matters |
|---|---|
| Frequent | Saving ten minutes on something you do twice a year is not worth the setup. Daily and weekly tasks are where the hours are. |
| Similar each time | Consistent shape means a consistent approach works. Wildly variable tasks need judgement that is hard to specify. |
| Currently manual | If a rule or a template already handles it, that is cheaper and more reliable than AI. Do not reach for a model where an if-then would do. |
| Easy to check | You need to spot a wrong answer immediately. If errors surface three months later inside a spreadsheet, the risk outweighs the saving. |
Use the questions below on a task you have in mind.
Every answer from the questions above, if you would rather read them all at once.
Use the simpler tool
If you answered: Daily or weekly › Yes, broadly the same › Yes, probably
A template, a filter or an automation rule is cheaper, faster, more predictable and easier to fix than anything involving a language model. It also will not occasionally invent something.
Reach for AI when the task genuinely needs to interpret language, summarise unstructured information or produce a draft. Not when an if-then would do.
This is a good first candidate
If you answered: Daily or weekly › Yes, broadly the same › No, it needs judgement or language › Yes, immediately
Frequent, consistent in shape, genuinely needs language or judgement, and errors are visible immediately. That is exactly the profile worth starting with.
Before you build anything, measure how long the task currently takes across two weeks. Without that baseline you will not be able to prove whether it worked, and you will end up arguing about impressions instead of hours.
Not a good first project
If you answered: Daily or weekly › Yes, broadly the same › No, it needs judgement or language › Possibly not for weeks
Errors that surface slowly are the expensive kind. Anything feeding accounts, tax, pricing, safety or compliance belongs in this category, and a confident wrong answer in those areas can cost far more than the automation saves.
Pick something more visible for your first project. Come back to this once you have built the habit of checking output and have a review step you trust.
Start with the part that is consistent
If you answered: Daily or weekly › Every case is different
Highly variable work usually contains a consistent core surrounded by judgement. Drafting a first version, summarising the inputs or pulling the relevant history together is often repeatable even when the final decision is not.
Automate the preparation and keep the judgement with a person. That tends to save more time than trying to automate the whole thing, and it fails safely.
Probably not worth automating yet
If you answered: A few times a year
Infrequent tasks rarely justify the setup, testing and maintenance that automation needs. Even a perfect solution that saves an hour four times a year saves four hours.
Write the process down instead. If it later becomes frequent, you will already have the documentation that any automation would need anyway.
What tends to work, and what does not
- Drafting replies to common questions. High volume, similar shape, and a person checks before sending.
- Summarising long threads or documents into the few things that need action.
- Pulling information out of documents such as invoices, forms and specifications into structured fields.
- First-draft quotes and proposals from a standard structure, for a person to adjust.
- Turning notes into something usable, such as a site visit into a written report.
- Searching across your own material to answer a question, rather than hunting through folders.
- Anything needing current, specific facts the system has no access to, such as live stock or today's prices.
- Final decisions with legal or financial consequence. Use it to prepare, not to decide.
- Publishing without review. The time saved is small and the reputational risk is not.
- Work that is genuinely different every time, where specifying the task takes longer than doing it.
- Replacing a process you never had. If it is chaotic manually, automating it produces faster chaos.
How to run a first project
Measure the baseline
Time the task as it is today, across two weeks if you can. Record how long it takes, how often it happens and who does it. Skip this and you can never prove the result.
Write the process down
What comes in, what decisions get made, what goes out, and what good looks like. This is the specification, and it is useful whether or not you automate anything.
Run it in parallel
Do the task both ways for a fortnight. Compare the output every time. You are looking for where it fails and how badly, not for a success rate.
Decide on the evidence
Compare the hours against the baseline and against what the tool costs. If it is not clearly better, stop. A negative result after five weeks is a good outcome compared with a year of vague dissatisfaction.
Review every output for the first few weeks, then sample. Full automation is something you earn once you know the failure modes, not something you start with.
The policy you need, on one page
Small teams need this more than large ones, not less, because there is rarely anyone reviewing work before it goes out. The realistic risk is not dramatic misuse. It is a confidential detail pasted into the wrong box, or a confident wrong answer sent to a client unchecked.
Your one-page AI policy
0 of 6Six lines is enough. A policy nobody reads protects nobody, and the goal is that the team knows the answer without looking it up.
One task, measured before and after, reviewed by a person, with a decision point five weeks out. That is the whole method. Businesses that try to adopt AI everywhere at once usually end up with several half-used subscriptions and no evidence either way.
