The AI pilot blueprint

The Handover Method is an AI advisory engagement run in phases, aimed at the client team taking over the runbook, the decision log and the deployed AI workflow. Its standing elements are progress reviews during the work and a handover before close.

It is not a perpetual retainer, not a vendor pass-through and not a discovery deck. The shape exists so the work stays focused on one workflow and ends with a team that can keep going without us.

A pilot with a clearly framed question is not a fashion. It is the shortest period that survives leadership's review cycle and the longest that holds the team's attention. A clear question helps a CFO plan the budget and a COO arrange the team's work around the pilot.

Too short and the baseline has no time to stabilise — the result becomes noise dressed as signal. Too long and the cost of the pilot starts to compete with the cost of just fixing the process in-house. The engagement shape must match the cadence of the business that is paying for it.

The most underrated phase of the engagement. What we agree at the start is the reference point for every later measurement. Weakness here is the most common reason pilots ship a result that does not survive a board conversation.

A real baseline has three parts: a KPI read from your operating system (not a vendor dashboard), a measurement protocol agreed with your finance leadership and a shared definition of what 'improved' means. Without those three elements, the result is hard to defend later in a board conversation.

Discovery is where most consulting firms invoice without producing anything the client can own. Our version ends with a description of the gap between how the workflow runs today and how it should run. Discovery should lead to a change in the workflow, not be an end in itself.

The output is not a slide deck. It is an annotated workflow diagram, a list of the three or four interventions we would actually make and a go/no-go recommendation. If discovery shifted the picture, we discuss it at the progress review, so leadership sees the same story we do.

During the work we hold a progress review where we check the baseline and the direction of the work against what discovery actually showed. If the picture has shifted, we adjust direction, and the decision log captures the call. It is a checkpoint that keeps the plan aligned with the work as it actually runs.

A review like this turns a long project into a sequence of explicit decisions. Without it, the work easily drifts away from what leadership actually needs.

This is the part that looks like delivery. What it actually is: an operating-model change running inside the business, read against the baseline on a regular cadence.

Frequent measurement is non-negotiable. The AI layer is the noisy part of the system — it gets better or worse depending on data drift, operator behavior and seasonality. If we read the KPI once at the end, we have no way to separate model drift from process drift, and no way to explain the curve to the CFO. Multiple cadence snapshots beat one big reveal every time.

The aim of the handover is that by the close of the engagement your team has the runbook, the decision log and the operator playbook. The method does not assume an embedded advisor six months later.

Handover is the part of the method we care about most. It helps avoid a managed-service tail that serves neither side.

In consulting, 'done' usually means 'the invoice is paid'. In our method we look at three criteria: the target KPI was read from the client's operating system by the client's finance team against the agreed baseline; the client's team runs the workflow without the advisor on the call; and the decision log is complete enough that a new operator could read it cold and understand why the workflow is shaped the way it is.

If a criterion is not met, we discuss the next steps with you, and the decision log captures why each criterion took the path it did.

Three pilot failure modes we see across the industry. Baseline theatre — the client team writes a baseline that is easy to beat; the measurement protocol is owned by someone too junior to defend it in a CFO conversation. Prevention: baseline artefacts have to be agreed with finance leadership before the next phase can start.

Demo-to-nothing — the pilot ships an impressive demo but never gets into the operating system. Prevention: at the progress review we decide together on the production path before the back half of the work begins.

Handover-by-handshake — the engagement closes on a phone call and the client 'owns' a Slack channel of context instead of a runbook. Prevention: handover is a planned stage of the work, not a gesture at the end of the last meeting.

A pilot around one workflow is a shape the business can actually carry. Every stage above is designed to lead to a handover, not to keep the advisor in the room. That is The Handover Method.

If you want to see how this maps to your own operating problem, the 30-minute call is the right next step. Bring the workflow, the cost pressure or the stalled initiative. We will map it against the blueprint on the call.

These are the engagement shapes a CFO can pick from when an AI initiative needs to be commercially safe and operationally real. The Handover Method (a pilot with a clearly framed question) is one shape — not the only shape — and it fits a specific window: a workflow with meaningful operating exposure, an outcome the business can verify in a defined window and a team that can absorb a runbook before we leave.

When the answer is none of those, an RFP route or an in-house build are the right calls, and it is worth discussing on the call. The point of naming the shapes is to make the choice readable instead of leaving it to vendor narrative.