Most teams asking whether they are ready for AI are really asking two different questions at once. The first is whether the technology works. The second is whether their own operation is in a state where it could benefit. The first question has largely been answered. The second is where projects actually succeed or stall, and almost nobody assesses it before signing something.
This page is the assessment we run before we build anything. Five checks, in order, applied to one candidate workflow at a time. You can run them yourself in an afternoon.
Readiness is rarely about technology
When an AI project fails inside an otherwise competent business, the cause is usually upstream of the model. Surveys of small and mid-sized businesses consistently put data quality near the top of the obstacle list — somewhere between a quarter and two-fifths of firms report struggling with the data quality that AI depends on, and disconnected tools are the most commonly named technical blocker. That is not a budget problem or a vendor problem. It is a plumbing problem, and it is diagnosable before any money is spent.
Which reframes the readiness question usefully. You are not asking whether AI is good enough. You are asking whether a specific piece of work in your business is described clearly enough, reachable enough, and checkable enough for a system to do it.
The five checks
1. Is the work written down anywhere?
Pick the workflow you have in mind and try to describe it as a sequence of decisions. Not the goal — the decisions. What arrives, what gets looked at, what judgement gets applied, what leaves.
If that description already exists as a procedure, a checklist, or even a long email one person sends to new hires, the workflow is a strong candidate. If it exists only in one person’s head and the honest answer is it depends, you have found something worth doing before automation: write it down. The writing-down frequently delivers value on its own, and it is the input a build needs.
2. Can a system reach the data without a person in the middle?
Trace every input the work depends on and ask how a program would get to it. A database, an API, a folder of files and a mailbox are all reachable. A report somebody exports weekly, a screenshot pasted into a chat, or a figure that lives in a spreadsheet on one laptop are not — not until something changes.
This check is where most optimistic timelines break. It is also the cheapest one to fix, because the fix is usually an integration rather than a rebuild. A concrete example of the shape we look for: an operations team spending the first hour of every morning downloading seventy PDFs from a supplier portal, renaming them, and filing them. The judgement in that hour is almost nil. The data is reachable. That is a five-minute process waiting to happen, and it is a far better first project than anything involving strategy.
3. Is there a right answer to check against?
This is the check most often skipped, and skipping it is what produces systems nobody trusts.
Before building, you need a set of cases where you already know the correct output — last quarter’s invoices with their correct codes, fifty support tickets with their correct routing, a hundred documents with the answer a human gave. Thirty to a hundred examples is usually enough to start.
Without that set, there is no way to tell whether the system is right, and no way to tell whether a change made it better or worse. With it, every claim about accuracy becomes a number you can re-measure. If you cannot assemble such a set for the workflow you have chosen, that is a finding: the work may be too subjective to automate, or it may simply need a narrower definition.
4. Does someone own the outcome?
Not sponsorship — ownership. A named person whose work gets easier or harder depending on whether this succeeds, and who has the standing to change how the work is done once the system exists.
Automations that report to nobody drift. The data shifts, the edge cases accumulate, accuracy quietly declines, and because no one owns the number, no one notices until the output is wrong in a way a customer sees. Decide who that person is before the build, not after.
5. Would anyone notice if it worked?
Quantify the current cost of the work in whatever unit is honest: hours a week, days of delay, error rate, backlog size. Then state what a good result would look like in the same unit.
The point is not the business case, though you will have one. The point is that a workflow with no measurable before has no demonstrable after, and the project ends in argument rather than evidence. If you cannot name the unit, pick a different workflow first.
Reading your own score
Score each check as a clear yes, a fixable no, or a hard no.
- Four or five clear yeses. Build it. This is a scoped first project and you should expect it to work.
- Two or three yeses, the rest fixable. Still a good candidate, but do the fixing as named work with its own timeline rather than folding it invisibly into a build estimate.
- A hard no on check three or check four. Change the workflow, not the plan. No amount of engineering compensates for an unmeasurable output or an unowned one.
So what should you automate first?
Run the five checks across three or four candidate workflows and the answer is usually obvious, because one candidate scores well on all five while the rest have a hard no hiding in them. In practice the first project tends to share three traits.
It is narrow — one job, not a department. “Answer questions about our policy documents” is a project. “Make the back office intelligent” is a budget line with no finish.
It is high-frequency and low-judgement — work that happens daily and follows rules, rather than the quarterly analysis that genuinely needs a person. Frequency is what makes a modest time saving compound into something visible.
And it is verifiable — you can tell whether each output was right without a meeting.
Worth saying plainly: the first project is not supposed to be the most valuable thing you will ever do with AI. It is supposed to be the thing that proves the pipeline, the permissions, the evaluation method and the ownership all hold. The ambitious work goes second, on top of foundations that have been tested.
What this looks like as a piece of work
For a narrowly scoped assistant that answers questions over a defined set of internal documents, published build ranges generally fall somewhere between ten and a hundred thousand dollars depending on data condition, integration count, and how strict the compliance requirements are. That spread is wide because the variables above are what drive it — which is precisely why the assessment comes before the estimate.
Our own sequence is Discover, architect, build and validate, then improve with evidence. These five checks are the Discover step, published. If you run them and the answer is that you are not ready, that is a useful result and it costs you nothing.
Where to start
Take one workflow that annoys someone every day. Write down its decisions. Trace its inputs. Assemble fifty cases with known right answers. Name its owner. State its current cost in hours or errors.
If all five hold, you have your first project and most of its specification. If one does not, you have found the thing worth fixing before anyone writes code — which is the more valuable outcome of the two.
You can see the kinds of work we build once a workflow passes, or bring us a candidate workflow and we will run the checks with you.