In this guide
Start with the live dependenciesMap the access relationshipsUse each system’s controlsKeep evidence and authority intactClose with a truthful checklistA colleague can leave an operation with open cases, pending provider replies and access to several tools. Treating offboarding only as a password change can leave work unowned. Treating it only as a handover can leave obsolete access in place. Record both outcomes through the actual systems.
The example below concerns operational continuity and account access. It does not prescribe employment policy or a universal deadline.
Start with the live dependencies
Identify cases waiting for customer information, provider confirmation or a team action. For each, keep the order reference, confirmed state, next action and new owner. Requests with unknown paid outcomes deserve particular care. A vague note such as recharge pending can lead an incoming colleague to create a second request rather than follow up on the first.
Map the access relationships
Review case tools, work email, shared files, payment evidence, remote-help tools and provider accounts actually used. Include temporary shares and devices where relevant. Business.gov.uk guidance recommends reviewing unused and former-staff access. A non-secret inventory can identify the systems without collecting every password into a widely shared offboarding document.
Use each system’s controls
Disable or remove access through the supported process for that tool. If a shared credential must change, coordinate the authorised update and dependent work. If a colleague holds the only receipt or provider conversation on a personal account, use legitimate transfer or record-preservation options rather than demanding broad access to unrelated personal material.
Keep evidence and authority intact
The incoming owner should know which customer instructions already exist and which changes remain unapproved. A staff transition does not create permission for a new purchase. Preserve the actual approval scope and provider references. If a confirmation arrives after the handover, attach it to the existing case so the team does not reopen a completed action.
Close with a truthful checklist
State what work was reassigned, what access was removed and which item remains pending. Do not mark all access closed because one chat membership changed. Do not mark all cases transferred because a transcript was forwarded. The useful result is an authorised person who can continue each task and a specific account of the relationships that ended.
A pending customer-update commitment should be handed over explicitly, even if no technical action is due. The incoming colleague needs to know what the customer was told and when the next communication is expected. This is separate from the provider’s completion time. Preserve that distinction so a staff transition does not accidentally turn a progress-update promise into a service deadline.
Questions about this guide
Should the incoming colleague repeat a pending provider request?
First check the existing reference and result. A handover should preserve what was submitted and what remains unknown. Repeat or replace an action only through the actual authorised process after understanding the first request’s outcome.