Where does my data go when I fill this in?

Nothing leaves your browser. Fields are saved to your browser's localStorage on this device so you can close the tab and come back. There is no server, no account, no email required. Use the download button to move a saved plan between devices or to attach it to a team drive. If you clear your browser data, saved plans are cleared with it — download before clearing.

Can I use this worksheet without JavaScript?

Yes. Every field renders in the HTML. JavaScript adds three things: automatic save between sessions, a live progress meter, and a JSON download of what you've filled in. Without JavaScript the worksheet still prints as a complete blank form, and you can fill it in by hand.

What if we don't have all the inputs?

Fill in what you have and mark the rest as 'unknown.' Unknown fields are honest data — they tell you where to spend the next meeting. But there is one exception: if the baseline section is mostly unknown, do not run the pilot yet. Without a baseline, you cannot prove the pilot worked, and the pilot becomes opinion.

How many people should be in the room?

Three, plus the workflow owner. A function leader, an AI engineer or product owner, and a finance or measurement partner. More than five people turns the worksheet into a meeting. Fewer than three risks filling in the workflow map without the skills to assess feasibility or the context to set a real baseline.

How long does it actually take?

Ninety to 120 minutes, in two sessions. The first session covers setup, workflow map, and baseline (about 60 minutes). The second covers success metric, scope boundary, HITL posture, risk screen, and sign-off (about 45–60 minutes). Splitting the sessions matters — the workflow map needs data access, and the sign-off needs a decision-maker who wasn't in the first meeting.

What happens after we fill this in?

The worksheet is complete, so the pilot can start with a fixed start date, a named owner, a baseline, a success metric, and a written decision rule. When the pilot is measured against the baseline at decision time, the go/no-go question has already been answered — the decision becomes whether reality matched what was written, not what to argue about after. The AI ROI Calculator is the next tool in the chain, used to convert the result into a payback estimate.

Tool · Pilot stage

The pilot plan worksheet

One workflow, mapped end to end — data in, transforms, integrations, outputs — with a baseline, a success metric, and a written decision rule. Fill it in with your team in ninety minutes. Save it, print it, or download it. Nothing leaves your browser.

Time: 90–120 min · 2 sessions
In the room: Function lead · AI engineer · finance partner
Requires: One workflow. Not three.
You leave with: One decision-ready pilot plan

How to use this

Session 1 (~60 min): sections 1–3. Bring someone who has access to the workflow's data.
Session 2 (~45–60 min): sections 4–8. Bring the decision-maker who signs the go/no-go.
Fill in what you know. Mark the rest "unknown" — it's data, not failure. Only one section is a hard block: the baseline.
When done: print it or download the JSON. Attach it to the pilot's project page. When the decision date arrives, you don't argue about whether it worked — you check what was written.

Setup

~10 min

The five fields that make every other section work. Two of them are the ones most worksheets skip: a named owner and a named sponsor. Without both, nothing after this page matters.

Workflow name Name the workflow, not the tool. "Drafting first replies to routine tickets" beats "the AI ticket bot."

One-sentence description of what changes The before → after. One sentence. If it takes two, the pilot is too broad.

Workflow owner The one person whose name is on the pilot. Runs it, tunes it, decides with the data.

Owner role

Pilot sponsor The one person who funds it and signs the go/no-go. Executive sponsor.

Sponsor role

Pilot start date

Pilot duration (weeks) Typical: 6–10 weeks. If your plan needs more than 12, split it into two pilots.

Go/no-go decision date The date the sponsor decides scale / retune / stop. Set it now, in writing, before the pilot begins.

Workflow map

~30 min

Four categories, mapped end to end: data in, transforms, integrations, outputs. Getting data in right — both at start and mid-stage — is the gate. If you don't know what enters, you can't instrument what leaves.

Data in (start) What enters the workflow when it starts? Formats, sources, owners, access. Be specific: "customer email (text), ticketing history (CRM API), and the current knowledge base article (KB)" — not "the data."

Data in (mid-stage) What enters partway through? Human inputs (a manager's approval, a SME's note), agent outputs from prior steps, or external signals (a status update, a new email). Mid-stage data is the one teams forget — and the one that breaks reproducibility.

Transforms What changes the data? The steps — extraction, classification, drafting, summarization, escalation decisions. Name the decisions the workflow makes, not the model it uses.

Integrations (in and out) Systems, APIs, people, and approvals that sit at the boundaries. What comes in from where, what goes out to where. Also: which systems must be *changed*, not just read from.

Outputs What leaves the workflow? Data out, finished products, downstream consumers. And what downstream system, team, or decision depends on the output?

Data sources — name the top three and who owns them
Source	Owner	Access notes

Baseline — the pre-pilot state

~20 min

Three metrics that describe how the workflow performs *today*. Without them, you cannot prove the pilot worked — you can only assert it. This is the one section that is a hard block: if the baseline is mostly unknown, do not start the pilot.

Baseline measured on

How confident are you in the baseline?

If not high, what would raise the confidence? Name the actual data you'd need to pull. "Better data" isn't an answer; "handle time from the last 500 tickets in the ticketing system" is.

Three baseline metrics · current state
Metric	Current value	How measured

Success metric and decision rule

~15 min

Write down what "worked" means, and what you will do with each outcome. Written now — before the pilot runs — this is the difference between a decision and a debate. Written after, it's just a rationalization.

