What an AI Opportunity Assessment should produce

Plenty of consultancies will sell you an AI assessment. Fewer will tell you what you should have in your hands when it ends. That matters, because the word covers everything from a two-hour brainstorm with a slide deck at the end to a real examination of your work, your systems, and your access boundaries.

This article describes what Natural State Logic thinks a paid assessment owes you. Use it to judge ours, or anyone else’s.

Start with what it should not be

An assessment is not a product demonstration. If most of the time is spent showing you what a vendor’s assistant can do, you have watched a sales call.

It is not a strategy retreat. A list of forty ideas ranked by enthusiasm is not a ranking, because nothing in it can be defended after the meeting ends.

And it is not a free discovery session that quietly turns into unpaid consulting. A short conversation to establish fit is useful, and it costs nothing. The assessment starts when someone is paid to look carefully at your actual work.

The inputs a good assessment needs

An assessment can only be as honest as what it examines. Expect the assessor to ask for these, and be suspicious if they do not.

• The people who do the work. Not just the sponsor. The person who re-keys the order, chases the approval, or answers the same question every week knows where the time goes.
• Someone accountable for the result. A workflow without an owner cannot be improved, because nobody can say what better looks like or authorize a change.
• The systems involved, as they are. Which applications hold the information, how it is structured, who can already reach it, and where the current version actually lives. Licensing limits and undocumented workarounds count.
• The rules. Approval thresholds, retention requirements, and anything a regulator or a contract has to say about the data. These decide what an assistant may read and what it may do.
• A safe way to look. Synthetic records or a non-production path when a workflow touches real data. An assessment should never require production access to begin.

Notice what is missing: a tool preference. If the first question is which model you want to use, the assessment has started at the wrong end.

The decisions it has to make

Collecting information is the easy half. The assessment earns its fee by making calls that are uncomfortable to make in a room full of stakeholders.

Which workflows are candidates at all. Each one gets written down as a sequence of real steps and decisions, not as an idea. Some ideas dissolve at this stage, which is a finding, not a failure.

What each candidate is worth. Time returned, errors avoided, service improved. Where a number is available, it should be stated with its source. Where it is not, the assessment should say so rather than invent one. Percentage savings quoted before any measurement are a warning sign.

What each candidate would cost to build and keep working. Integration complexity, how ready the data is, and the ongoing effort to operate the result. A workflow that is cheap to demonstrate and expensive to maintain should be ranked as expensive.

Whether each candidate can meet the security constraints. Least-privilege access, approved data sources, a record of what ran and who authorized it, and a person approving anything with consequences. A candidate that cannot meet those conditions is either reshaped until it can or marked as not viable. It does not get a pass because the demonstration was impressive.

Whether to proceed. This is the decision most assessments avoid. Sometimes the right answer is that no candidate justifies the work yet, or that identity hygiene or information quality has to be fixed first. A paid engagement that can only say yes is not an assessment.

The deliverables you should walk away with

Everything above should be written down in a form you can circulate without the consultant in the room. In practice that means five things.

1. A prioritized opportunity list. Every candidate, ranked, with the value, complexity, and risk reasoning attached to each one. The test is simple: can a leader who was not in the interviews explain to a colleague why item one is above item three? If not, it is a wish list.
2. A recommended first pilot. One workflow. Not three. With success criteria that can be observed in normal work, agreed before anything is built, so that afterwards nobody has to argue about whether it worked.
3. A written roadmap. The sequence, the dependencies between steps, the approvals each step needs, and the constraints each step has to respect. A roadmap that fits on one slide is usually missing the dependencies.
4. Documented findings and unknowns. What was examined, what was assumed, and what could not be confirmed with the access available. The unknowns are the most valuable part, because they are where the next surprise will come from.
5. A recommendation on whether to proceed, and why. Proceed to a pilot, fix a prerequisite first, narrow the scope, or do not proceed. Any of the four is a legitimate outcome. The reasoning should be specific enough that you could disagree with it.

How to tell a roadmap from a slide deck

The two can look similar from across the table. Here is how they differ up close.

A slide deck	A roadmap
Lists ideas	Describes workflows as they run today
Ranks by excitement	Ranks by value, complexity, and risk, with the reasoning shown
Quotes industry savings figures	States what was measured, and what was not
Assumes access will be sorted out	Names which sources, which permissions, and who approves
Ends with “next steps: implementation”	Ends with one pilot, success criteria, and a documented option to stop
Makes sense only with the presenter	Can be handed to someone who was not there

The last row is the one to test. Give the output to a colleague who missed every meeting and ask them what the organization should do next and why. If they can answer, you were given a roadmap.

What happens after

A good assessment does not commit you to anything. You receive the written output, you decide, and nothing proceeds automatically. If a pilot goes ahead, it should be fixed in scope and measured against the criteria the assessment set, which is how the AI Workflow Pilot is run. If it does not, the findings stay useful on their own: they record what was examined and what would have to change for AI work to make sense later.

That is the standard Natural State Logic holds its own AI Opportunity Assessment to. If you are evaluating one from anyone, including us, ask for the five deliverables by name before the engagement starts. The answer will tell you a great deal about what you are buying.