framework · cross business
First-pilot checklist
Scope a first pilot with approved samples, constrained permissions, acceptance tests, a shadow trial, explicit decision rules, and an accountable signoff.
Purpose
Use this checklist to decide whether one bounded workflow is ready for a small pilot and what evidence will determine continue, change, or stop. A pilot is a limited trial with an owner, review, and fallback; it is not permission to expand automatically.
When to use it
Complete it after writing a workflow brief and before using any approved live inputs. Start in synthetic test mode. If permission, ownership, or recovery is missing, record that blocker and prepare the process before a pilot.
Reusable worksheet
Values stay in this page’s memory; refresh clears them. Nothing is submitted or saved automatically. Copy notes into your own document to keep them. Do not enter private records or credentials.
Filled synthetic example
| Field | Example, not an observed trial |
|---|---|
| Workflow | Draft guide-location replies; exclude access changes and sending. |
| Simpler alternative | Compare with a saved reply and manual categorization. |
| Owner | Support owner and backup must be named before running. |
| Samples | Versioned eight-case support pack and approved F01 FAQ. |
| Permissions | Read test messages; write test review queue only. |
| Acceptance | No duplicate effects; no unsupported promises; every draft reviewed. |
| Shadow trial | Proposed one-week observation, capped at 20 approved eligible items; manual process remains authoritative. |
| Fallback | Stop the trigger and return all unresolved items to the manual inbox. |
| Decision rule | Continue only with passed action-boundary tests and manageable review; change scope on recurring ambiguity; stop on unauthorized action. |
| Signoff | Pending: no trial executed and no person has approved this example. |
Instructions
Choose one input and one reviewable output. Attach the brief and test records. Confirm access with the actual owner and inspect account permissions before connecting. Run the normal and difficult cases, record failures, correct them, and rerun.
A shadow trial produces candidate outputs while the established manual process remains authoritative. Prevent both processes from performing the same external action. Record comparable handling and correction time, actual charges, exceptions, and maintenance effort. Limit the trial by both period and workload; do not let an unattended queue grow beyond review capacity.
Interpretation
Continue means the owner accepts the evidence for the stated scope only. Change means a specific revision, owner, and retest are needed. Stop means disable the workflow, reconcile affected items, and use the manual process. Unknown evidence does not count as a pass. Record the actual decision and date when it happens rather than pre-signing the worksheet.
Limitations and sources
This is an original planning checklist, not a validated readiness score or safety certification. The example is synthetic and reports no outcome. Passing a small trial cannot establish universal accuracy.
Related playbook and next step
Apply it to the support triage playbook after preparing the test worksheet. Suggest a correction.
Change notes
Foundation draft prepared October 20, 2026. No public publication or successful live-tool test is claimed.
Next learning step: Triage support emails and draft replies for review