Primary success metric One metric. Not a dashboard. The one you'd stake the program on.

Target value The number that means "worked." Not the ceiling — the bar.

How it will be measured Same method as the baseline. If it's different, the comparison is invalid.

Measurement cadence

If we hit target → The action if the target is met. Be specific about the next step: expand to which teams, fund which follow-on.

If we miss target → The action if the target is missed. "Keep trying" isn't a rule.

If we're close but not there Optional but useful: the range where you'd retune and retest, rather than scale or stop. Say how long the retune gets.

Scope boundary

~10 min

Name what's in scope, and — more importantly — what's out. The out-of-scope list is the less popular half and the more important one. It is the discipline that keeps a pilot from silently growing into three pilots and failing all of them.

In scope Both dimensions: what part of the workflow, and which population (team, region, customer segment).

Out of scope The discipline section. Name what you are choosing not to include, and why — even the tempting items.

How scope can change, and who approves The rule for expanding scope mid-pilot. Default: it can't. If you allow it, name the approver and the limit.

Human-in-the-loop posture

~10 min

Fully automated and human-in-the-loop are not attitudes. They're a decision about which errors are recoverable and which are not — and about how much review burden the workflow can bear. Name the posture, and if there's review, name the threshold.

Posture for this pilot

Fully automated — no human review at any stepOnly valid when errors are cheap, reversible, and caught by a downstream check. Automated with human review on exceptionsThe agent runs; a human reviews only flagged or uncertain outputs. Most pilots live here. Human-in-the-loop on every actionThe safest posture. Correct for the first 2 weeks of any high-stakes workflow.

If exceptions: what triggers a flag? Name the trigger, not the concept. "Uncertainty above 0.7" beats "when the model isn't sure."

Named reviewer role

Escalation path Who sees a flagged item next, and in what timeframe.

Risk screen

~10 min

Three risks, ranked by (likelihood × impact). Not a full risk register — just the three things that would actually sink this pilot if they happened. Name the mitigation, not the concern.

Top three risks
Risk	Likelihood	Impact	Mitigation

Who approves the residual risk? Name the person and role. "The team" isn't an approver — one person is.

Sign-off

~5 min

Two names and two dates. If the owner and the sponsor can't both sign, the pilot isn't ready — the worksheet has done its job by surfacing that before you spend the eight weeks.

Workflow owner signed on

Sponsor signed on

Conditions or caveats (optional) Anything the sponsor agreed to conditionally — budget, resourcing, approval-gating.

See a filled-in example (insurance · claim summaries)

This is the case study from the hub's regional insurer case, written up as a completed pilot plan. It shows what "done" looks like — not because it's aspirational, but because it's how a real one reads.

Setup

Workflow: Drafting claim summaries for adjusters at a regional insurer.
Description: Time to first decision drops from 8 minutes to under 5 without reducing decision quality or rework rate.
Owner: Priya Raman · VP Claims Operations
Sponsor: Marcus Solis · COO
Duration: 8 weeks · decision date set

Workflow map

Data in (start): Claim file (PDF), adjuster's intake notes (free text), policy document (PDF), historical decisions for this claim type (from the customer DB).
Data in (mid-stage): Adjuster's category call after the first summary draft; the review checklist status.
Transforms: Extract claim facts → summarize the damages narrative → cross-reference the policy → draft the summary → flag for adjuster review.
Integrations: Claims management system (read); adjuster UI (write draft); audit log (write every draft + edit).
Outputs: Drafted summary (text) delivered to the adjuster; decision-support packet; audit record.

Baseline

Time to first decision: 8 min · median, last 90 days, claims system
Rework rate: 22% · reopened or escalated within 7 days
Adjuster adoption: 71% · weekly active use, top 2 regions

Success metric and decision rule

Primary: Time to first decision · target under 5 min
If hit target: Scale to the remaining regions within 4 weeks; a second claim-type pilot funded from the same envelope.
If miss: Stop within 2 weeks. Do not modify the target. One-page retro of what the workflow map missed goes to the claims ops archive.
If close (5–6 min): One 3-week retune with the adjuster review checklist, then re-measure. If still 5+, apply the stop rule.

Scope boundary

In scope: Auto comprehensive claims only · US East region · 2 adjuster teams · human review on every draft.
Out of scope: Liability decisions · payment authorization · non-auto claims · any CRM data-model change.
Scope change rule: Owner + sponsor in writing, once max, before the pilot's midpoint.

HITL posture

Posture: Human-in-the-loop on every action (first 4 weeks), then automated with exceptions if rework holds under 15%.
Exception trigger: Any citation outside the current policy version · any reference to a prior claim · any gap in the claim file.
Reviewer: Senior adjuster · escalation to team lead within 4 hours.

Risk screen

Hallucinated policy citation: Likelihood: high · impact: high · Mitigation: citation check on every draft, HITL review before final.
Adjuster over-reliance: Likelihood: medium · impact: medium · Mitigation: weekly calibration on 20 sampled drafts; edit-rate tracked per adjuster.
PII handling across systems: Likelihood: low · impact: high · Mitigation: PII redaction at ingestion; data-retention policy signed by risk before start.

Sign-off

Owner: Priya Raman · signed
Sponsor: Marcus Solis · signed, subject to legal review of PII flow (completed before start)

What to do with the finished worksheet

The plan is one artifact in a chain. Here's where it goes next.