Choose a workflow
Observe the work, compare candidates and define the measurable outcome.
Gate: worth a prototype?The approach
A pilot is a decision system, not a demonstration.
The purpose of a first pilot is to learn whether a better way of working is valuable, usable and controllable in your organisation.
We make the questions, evidence and decisions visible from the start.
The first 90 days
Four stages. Four honest decisions.
Timing changes with access, integration and risk. The sequence should not: choose, prove, use, decide.
Build working evidence
Create a narrow version and test representative tasks and failure cases.
Gate: worth a live pilot?Trial it with people
Put the workflow in context, collect structured feedback and refine controls.
Gate: usable and supportable?Review the whole result
Compare value, quality, adoption and risk against the agreed baseline.
Gate: adopt, extend or retire?Candidate scorecard
Useful beats impressive.
A first pilot should produce meaningful evidence without asking the organisation to solve its hardest data, integration and governance problems all at once.
01
Value
Is the current friction important enough to change?
Time, quality, capacity, revenue, experience or risk02
Feasibility
Can a narrow version work with today’s tools and constraints?
Task clarity, integrations, volume and exception rate03
Data
Is the necessary information available, usable and appropriate?
Access, quality, sensitivity, currency and rights04
Risk
What happens when the system is wrong or misused?
Impact, reversibility, affected people and human review05
Adoption
Will people change how the work gets done?
Owner, user pull, workflow fit, training and incentivesPrototype acceptance
Decide what “good enough” means before the demo.
A prototype is evaluated against the job it is supposed to do—not whether it can produce an attractive answer once.
ACCEPTANCE SET / v0.2BEFORE PILOT
QualityRequired facts are correct and sourced
CoverageCommon and difficult examples represented
UncertaintyMissing or conflicting evidence is surfaced
ControlMaterial action requires the named approver
RecoveryA failed run can be stopped and completed manually
AdoptionUsers can complete the workflow with the new method
Portable evidence
The engagement leaves a usable decision record.
Workflow and boundary
Purpose, users, inputs, outputs, systems, exclusions and accountable owner.
Data and tools
Approved sources, access, retention, providers, model choices and known limitations.
Evaluation evidence
Representative tasks, expected outcomes, observed failures and acceptance results.
Human decisions
Review points, permitted actions, escalation, override, shutdown and safe manual path.
Working instructions
How users start, check, correct and complete the work—and when not to use the system.
Next decision
Observed value, adoption, issues, operating cost and recommendation.
Ownership
Your team should understand what it is adopting.
We document decisions, specifications, tests and operating instructions in plain, portable formats. Tool and code ownership depends on the engagement and third-party licences, and is agreed before the build.
We avoid unnecessary lock-in. If another team takes over, the handover should be a planned transition rather than a reconstruction exercise.
A practical first conversation
Start with a decision you can reverse.
A good first pilot is narrow enough to test, useful enough to matter and controlled enough to learn safely.
Start with the workflow