Start from a measurable bottleneck, not an AI idea
Most first-workflow selections go wrong before anyone compares options, because the question is "where could we use AI?" instead of "where does work measurably leak value?" The first question produces a wishlist; the second produces candidates. Walk the actual process end to end and mark four things on its steps: lost time, repeated work, decision delay, and error cost. If none of the four shows up, there is no bottleneck—only curiosity.
Then turn each mark into a number, even a rough one. "Invoice matching is painful" is a complaint. "Three people spend roughly two hours a day reconciling exceptions, and one missed mismatch costs a week of downstream correction" is a candidate. Precision matters less than the attempt: a bottleneck that resists quantification after an honest effort is not ready to be your first AI workflow. It is ready for more observation.
The decision rule is simple: no baseline, no build. If you cannot state today's numbers, you will not be able to prove next quarter's improvement, and the pilot review becomes an argument about impressions rather than evidence.
Feasibility is more than data quality
Most feasibility checks start and end with "do we have the data?" Necessary, not sufficient. Three further questions decide whether a technically possible idea is organizationally buildable: how many systems the workflow touches, since every integration is an engineering dependency and a permission negotiation; how sensitive the data is, since masking, pseudonymization, and access boundaries consume real design time; and whether the process has a single accountable owner who can approve changing how the work is done.
The owner question deserves the most weight. A workflow spanning three departments with no single owner can be technically trivial and organizationally impossible: every design choice becomes a committee, every exception an escalation. For a first workflow, prefer one owner, one contained user group, and a reversible action set—if the output is wrong, a human should catch and undo it cheaply. Add user motivation too: a modest tool for a team that wanted it beats a strong tool forced on a team that did not.
Treat this as checklist logic, not a veto system: data condition, integration count, sensitivity level, a named process owner, motivated users, a cheap undo. A "no" on any line is not disqualification. It is a cost to price in before comparing candidates.
Read the impact-feasibility quadrant honestly
Once candidates exist, plot them on two axes. Impact combines time recovered, error cost avoided, and decision speed gained. Feasibility combines data readiness, integration count, sensitivity, and ownership. This is the logic a structured assessment makes explicit, and each quadrant carries its own decision rule.
High impact, high feasibility: your first-workflow candidates live here, usually two or three. High impact, low feasibility: roadmap material—do not start here, but start the prerequisite work on data access and integrations now, because those lead times are long. Low impact, high feasibility: the tempting quick win; use at most one as a warm-up, because a string of trivial automations teaches the organization that AI is a toy. Low impact, low feasibility: close the file without guilt.
The quadrant has one classic failure mode: inflating impact to rescue a favorite idea. The guard is procedural, not moral. Let the person who owns the process metrics score impact, and let the people who own the systems score feasibility. When one person scores both axes, the matrix stops being an instrument and becomes decoration.
Why the loudest idea is usually the wrong first pick
Every organization has one high-visibility AI idea—often a customer-facing chatbot, or something a senior sponsor saw at a conference. It tends to top the list through a mechanism worth naming: ideas that are easy to imagine get discussed more, discussion builds familiarity, and familiarity quietly reads as feasibility. None of that changes the workflow's actual integration count, data sensitivity, or error tolerance.
A second mechanism stacks on top. Visible ideas are usually customer-facing, and customer-facing workflows carry the harshest failure economics: errors are public, tolerance is minimal, data is sensitive, rollback is expensive. That is precisely the wrong risk profile for a first attempt, while the team is still learning to evaluate outputs, design human approval, and run an exception path.
The productive response is not to kill the loud idea but to score it. Put it through the same quadrant as everything else. If it genuinely wins, build it. If it does not, the sponsor sees exactly why—in integrations, ownership, and error cost rather than opinion—and the idea often returns as a strong second or third workflow once the organization has practiced on a safer one.
Between close candidates, choose for learning capacity
Two candidates with similar scores are not equal, because the first workflow has a double job: deliver measurable value and teach the organization how to operate AI in production. Prefer the candidate that surfaces critical assumptions fastest—whether users trust the output, where human approval belongs, how often the exception path fires—in weeks rather than quarters.
Consider a hypothetical retail chain weighing two options with similar scores: automating the triage of supplier emails, or automating price-change proposals. Triage touches one inbox and one team, and a wrong classification costs minutes. Price proposals touch the ERP, a finance approval chain, and margin risk. Both teach the same core lessons—output evaluation, approval design, exception handling—but triage teaches them at a fraction of the blast radius. That asymmetry is the tiebreaker.
A good first workflow also leaves something behind: a document pipeline, a retrieval layer, an approval surface the next workflows inherit. Ask of every close candidate: if this succeeds, what does the second workflow get for free?
The first workflow is a portfolio decision
Choosing the first workflow feels like a single decision. It is actually the opening move of a portfolio. Map more than you build: a shortlist of eight or ten scored workflows with one in development is a roadmap; one idea built in isolation is a bet. The unbuilt candidates are not rejects—they are the queue, ordered by what the first build will make cheaper.
That is the compounding logic. Workflow one produces patterns: data access agreements, an approval design, evaluation habits, integration scaffolding. Workflow two inherits them and ships faster; workflow three faster still. It is why a sound method runs Map → Prioritize → Prove → Build → Embed → Compound—the last step only exists if the first workflow was chosen with successors in mind.
The concrete next step: list candidates across departments, attach rough numbers to their friction, score impact and feasibility with different owners per axis, and pick the workflow with a single process owner, recoverable errors, and a reusable core. Then write down what the second workflow will inherit—before building the first. Saying "not yet" to nine ideas is what makes the first yes count.