Build, Wait, Never: A Scoping Rubric for AI Use Cases
Most AI scoping failures are not technical. Nobody scored the workflow before building it. Five criteria sort any candidate into build now, wait, or never…
Many AI pilots never reach production, and the autopsies almost always blame the model, the vendor, or the change management. The more common cause is earlier and duller. Nobody scored the workflow before building it. Somebody picked a process that felt automatable, a budget got approved, and the first honest assessment happened after the system was half built. Scoping gets treated as a conversation rather than an instrument, which means it reliably produces the answer the person holding the budget already wanted. The rubric below is five criteria, scored on whatever scale you like, because the scale matters far less than the honesty. What comes out is not a number to defend in a steering committee. It is a verdict, and there are only three. Rule density measures how much of the decision can be written as rules rather than judgment. High rule density favors building, because rules are the thing a system encodes without fatigue and without drift. Nearly everyone overestimates this criterion, and the reason is structural. A process looks rule-bound from the outside, in the standard operating procedure, in the flowchart on the internal wiki. Then you interview the person who actually runs the exceptions and find that the documented rules cover the easy majority and everything else runs on years of pattern recognition nobody ever wrote down. Score rule density from the exception handler's desk, not from the process document. When the two disagree, the exception handler is right. Volume measures how often the workflow runs, and it matters more than teams expect because the cost of automation is mostly fixed. Architecture, data plumbing, escalation logic, and monitoring cost roughly the same whether the process runs ten times a month or ten thousand. A first production AI agent runs $12,500 for a Pilot or $40,000 for an Install, plus a monthly Operate plan, and that number is largely indifferent to your frequency. Frequency alone sets the return. A quarterly process almost never earns the build, regardless of how much everyone hates it. Annoyance is not volume, and the workflows people complain about loudest are frequently the ones they touch least. Error tolerance measures what a wrong answer costs, and more importantly whether a wrong answer can be caught before it does anything. Those are separate questions and the second one is decisive. A workflow with a human review step standing between the output and the consequence can run at a much lower confidence threshold, because a mistake is a rework item instead of an incident. A workflow where the action fires immediately and cannot be pulled back has to clear a far higher bar. When you score this criterion, do not start by asking how accurate the system needs to be. Ask what sits between the system and the damage. If the answer is nothing, the score is low no matter how good the accuracy looks. Data availability measures whether the inputs the system needs exist today, in a form something can read. Not whether they exist in principle, not whether a migration could eventually produce them, but whether they are queryable this week. The most enthusiastic projects die here, and the cruelty of it is that the answer is knowable in an afternoon. One person with database access and a list of the fields the workflow depends on can settle it before a dollar is committed. Teams skip that afternoon because the answer might end the project, which is exactly the reason to spend it. Judgment content measures how much of the work depends on context the organization has never written down. The pricing exception everyone knows and nobody documented. The reason this account gets handled differently. The tacit standard for what good output looks like. High judgment content pushes the score down, but it does not mean the workflow is unautomatable. It means the documentation happens first and the automation happens second. That sequence is the entire difference between a system people trust and a system that produces confident output nobody believes. Judgment content is the criterion most likely to turn a build now into a wait, and the conversion is a gift, not a setback. Build now is the clean case: high rule density, high volume, errors that are reviewable before they land, data that already exists in readable form, and little dependence on undocumented judgment. Workflows that score this way are less common than the average pipeline suggests, but they are not rare, and they are almost always the ones nobody has been eager to work on. When a candidate scores here, the remaining risk is execution risk, which is the kind of risk a competent team can price, plan, and manage. Wait is the verdict that saves the most money and gets stated the least. The workflow is a genuine candidate. Something upstream is missing, and it is nearly always one of two things: judgment that lives only in people's heads, or data that is not accessible in the shape the system needs. The correct response is to go fix the missing precondition, which is real work with its own scope and timeline, and then score the workflow again. The incorrect response, and by a wide margin the more common one, is to build anyway and hope the gap closes during implementation. It does not close. It surfaces at the worst possible moment, usually the week before the system is supposed to go live. Never has two archetypes, and both are worth naming precisely because so few scoping conversations ever reach them. The first is the workflow where an error is both consequential and unreviewable. The action fires, the consequence lands, and no human sees it in between. In that shape no confidence threshold is defensible, because the system will eventually meet a case outside its distribution and nothing exists to catch it. The second is the workflow where the human interaction is the product rather than the overhead, so automating it removes the thing the customer is actually paying for and calls the removal efficiency. Both archetypes describe a shape. A workflow with the wrong shape does not become a good candidate because the budget already exists. The rubric earns its keep on the answers that disappoint someone. Anyone can run a framework that confirms the workflow already chosen. An instrument only has value if it is capable of returning an outcome that ends somebody's project, and the only evidence that it is capable is that it sometimes does. Hold your own process to that standard, and hold any partner to it. Ask what a partner declines to build and on what grounds. The answer tells you whether their scoping step is diagnostic or decorative, and it tells you before the invoice rather than after. The rubric also explains something that sounds like a matter of taste and is actually arithmetic. The unglamorous workflows score highest. Rule density and volume are the two criteria that dominate the total, and rule density plus volume is the precise definition of work that is dull for a human. Nobody is bored by a decision that requires real judgment and happens twice a year. People are bored by rule-governed work they repeat hundreds of times a month. That boredom is a signal, and the rubric reads it as a high score. The scoring belongs at the front of an AI engagement, before architecture and long before code, because the cheapest system is the one that never got built for the wrong workflow. That is what a workflow audit is for. Not to confirm the project somebody already picked, but to sort the candidates, to name the ones that need a documentation or data project first, and to say plainly which ones should not happen at all.