Pilot Use-Case Selection Worksheet As of 2026-05

Score 2–6 candidate use cases across 5 axes → ranked verdict (Strong pilot / Viable / Risky / Not yet) with explicit blockers. Operationalizes Week 0 of the adoption playbook — the playbook names the decision; this worksheet shows the math. Run candidates through anti-use-cases first — that filter kills bad pilots before they get scored. Optional operating-model impact annotation per candidate (collapsed by default) captures the headcount / margin / cycle-time / risk delta behind the value score — annotation only, doesn't move the math.

Candidate use cases

Axis definitions

1. Value-at-stake

How much does it matter if Claude works here. 1 = nice-to-have, no executive interest. 5 = board-visible win / direct P&L lever / strategic priority.

Why it matters: low-value pilots starve in week 8 when budget reviews start.

2. Time-to-signal

How fast you can tell if it worked. 1 = needs 6+ months of usage data. 5 = signal in 2–4 weeks of pilot users.

Why it matters: 90-day arc fails if you can't prove the win by week 8.

3. Data + tool readiness

Are the inputs Claude needs already accessible? 1 = data behind 3 system migrations. 5 = clean APIs / docs / structured data already in place.

Why it matters: pilots that need a data engineering project first aren't pilots — they're full programs.

4. Risk profile (reversibility)

Lower risk = better pilot. 1 = regulated, customer-facing, irreversible (PHI claims, public statements, financial advice). 5 = internal-only, reversible, low blast radius.

Why it matters: the playbook says "don't lead with customer-facing." Pilots are for learning, not for proving you can fly the high wire on day 1.

5. Sponsor + owner clarity

1 = "the AI committee owns it." 5 = named C-level sponsor and named operational owner whose neck is out.

Why it matters: the most common Week 0 mistake is committee ownership. Committees diffuse decisions; pilots need someone whose neck is out.

Optional — Operating-model impact annotation

Each candidate has a collapsed Operating-model impact details block: headcount delta · margin delta · cycle-time delta · risk delta. Annotation only — the inputs don't move the verdict score. They make the value-axis defensible when a CFO asks "you scored value at 5; why?" and they surface in the ranked verdict panel so the impact travels with the score.

Why annotation, not scoring: operating-model impact varies in kind across use cases (headcount-driven vs. margin-driven vs. risk-driven). Folding it into a 1–5 score loses that signal. Free-form annotation keeps the texture; the value-axis stays the math.

Ranked verdicts

Add candidate use cases to see ranked verdicts.

How verdicts are computed

Total score = sum of 5 axes (max 25).

Verdict bands (no blockers):

Strong pilot ≥ 20 — high-leverage, clean inputs, owned. Build first.
Viable 16–19 — workable, with at least one axis to monitor.
Risky 12–15 — needs structural work before piloting.
Not yet < 12 — pick a different use case for the pilot.

Blocker rule: any axis at ≤ 2 downgrades the verdict by one band, even if the total is high. Any axis at 1 forces "Not yet" regardless of total.

Why blockers override the total: a use case scoring 4-4-4-4-1 has the same total as 4-4-3-3-3 but the first one has a fatal axis (e.g., no sponsor). Pilots fail on weakest-link, not on average.

Decision frames (cheat sheet)

Two Strong-pilot use cases? Pick the one with faster time-to-signal. Faster signal = more credibility for the rest of the program.
Strong on 4 axes, axis-1 blocker on Sponsor? Don't fix the use case — fix the sponsor. Re-score after.
All candidates land in Risky? The bottleneck is upstream — usually data-readiness or sponsor clarity. Don't pilot yet; spend 2 weeks on those before scoring again.
One use case is Strong, but customer-facing? Treat with extra care — the playbook recommends internal-facing first. Score Risk Profile honestly; consider a smaller internal-facing pilot adjacent to it.
Tie? Faster time-to-signal wins, then lower risk profile, then higher data readiness. Value-at-stake is the tiebreaker only when the others are even.
Don't pilot more than two use cases at once. Two is for learning rate; three+ is for losing focus. Plan the second pilot for Weeks 9–13 (scale phase).

Why these 5 axes (and not the obvious 10)

Every axis here is a weakest-link dimension — a failure in any one of them sinks the pilot regardless of how strong the others are. Other dimensions (model fit, prompt complexity, UI quality) matter, but they can be iterated during the pilot. These five can't.

Notably absent: budget (assumed; if you don't have one you're not selecting a pilot, you're seeking funding), team availability (collapses into Sponsor + Owner clarity), technical complexity (use cases at this stage are scoped, not built — complexity emerges later), and vendor choice (this worksheet assumes Claude; see build-vs-buy-worksheet.html for that decision).