Choose a first workflow that can teach you whether a useful change is possible. The best starting point has a recognizable problem, a responsible owner, accessible evidence, and a bounded way to test the proposed improvement.
The first project does not need the largest theoretical value. It needs enough value to justify learning and enough structure to tell whether it worked. A first pilot that ends in a clear "no" has done its job; one that ends in an argument about what the numbers meant has not.
Different gaps lead to different first moves
- Evidence stated
- Gap stated
- Not stated
| Idea | Clear owner | Defined outcome | Permitted inputs | Baseline | Bounded authority | Review capacity | First move |
|---|---|---|---|---|---|---|---|
| Support drafting assistant | — | — | Approved documentation | — | — | Existing quality reviewer | May be the strongest first test, if eligible volume and maintenance cost support the case |
| Autonomous renewal negotiator | — | Outcome attribution is difficult | — | — | Needs commercial authority | — | Begin with read-only preparation, not autonomous commitments |
| Internal policy search | Needs document ownership | — | Documents conflict | — | — | — | First establish document ownership |
Begin with an observed problem
Ask employees for examples of repeated effort, avoidable errors, delays, or unmet demand. Inspect complete cases rather than collecting broad suggestions such as “use AI for finance.” Identify the input, accepted output, frequency, and consequences of failure.
Then ask whether the problem is interpretation, missing information, unclear authority, a broken integration, or insufficient capacity. A model may help interpret documents; it will not resolve a disagreement about who approves a price.
Those five causes point to different remedies:
| Cause | What it looks like | Remedy to consider first |
|---|---|---|
| Interpretation | Staff read unstructured documents, emails, or tickets to find the facts | Extraction or drafting with review: a plausible AI case |
| Missing information | The answer is not written down anywhere reliable | Documentation, ownership, a knowledge base; AI comes after |
| Unclear authority | Work waits because nobody knows who decides | A decision rule and an owner; no system resolves it |
| Broken integration | People re-key data between systems | Ordinary integration, structured forms, EDI |
| Insufficient capacity | The work is clear but there is too much of it | Process change, staffing, or assistance, depending on the work |
A useful exercise is to take at least ten recent complete cases and mark where time went. If most of it is waiting for an answer that does not exist, a model will draft fluent text around a gap. If most of it is reading and re-keying well-defined documents, assistance may help. The workflow change chapter shows why the step that looks slow may not be the constraint.
Apply gates before comparing opportunities
| Gate | Evidence to bring | If it is missing |
|---|---|---|
| Clear owner | Someone accountable for the workflow and result | Assign responsibility before prototyping |
| Defined outcome | An accepted unit of completed work | Map the process and acceptance criteria |
| Permitted inputs | A usable source set and access basis | Resolve data availability and permissions |
| Baseline | Current effort, quality, and volume | Measure a representative sample |
| Bounded authority | Allowed actions and a rollback path | Narrow the initial scope |
| Review capacity | People able to judge consequential output | Design the review process or defer |
These gates are decision prompts, not a certification or numerical readiness score. Some gaps can be resolved cheaply; others change the feasibility of the project.
What each gate looks like in practice, with the guide's chapters as examples:
Clear owner. A named person who will answer for the result and can change the process. In the support chapter, the support manager owns expansion and the knowledge owner signs off on sources. If nobody can be named, the cheapest fix is a conversation, not a prototype.
Defined outcome. A unit of completed work that two people would score the same way. "A resolved request", not "a generated reply". The order intake chapter defines success as a complete, correct order created once, not as extracted fields.
Permitted inputs. Sources the system may use, with an access basis. The knowledge retrieval chapter treats unlabeled engagement files as a curation gap that blocks the pilot, because guessing a label risks confidential material. Closing this gap can be the most expensive step, so find out early.
Baseline. Current effort, quality, and volume on a representative sample, measured the same way the pilot will be. A short timing study of complete cases may be enough to show whether the opportunity is large; a baseline that excludes follow-ups will flatter any change.
Bounded authority. What the system may do, what it may never do, and how to undo a mistake. The authority chapter describes the arrangements; the order intake chapter shows why an order written twice is a harder problem than a wrong draft.
Review capacity. People who can judge consequential output, with the time to do it. If the only qualified reviewer is already the bottleneck, the human review playbook shows how quickly review load can erase the benefit.
Compare a small shortlist
For each candidate, describe expected value, uncertainty, dependencies, and the cheapest useful experiment. Compare against a simpler change such as a better form, maintained template, clearer documentation, or deterministic integration.
Avoid summing subjective scores into an apparently precise ranking. A candidate with modest value and accessible evidence may be the better first experiment than one with high claimed value but an unknown source of truth. Document that reasoning in words.
A comparison that resists false precision answers the same five questions for each candidate:
- What is the mechanism? Released capacity, avoided errors, faster revenue, less inventory. Name one; see the economics chapter for where each lands.
- What would have to be true? The assumptions the value depends on, such as review staying short, adoption staying high, or sources staying current.
- What blocks it? The gates that are not yet met, and what closing them costs.
- What is the cheapest test? An offline replay of past cases, before any live use, may answer the first question for little cost.
- What is the simpler alternative? A template, a form, an integration, or a documentation fix that might deliver most of the value.
An illustrative shortlist
A software company considers three ideas. A support drafting assistant has repeated questions, approved documentation, and an existing quality reviewer. An autonomous renewal negotiator could affect revenue but needs commercial authority and difficult outcome attribution. An internal policy search tool is easy to prototype but the documents conflict.
The support assistant may be the strongest first test if its eligible volume and maintenance cost support the case. Policy search might first need document ownership. Renewal negotiation might begin with read-only preparation rather than autonomous commitments.
This example illustrates how to choose an experiment; it is not a universal recommendation for software companies.
How the guide's nine workflows compare as first pilots
The workflow chapters were written as fictional cases, but their structure makes them useful for comparison. The table below is editorial judgment about each as a first pilot, using the chapters' own illustrative economics; it is not a ranking of which workflows are worth doing.
| Workflow | What makes it testable | What makes it hard as a first pilot |
|---|---|---|
| Support replies | High volume, documented answers, reversible drafts, an existing reviewer | Thin margin if review stays long: the base case's $3,400 of monthly capacity value after recurring cost turns to −$200 at seven assisted minutes |
| Catalog enrichment | Every value can be checked against a source span; publication is staged | Thin economics: halving adoption takes the $580 base case below break-even |
| Meeting follow-up | Internal, low authority, easy to compare with a human recap | Small labor value ($428 base); the main benefit, fewer dropped actions, is hard to measure |
| Proposals | High value per unit; clear approval points | Low volume makes evaluation slow; scope and price commitments carry commercial risk |
| Order intake | Clear correctness test per order | Writes to an order system: duplicate prevention and exception queues must work first |
| Onboarding guidance | Defined milestones, versioned guides | Needs a reliable entitlement record; negative as cash at 50% realization |
| Knowledge retrieval | Natural fit for retrieval | Confidentiality: access labels and conflict walls must be right before anything is indexed |
| Inventory forecasting | Backtests on history before any live use | Outcomes arrive weeks later; stockout records and lead times must be reliable |
| Incident triage | Read-only, verifiable against telemetry | Low volume: the $433 base case is a weak labor case and every stress case falls below break-even |
Three patterns stand out. Workflows where the system only drafts or proposes, and a person already reviews, are easier first pilots than workflows that write to a system of record. Workflows whose value is mostly quality, such as meeting follow-up and incident triage, need a different kind of evidence than a labor calculation provides. And several workflows have a prerequisite that is not AI at all: labeled files, an entitlement record, stockout history. Those prerequisites may be the better first investment.
State the hypothesis and disconfirming result
A useful hypothesis is specific: “For documented support questions, source-linked drafts will reduce complete handling effort without increasing material errors or repeat contacts.” It names a population, change, benefit, and quality condition.
Also state what would cause you to stop. For example, review may eliminate the expected time gain, documentation may not cover enough cases, or employees may need to repeat the original task to validate each draft. Agreeing on these possibilities in advance reduces pressure to reinterpret every result as success.
A proposed template:
For [population and boundary], the [change] will [effect on a measured outcome] without [quality condition]. We will stop if [disconfirming result]. We will decide by [date], and [named person] decides.
A version for catalog enrichment might read: for new SKUs in one product category, span-linked attribute proposals will halve steward handling time without any unsupported value reaching publication; we will stop if checking spans takes as long as keying, or if any safety attribute is populated without its owner. The numbers in a real hypothesis come from your baseline, not from this guide.
Keep the first system narrow
Choose one team, input channel, product category, or task class. Narrowness makes evidence interpretable. It also limits the number of source owners and integrations needed to keep the pilot operational.
Do not narrow the evaluation until only easy examples remain. Include difficult cases within the chosen boundary and clearly identify cases outside it. A system must recognize when its approved scope does not apply.
Good boundaries are ones the system can check: a product version, a document type, a customer segment, a queue. "Simple questions" is a poor boundary because nobody can tell in advance which questions are simple. The support leaders guide narrows its first category to the current product version and articles with a named owner for that reason.
Budget for the decision, not just the prototype
The pilot needs employee time, representative cases, baseline measurement, expert review, and a person who can decide whether to expand. Include these costs alongside implementation. A prototype without an evaluation budget may produce an attractive demonstration but no usable decision.
The budget lines that get left out: the baseline study; building and scoring the evaluation set; reviewers' time during the pilot; the knowledge or data owner's time fixing sources the pilot exposes; and the time to write the decision memo. The pilot kit provides the charter and memo structure.
At the end, choose among expansion, another bounded test, a simpler alternative, or stopping. Record what was learned and what remains uncertain. A first workflow succeeds as an investment in learning when it reduces uncertainty about a consequential next step, even if the model-based approach is not adopted.
Signs the first choice was wrong
These are things to watch for in the first weeks, presented as warning signs rather than reported patterns. Three are the baseline, review capacity, and owner gates failing in practice after passing on paper; the other two are new:
- The baseline cannot be measured. If nobody can say how long the work takes today or how often it goes wrong, the pilot will not be able to say whether anything changed.
- The source of truth keeps moving. Staff disagree about which document, record, or rule governs, and the pilot spends its time arbitrating.
- Every case becomes an exception. The boundary was drawn around a category that turns out to be mostly edge cases.
- Review takes as long as doing the work. Reviewers repeat the original task to check each output; the human review playbook describes how to design review that does not.
- The owner is not deciding. Results accumulate and no one with authority is prepared to expand, change, or stop.
Each is a reason to pause and reconsider the choice, not to push harder on the model.
When to choose something other than AI
Some of the most useful outcomes of a selection exercise are not AI projects. If the cause analysis points to missing documentation, the documentation is the project. If it points to unclear authority, the project is a decision rule. If structured data already exists, an integration may remove the work entirely. Each of the guide's workflow chapters names a simpler alternative for this reason; treat that alternative as a real candidate on the shortlist, not as a fallback to mention.
Related chapters: workflow change, evidence, authority, pilot design, economics worksheet, operations leaders.