A completed Pilot Blueprint, illustrated
This is the form and depth of the day-21 output, worked through end to end on the synthetic accountancy demonstration case. Every value is illustrative. No client data appears on this page.
Nothing here describes a real client, a real engagement or a real result. The workflow is the synthetic quarterly-update case published as a demonstration elsewhere on this site, and the Blueprint below is what its day-21 deliverable would contain. The panel names, fields and decision questions are the published ones; only the values are illustrative.
Evidence & Capacity Case
Synthetic demonstration case — illustrative Pilot Blueprint
- Baseline
- Quarterly-update preparation, from records received to pack ready for qualified review.
- Demand and volume
- Four quarterly peaks a year, with the bulk of cases arriving in the final fortnight of each window.
- Handling and cycle time
- Elapsed time is dominated by waiting for missing records, not by preparation itself.
- Rework and exceptions
- Most repair traces to incomplete or miscategorised source records rather than to preparer error.
- Capacity exposure
- Qualified review is the constrained resource; it absorbs work that does not require qualification.
- Material constraints
- The filing deadline is fixed and cannot absorb slippage; staffing cannot flex within a window.
- Economics
- Unit cost-to-serve is driven by repeat handling, not by the underlying professional judgement.
- Evidence strength
- Evidence-rich: a transaction-level operational log covers the whole window, so the baseline is measured rather than estimated.
Is the problem material enough to justify intervention?
Yes — the avoidable work is concentrated enough, and repeats often enough, to justify a bounded intervention.
Redesigned Workflow
Synthetic demonstration case — illustrative Pilot Blueprint
- Current vs designed
- Chasing moves upstream to a structured request at intake; categorisation exceptions are caught before preparation rather than at review.
- Removed, simplified and standardised activity
- Duplicate re-keying between the intake record and the preparation pack is removed; the completeness check is standardised to one list.
- Human and system actions
- The system assembles and validates; people decide on exceptions and on anything requiring professional judgement.
- Hand-offs
- Two hand-offs removed. The remaining ones are explicit, with a named owner on each side.
- Exception paths
- One exception route, triaged by cause, with a defined path back into the main flow.
- Retained professional review
- Unchanged in substance. Review receives a complete pack and reviews it, rather than completing it.
What should the operation look like?
A workflow where completeness is enforced at intake and qualified review receives complete packs.
Data & Fitness Map
Synthetic demonstration case — illustrative Pilot Blueprint
- Source
- Client-supplied records, the practice management system, and the filing platform.
- Input
- Transaction records, client standing data, prior-period comparatives.
- Purpose
- Completeness checking, categorisation, and preparation of the review pack.
- Completeness and currency
- Standing data is complete but ages between windows; transaction records arrive incomplete and are completed by chasing.
- Processing
- Validation, categorisation, exception flagging, pack assembly.
- Destination
- The review pack, and the filing submission that follows approval.
- Owner and control
- The practice owns standing data; the client owns transaction completeness. That split is the root of most chasing.
- Usable / usable with control / blocker
- Usable with control: the data supports the pilot provided the intake request is structured and completeness is enforced at entry.
Is the information fit enough to proceed, and what must be remediated?
Usable with control. The intake request must be structured before the pilot begins.
Solution Concept & Technical Boundaries
Synthetic demonstration case — illustrative Pilot Blueprint
- Required components
- A structured intake request, a validation and exception-flagging step, and assembly into the existing review pack format.
- Source and target systems
- The practice management system is the system of record throughout; nothing is migrated for the pilot.
- Information flows
- Intake → validation → exception triage → preparation → review → filing.
- Integration points
- Read from practice management; write back categorisation and exception status. No write to the filing platform inside the pilot.
- Automation or AI role where justified
- Assisted categorisation with a confidence threshold, below which the case routes to a person. Nothing files automatically.
- Permission, security and audit considerations
- Role-based access unchanged; every assisted categorisation is logged with its confidence and its reviewer.
- Specialist dependencies
- Integration work against the practice management API, and a categorisation model evaluated against held-out cases.
- Unresolved technical decisions
- Whether categorisation runs at intake or at preparation. Both are viable; the pilot is specified to test intake first.
How could this fit the environment, and what needs specialist validation before build?
Inside the existing system of record, with assisted categorisation behind a confidence threshold. Integration and model evaluation need specialist validation.
Human, Adoption & Control Design
Synthetic demonstration case — illustrative Pilot Blueprint
- Human judgement
- Every professional judgement, every exception with a client consequence, and final review stay with people. The pilot changes what reaches them, not who decides.
- Confidence and exception routes
- Assisted categorisation carries a confidence score. Below the threshold the case routes to a person with the reason shown; above it, the categorisation is still visible and still reversible.
- Approval and sign-off
- Unchanged. The qualified reviewer approves the pack, and nothing is filed without that approval.
- Source verification
- Every assisted output shows the source record it was derived from, so a reviewer can check the basis rather than trust the output.
- Trust points
- Visible confidence, a visible source, and an override that costs nothing and requires no justification.
- Adoption assumptions
- That preparers use the structured intake request under deadline pressure rather than reverting to informal chasing. This is stated as an assumption, not designed around.
- Override and rejection behaviour
- Any user may override or reject any assisted output. Overrides are logged and reviewed for pattern — to improve the design, never to challenge the user.
- Control ownership
- The confidence threshold, exception triage and review sign-off each have one named owner, agreed before the pilot starts.
What stays human, how will people trust and use it, and where are the controls?
Judgement, exception handling and final review stay human. Trust rests on visible confidence, a visible source and a costless override. Controls are the threshold, exception triage and sign-off, each with one named owner.
Pilot Specification
Synthetic demonstration case — illustrative Pilot Blueprint
- Thin-slice scope
- One office, one quarterly window, the quarterly-update workflow only. No second workflow and no second office inside the pilot.
- Hypothesis
- That enforcing completeness at intake removes most downstream repair, and that qualified review time falls because packs arrive complete.
- Test population
- The cases arriving in that office during one full quarterly window, so the pilot sees a peak rather than a quiet period.
- Baseline
- The measured baseline from Stage 1, on the same basis, so the comparison is like for like rather than against an impression.
- Operational, quality, adoption, control and economic measures
- Turnaround and queue time; first-time-right and exception rate; intake-request usage and override rate; threshold and sign-off adherence; unit cost-to-serve on the stated basis.
- Key requirements
- A structured intake request, validation with exception flagging, assisted categorisation behind a confidence threshold, and assembly into the existing pack format.
- Dependencies
- Integration against the practice management API, a categorisation model evaluated on held-out cases, and data-access approval before any build begins.
- Pass / change / stop thresholds
- Agreed before the pilot starts and written into this Blueprint, so the close-of-window decision is read off evidence rather than argued.
- Mobilisation work packages and ownership
- Intake redesign, integration, model evaluation and measurement — each with a named owner and a stated acceptance criterion.
Are we ready to approve and mobilise the pilot?
Ready to approve and mobilise, scoped to one office and one quarterly window, with pass / change / stop thresholds agreed before it starts.
One engagement, two stages, one decision between them
21 working days to a Pilot Blueprint
- Stage 1 · Working days 1–10Establish, then Diagnose & Select
- Stage 2 · Working days 11–21Design, then Specify & Challenge
Stage 1 runs working days 1–10 and ends in a decision. If the evidence doesn't justify continuing, the engagement ends there: you keep the evidence and pay only for Stage 1. If it does, Stage 2 takes the selected intervention to a Pilot Blueprint by working day 21.
£7,500 to start. Stage 2 (£9,500) only if the evidence justifies it.
£17,000 — Total if both stages run, for one bounded workflow. Larger scopes are quoted.