What an AI opportunity assessment covers
What an AI opportunity assessment covers, step by step: the inventory, the scoring, the document you get, and how to tell it from a pitch.
Why the assessment exists
A company that asks about AI usually has a list of ideas already, ordered by how exciting each one is rather than by how much manual work it removes, how many systems it touches, or what happens if it is wrong. The assessment replaces that ordering with one that can be defended to a CFO, before anyone has written code.
It is deliberately bounded: a few weeks of looking carefully, and a document at the end. It is not a transformation program.
Step one: inventory the workflows
The first step is sitting with the people who do the work. Not a workshop; a desk. The team walks through a day: an order arrives, a purchase order goes out, a report is assembled, a customer writes in. For each workflow: who does it, how often, which systems they open, where they type the same thing twice, and what they do when the normal path does not apply.
The exceptions are the valuable part. The normal path is what every vendor shows in a demo. The exception list decides whether an automation is a relief or a new source of cleanup. A week of the team logging their own time in half-hour blocks is the cheapest way to get this honest; the AI readiness checklist describes how.
Step two: inventory the data and systems
In parallel, the assessment maps the systems: the ERP, the storefronts, the shipping platform, the mailbox, the messaging workspace, and the spreadsheets between them. For each: which facts it owns, whether it has an API, whether that API allows writes, and what the export paths carry. Then the fields each candidate would read are checked for whether they are filled in and believed.
This step also records environments: whether a non-production copy of each system exists, how credentials are issued, where secrets are kept. Those answers do not change which ideas are valuable, but they change how much work stands between an idea and a safe deployment.
Step three: build the candidate list
With both inventories in hand, the assessment writes down every candidate, including the ones the company arrived with. Each takes one of four shapes, because shape determines most of the integration and risk: a scheduled automation; a copilot that drafts for a person to review; an agent that acts under approval; or an integration that moves data between systems. One idea often splits into two candidates of different shapes, and the split is where the value becomes clear.
Step four: score each candidate
Every candidate gets three scores, each written as a short argument rather than a bare number, so someone who was not in the room can disagree with it.
Hours of manual work removed per week, from the time log, plus the cost of the errors the manual process produces today: the late reorder, the mis-keyed order, the wrong reply. Not projected revenue.
How many systems it reads, how many it writes to (ideally one), whether an approval queue must be designed, how clean the fields it depends on are, and whether environments and credentials exist. Writes and approvals drive this score far more than reads.
What a wrong output does before anyone notices, and whether it can be undone. A wrong draft a person reads is cheap. A wrong price exported to three storefronts is not. Risk decides whether a candidate ships as a copilot first and an agent later.
Scoring is also where build-or-buy is answered per candidate. Some items are a product to buy and evaluate for a week, and the assessment should say so. The reasoning is in custom AI vs off-the-shelf AI.
Step five: sequence
The ranked list is not the build order. The first project has its own criteria: one write destination, a reversible write, a measurable baseline, a named approver and a named owner. A high-value candidate is still the wrong first project if it touches four systems or nobody can check its output. The first project is chosen to be finished and trusted, because the second inherits that trust.
The automations Butler runs for PPC International (a Brdy Holdings portfolio company, so a business we own) share that shape: purchase planning, end-of-day reports, wholesale shipping and order intake each run on a schedule, write into Odoo only, and go through a person. The pattern is described in AI automation for ERP and ecommerce operations.
Step six: the output document
The assessment ends in a written document, and the document is the product. At minimum it contains:
- The workflow inventory, time log and exception list.
- The systems map: source of truth per fact, API and write capability, export-path coverage.
- The candidate list, each with its shape, three scores and the argument behind each.
- The build-or-buy call per candidate, with the tools worth evaluating named.
- A recommended first project, with its write path, approver, baseline and measurement method.
- The list of things not to do yet, and why.
A document in this form can be handed to any competent engineering team, including one that is not the assessor. That portability is the test.
How to tell an assessment from a pitch
A pitch dressed as an assessment is common, and not always cynical: a vendor who builds one kind of thing will sincerely find it everywhere.
It names things not to do
An assessment that recommends everything has ranked nothing. Look for candidates marked buy, defer or drop.
It measured your business, not the industry
It can say which of your fields are empty and which export paths drop a column, and its value scores come from your time log by a written method. Industry percentages mean nobody looked.
It names the writes
For every candidate, which system it changes and who approves. A pitch talks about what the AI will understand. An assessment talks about what it will write.
It is fixed in scope and portable
It ends on a date with a document you own and could take elsewhere. If it only makes sense as phase one of the assessor's build, it was a proposal.
The people who need to be in the room are the operations lead, the ERP administrator, someone who owns the money, and at least one person who does the manual work daily, because only they know where the exceptions are. Our own version is described on the AI strategy and opportunity assessment page. The guide to custom AI solutions for business covers what happens after the document.
Common questions
How long does an AI opportunity assessment take?
It is fixed-scope work measured in weeks, not quarters. The bounding factor is usually how quickly the team can log a week of their time and provide system access, not the assessor's effort.
Do we need to have an AI idea already?
No. The candidate list is built from the workflow inventory, not a wish list. Ideas the company arrives with are scored alongside everything else, and the top candidate is often something nobody proposed, because it was boring.
What if the assessment finds nothing worth building?
Then the document says so, and says what would have to change first: usually an API, a data field, or an approval nobody owns. An assessment that cannot return that answer is a sales process.
Can we run the assessment ourselves?
The inventory steps, yes, and you should: the readiness checklist is designed for that. Scoring benefits from someone who has built and run these systems, because integration cost and risk are easy to underestimate from outside. Either way, the document is yours at the end.
If you want to talk through whether an assessment is the right first step for your operations, a scoping conversation is where to start.