Supplier Service Handover: Let the Receiving Team Run It

A supplier demonstrates a new equipment-booking service. An employee reserves a laptop, the request reaches the service desk, and the confirmation arrives. The delivery manager marks the demonstration complete.

Now change the situation. The confirmation queue stops processing. The service desk can see an error count but cannot inspect the failed request. The supplier's support portal accepts only the account of the engineer who built the integration. The receiving team has a runbook, but its first instruction refers to a menu their role cannot open.

This is a fictional example. It illustrates a question a completion meeting can miss: what can the receiving team actually do when the supplier's demonstrator stops leading the exercise?

An operator-led rehearsal makes that question observable. The supplier remains available, but the receiving team performs the work using its own access and the agreed support arrangements. The following exercise is a proposed working method, not a certification or a substitute for the acceptance terms in a contract.

Move from rehearsal to acceptance

Agree the receiving scope

Name the service boundaries, acceptance criteria, access, support arrangements and current owners.

Prepare safe test conditions and the operating package

Let the receiving operators lead

Use their own accounts and runbook. The supplier observes and records every intervention.

Compare the observed result with the agreed criterion

Can the receiver perform the agreed work?

Keep tested, untested and unmet criteria separate.

No, or the test is incompleteRecord the gap and retained owner

Correct the access, instruction or support arrangement, then retest with the receiving team.

Conditional transfer proposedApprove the limited scope explicitly

Name excluded duties, who retains them, restrictions and the next review. Do not imply full acceptance.

Criteria met and authorized acceptance recorded

Transfer the defined responsibility

Keep the agreed support available. Review enhanced-support exit against evidence and preserve owners for unresolved work.

This is an operator-led rehearsal for the fictional equipment-booking service. It does not replace contractual acceptance, create a right to withhold payment or transfer unagreed duties.

Establish the boundary before testing it

Start with a short description of the service being transferred. In the equipment-booking example, the supplier operates the hosted application. The internal service desk handles employee inquiries. Internal engineering owns the connector to the equipment directory. A separate access owner approves changes to privileged roles.

That boundary determines what an operator should be able to do. Expecting the service desk to repair the supplier's infrastructure would test the wrong responsibility. Expecting it to identify the affected requests and reach the agreed responder may be appropriate.

Record the scope of each decision too. A demonstration can establish that a feature works under its tested conditions. Operational acceptance asks whether the receiving team can support the agreed service. Commercial acceptance follows the organization's contractual process. A program manager coordinates these decisions and exposes missing evidence; the role does not automatically carry every approval right.

APM's handover guidance recommends agreeing information requirements early and writing documentation for the people who will use it. That supports involving the receiving team before the final demonstration. It does not prescribe the specific exercise below. APM handover guidance

Prepare a rehearsal the receiver can perform safely

Choose a representative environment and describe where it differs from production. Use synthetic booking requests. Obtain the required approval for failure simulation, identify who can stop the exercise, and agree a recovery procedure before introducing the fault.

For this scenario, the facilitator pauses a test notification worker. The booking itself remains recorded. The exercise should reveal whether the receiver can distinguish a delayed confirmation from a failed booking. It must not train staff to create another booking whenever an email is missing.

The receiver begins with the same access and support material it is expected to use after transfer. The supplier observes and records help it provides. Coaching is useful during training, but the record should show when it was necessary. A later unassisted attempt can establish whether the gap has been closed.

GOV.UK's service standard calls for testing in a representative environment, appropriate monitoring and a sustainable response to the problems monitoring identifies. These are government-service expectations used here as operational context, not requirements imposed on every private organization. Operate a reliable service

Follow one failed request through the support path

Give the operator a concrete starting point: an employee reports that a booking is visible in the application but its confirmation has not arrived. Do not begin by announcing the failed component.

Arrange the support test with the supplier. Do not simulate a real emergency or page an on-call team without agreement. If after-hours routing matters but has not been exercised, record it as untested rather than inferring coverage from a daytime response.

A screenshot of a green dashboard is insufficient for the entire exercise. It may prove that one view loaded. It does not establish that a responder received an escalation or that the receiver has authority to perform recovery.

Turn each intervention into a specific gap

Suppose the supplier explains that the notification error is visible only in a different console. Capture what happened: the documented navigation was wrong for the receiving role. Assign a correction, then repeat that part of the exercise with the receiver's account.

Avoid recording the finding simply as "training incomplete." That label leaves several possible causes unresolved. The person may need training, the procedure may be wrong, access may be missing, or the task may belong to someone else. Each requires a different response.

These rows are invented teaching examples. They are not findings from a customer engagement or evidence that a particular supplier has failed.

Make any conditional transfer usable

Some gaps may prevent transfer. Others may be manageable within an explicitly limited scope. Use the organization's decision process and the actual agreement; this article does not determine payment rights, remedies or what a particular contract permits.

For each accepted condition, record the affected service, consequence, temporary arrangement, responsible owner, correction date and review trigger. Identify who has authority to accept the condition. An acknowledgement that a defect exists is different from accepting responsibility for operating with it.

In the example, the receiving team might support employee inquiries while the supplier retains responsibility for restarting the notification worker. That can be a deliberate operating arrangement if its coverage, access, escalation and funding are agreed. Calling it "handed over" without describing the retained responsibility would obscure who must respond.

Google's account of SRE onboarding describes progressive transfer and continuing backup from the development team while the receiver takes on production responsibilities. It is one organization's operational model, not evidence that every supplier engagement should adopt Google's structure. Google SRE: onboarding

Decide how support will end before people leave

Give any enhanced support period a review date and an evidence-based exit decision. In this example, the review could examine whether the service desk can handle the agreed request types, the engineering responder has completed the recovery exercise, and unresolved work has accepted owners. Set the criteria for the service rather than borrowing an arbitrary number of support days.

Also check what happens when the supplier relationship changes later. Identify how operating knowledge, required records and continuing support responsibilities can move to a replacement team. The UK Digital, Data and Technology Playbook connects exit planning with the incoming provider's mobilization. Its procurement context limits where its requirements apply, but it is a useful prompt to examine both sides of a transition. DDaT Playbook: exit planning

Keep the final handover record short enough to use during an incident. It should point to tested procedures and current owners, identify what remains untested, and state who still provides help. The receiving team should be able to explain what it accepted and what happens when the service behaves differently from the demonstration.