Which business process should AI improve first?

In most companies the choice is not a method, it is a reflex: start with whatever case is most talked about right now, the one someone saw a competitor do or a conference demo. That is a visibility criterion, not a value criterion, and the two rarely line up.

A case is a priority when it holds up across four axes together: how much it is worth if it works, how realistic it is to work with the data and tools you have today, whether the required data exists and is accessible, and whether an internal person is willing to put their name on the result. A case that wins on three of these axes and loses on the fourth is not an acceptable compromise: it is a case that stalls, and stalls late, after consuming weeks.

The right sequence is not "which case excites us most," it is "which case survives all four filters." Change the order of the questions and the outcome changes with it.

That it is these four axes specifically is not an arbitrary convention: they are the same points where projects stall. Gartner, predicting that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, names four causes: poor data quality, inadequate risk controls, escalating costs, and unclear business value. Those are the four criteria on this list, observed from the failure side instead of the choosing side.

Each criterion answers a different question, and has to be assessed separately before being combined. Conflating them is the most common way a reasonable choice quietly turns into a wrong one.

Because the visibility criterion inside a company rewards outward-facing cases, sales and marketing, where the result is easy to put on a slide. MIT NANDA's 2025 report The GenAI Divide, a study of over three hundred enterprise AI initiatives, finds that more than half of generative AI budgets go to sales and marketing tools, while the highest and most measurable return shows up in back-office automation: finance, procurement, internal operations.

This is not an isolated finding. It is the predictable effect of a selection process driven by whoever has to show the result, not by whoever has to measure it. A back-office case rarely makes it into a board demo, but it is the one with cleaner data, an already documented process, and an owner who lives it daily: exactly the three criteria the flashy case usually lacks.

This is not a case for ruling out customer-facing cases on principle. It is a case for not letting a case's visibility substitute for the four-criteria assessment.

A qualitative comparison of three typical cases makes visible why intuition fails so often. None of the three wins across the board: the comparison exists to show where each one loses, not to crown an absolute winner.

An observable output and a metric already defined, written down before anyone touches a tool. The same MIT NANDA report points to the absence of a defined outcome before launch, not model quality, as the most common cause of failure: the project starts from "let's try AI on this" instead of "we want to reduce this specific number, measured this way."

The difference is practical, not philosophical. If the metric does not exist before the project, it gets invented afterward to justify the time spent, and a metric invented after the fact almost always confirms the project worked, regardless of what actually happened.

The second thing that has to exist beforehand is a time limit for the go or stop decision. Without a date, a low-feasibility case keeps absorbing time on the promise it will work "once one last detail is sorted," and that detail never gets sorted.

One to three, not more. Not as an arbitrary rule of method, but because every extra case dilutes the internal owner's attention, and in most organizations that person does this work on top of their own job, not instead of it. Five parallel cases usually move slower overall than two run in sequence.

There is also a learning reason. The first case, whatever it is, teaches things about the company's adoption process (who approves what, where a data request stalls, who needs convincing) that the second case will use to move faster. Starting too many cases at once means paying that learning curve more than once instead of just once.

Pick the one with the shorter verification cycle. A case whose outcome shows up in two weeks, even if it is worth less than one whose outcome shows up in two months, produces the evidence needed to correct course, or to justify the next step to whoever is funding the project, sooner.

It is the same principle applied to the choosing itself rather than to execution: an output observable soon beats a bigger output observable late, because time passing without signals is time a project loses sponsors, not time it matures.

Beyond the speed of the verification cycle, three other signals help break a tie when the four main criteria stay close.