Most AI pilots don't fail on technology — they fail on measurement. A team picks a tool, runs it for six weeks against nothing resembling a baseline, and then argues about whether it "feels faster." By day 90 the pilot is either quietly dead or expanding on vibes. There's a better structure: 90 days, three phases, a baseline captured before anything switches on, and go/no-go criteria agreed before anyone falls in love with the demo. This is the framework.
Why 90 Days Is the Right Window
Ninety days is long enough to clear the novelty effect — the first two weeks where everything new feels transformative — and short enough to hold attention before the next priority lands. It splits naturally into three 30-day phases: scope (days 1–30), run (days 31–60), and prove (days 61–90). Each phase has exactly one job and one exit gate. If a phase can't pass its gate, the pilot stops — and that's a success of the process, not a failure of the team.
The other reason for 90 days: B2B work has cycles. Monthly reporting, quarterly reviews, recurring workflows — a 90-day window guarantees you see at least one full cycle of the process you're trying to improve, including the messy edge cases that monthly averages hide.
Phase 1 — Scope and Baseline (Days 1–30)
Days 1–10: pick one task, not one ambition. The right first pilot is a single high-volume, low-risk task with a measurable output: lead-qualification summaries, content tagging, first-draft replies to common support questions, meeting-notes structuring. Not "customer service." Not "marketing." One task a person does repeatedly, whose volume you can count.
If you're not sure where AI fits your stack at all, run the AI diagnostic: where intelligence fits your stack first — it maps candidate tasks by volume, pattern-repeatability and cost of error, which is exactly the filter a pilot needs.
Days 11–20: capture the baseline. Before the pilot touches anything, measure the current state for at least two full weeks:
- Time per unit: how long does the task take a human today, on average and at the 90th percentile?
- Volume: how many units per week?
- Error/quality rate: what fraction needs rework today? (Yes, humans have an error rate too — pilots are judged against it, not against perfection.)
- Cost per unit: fully loaded. A task taking 40 minutes of a £50k salary is not free.
No baseline, no pilot. This is the single most common failure point — without it, day 90 turns into a debate about impressions.
Days 21–30: define success, guardrails and the go/no-go. Write down, before launch:
- Success metrics — pre-agreed, typically: time saved per unit, error rate vs human baseline, and team adoption (% of eligible volume actually routed through the AI).
- Guardrails — what the AI is never allowed to do (send externally, touch customer data without masking, overrule a human) and who owns the rollback switch.
- Go/no-go thresholds — e.g. "go" means ≥30% time saved per unit, error rate no worse than 1.5× human baseline, ≥60% adoption by day 60. Anything else is "no-go" or "reshape and re-run one phase."
Agreeing these while nobody is emotionally invested is cheap. Agreeing them on day 88 is impossible.
Phase 2 — Run the Pilot (Days 31–60)
Ship small, then expand the sample. Week 5: the AI does the task alongside the human, output marked but not used. Week 6: the AI output becomes the first draft the human edits. Weeks 7–8: full run on the scoped task, human spot-checking a fixed sample (10–20% of units, randomly selected).
Measure weekly, not at the end. Track the pre-agreed metrics every week on a single dashboard: time per unit (AI-assisted vs baseline), error rate, rework time, adoption. Weekly measurement catches the two classic mid-pilot failure modes early: scope creep (the task quietly doubling in size) and adoption drift (people routing around the AI because it's slower than the old way).
If the pilot involves an agent rather than a single generation task, keep it deliberately simple — one tool, one job. Every addition mid-run resets your measurement clock.
The build specifics are covered in building your first AI agent: a practical walkthrough; for the pilot itself, resist adding capabilities mid-run.
Design for the human override. The pilot's job is to find where AI output is trustworthy enough to reduce human time — not to eliminate the human. Teams that build review in from day one get honest error data. Teams that don't get surprised on day 89.
Phase 3 — Prove It or Kill It (Days 61–90)
Days 61–75: the measurement freeze. No changes to the task, the tool or the routing. Measure the full four weeks against baseline with the same definitions agreed in phase 1. Freeze means freeze — "we also improved the prompt on day 70" invalidates your comparison.
Days 76–85: the honest ROI calculation. Three numbers:
- Time saved per unit × weekly volume × fully loaded hourly cost = gross weekly saving.
- Rework + review time the AI adds back = the tax. AI drafts that take 25 minutes to fix against a 40-minute manual task save a lot less than the demo suggested.
- Run cost: API/tool spend + any maintenance time.
AI pilot ROI = (gross saving − tax − run cost), annualised, against the cost of the pilot itself. If that's positive on the scoped task, you've earned the right to discuss scaling. If it's not, you've spent 90 days and a small budget finding out cheaply — which is the framework doing its job.
Days 86–90: the go/no-go meeting. Thirty minutes, three outcomes on the table:
- Go: scale to adjacent tasks. The natural next step is upgrading existing automations rather than bolting AI onto new problems — the path is mapped in from automation to intelligence: the upgrade path.
- Reshape: the task was wrong, not the technology. Pick the next candidate task from your diagnostic and re-run phases 1–2 with the same discipline.
- No-go: document why, keep the baseline data, close it. A clean kill protects the next pilot's credibility.
For scaling decisions that touch multiple processes, structure the expansion with the AI agent design canvas (template) — one canvas per agent, so the second pilot inherits the discipline of the first.
What Kills Most AI Pilots (and How the Framework Prevents It)
- No baseline data. Fixed by days 11–20 — measurement before automation.
- Scope creep. Fixed by the phase 2 change freeze and weekly task-size tracking.
- Picking a problem AI isn't good at. Fixed by the diagnostic filter in days 1–10: high-volume, pattern-repeating, low-cost-of-error.
- Measuring vibes instead of numbers. Fixed by pre-agreed metrics and the day 61–75 freeze.
- No permission to kill. Fixed by the go/no-go thresholds signed off before launch — when "no-go" is a legitimate outcome agreed upfront, the pilot can't silently zombie on.
The framework's real deliverable isn't a successful pilot — it's a decision you can defend either way, made on data captured before anyone got attached to the outcome.