Where AI pays off first
Every organization has a list of AI ideas. It lives in a slide deck, or a shared document, or the head of the person who went to the conference. The list is usually long, usually exciting, and usually ordered by whoever spoke most recently.
The first job of an assessment is to turn that list into a sequence. Not a ranking of which ideas are best, but an order of which to build first, given what depends on what. Here is the method we use, stripped to its essentials.
Score every candidate on four things
For each idea on the list, we ask four questions and score each on a simple scale. The scale matters less than the discipline of asking all four every time.
Value: if this worked perfectly, what would change, in units the business already measures? Hours, days of cycle time, error rates, revenue, cost. If nobody can name the unit, the idea is not ready to be scored; it is a feeling.
Effort: how much work to get a first version into production, with the evaluation harness that proves it works? Not to a demo. To production.
Risk: what happens if it is wrong, and how reversible is that? An agent drafting internal summaries and an agent contacting customers are not the same risk, even if they are the same technology.
Dependencies: what has to exist first? Data that is not yet accessible, an integration that is not built, a process that is not yet defined well enough to automate.
The trap each criterion avoids
Scoring on value alone builds the most ambitious idea first, which is usually the one with the most dependencies and the longest path to any evidence. Six months in, nothing is running and the budget conversation gets hard.
Scoring on effort alone builds toys. The easy things are easy because they do not touch anything important, so they ship and nothing changes.
Ignoring risk builds the customer-facing agent before the internal one, and the first bad outcome ends the program.
Ignoring dependencies produces a roadmap that looks great and cannot be executed in order, because item two needs data that item seven was going to make accessible.
Sequence, do not rank
The output is not a leaderboard. It is a sequence with reasons. The first system is chosen for a specific combination: real value, contained risk, few dependencies, and an effort that gets it into production within a quarter. It does not have to be the highest-value idea on the list. It has to be the one that produces evidence fastest while building something the later items need.
Often the first build is infrastructure disguised as a feature: the integration that makes a data source accessible, wrapped in one useful workflow so it delivers value on its own. Item one earns item two.
Write the assumptions down
Every score carries assumptions. The value estimate assumes a certain volume; the effort estimate assumes a certain data quality; the risk score assumes a certain gate design. We write them next to the score. When reality disagrees, and it will, the roadmap can be re-sequenced by checking which assumption broke rather than starting over.
This is also how the roadmap survives a leadership change or a budget cut. A sequence with written reasoning can be defended by someone who was not in the room. A ranking cannot.
The part that is not a method
The four criteria are a tool. The judgment is in the conversations that fill them in: sitting with the people who own the work, watching where time and money actually go, and noticing the process that everyone works around because it is broken. Those are usually not on the idea list at all, and they are frequently where AI pays off first.
So use the method, but do the interviews. The roadmap is only as good as the map.