Hand over the process. Not the problems.

A business process handover should make work easier to run, not merely move the same confusion to another team. Before you transfer a queue, a spreadsheet or a customer workflow, decide what the receiving team needs to complete the work without depending on your memory.

Think of the handover as a small operating agreement. It should explain what arrives, what good output looks like, who makes decisions and what happens when the normal steps do not apply. This guide offers a practical way to build that agreement without turning a straightforward process into a documentation project.

The examples below are illustrative. They are not descriptions of a particular Dhiti client, a guaranteed transition timeline or a promise that every process can be transferred in the same way.

Start with the outcome, not the task list

Write one sentence describing the result the business needs. “Enter supplier information” describes activity. “Create supplier records that the purchasing team can use without asking for missing details” describes a useful outcome. The second version gives both teams something concrete to discuss.

Now identify the person who uses that output. Ask them to show you a record they accepted and one they returned. Note the actual difference. A missing tax field may stop the next step entirely, while a different abbreviation may be inconvenient but harmless. Do not give both issues equal treatment simply because both are visible.

Define the boundary too. State whether the new team collects missing information, only flags it, or returns the record to someone else. Avoid phrases such as “manage end to end” unless everyone agrees where that end actually is.

Map what arrives before explaining what happens

List every input the process accepts: a form, an email, an exported file, an attachment or a record in a system. Record the expected format, arrival frequency, source owner and minimum information required to begin. Include the inconvenient channels people actually use, not just the channel described in the official process.

Create an intake check that separates ready work from incomplete work. For example, a request might need a reference number, a readable attachment and an identified requester. If one is missing, specify whether the item stays in an intake queue or moves into active work with a visible blocker.

This distinction matters when you later discuss performance. A team should not appear slow because the information required to start never arrived. Equally, incomplete requests should not disappear from reporting merely because they are difficult to process.

Capture decisions, not every mouse movement

Document the points where a person must choose between actions. When should two similar records be merged? Which source wins if details disagree? When does a customer request require approval? These decisions deserve more attention than a long sequence of screenshots showing obvious buttons.

Use an instruction, a reason and an example for each decision. An instruction might say to preserve the original reference number. The reason might be that another system uses it to match updates. An example should show a valid reference, an invalid reference and the correct response when the field is empty.

Keep screenshots where they genuinely remove ambiguity. Date them or identify the interface version so a later design change does not silently make the procedure misleading. A short document that explains judgement is more useful than a long document that assumes it.

Assign a decision owner and a backup

Give each unresolved question a named role that can answer it. Separate the person who performs the work, the person who checks it and the person who can change the rule. One individual may cover more than one role in a small team, but the responsibilities should still be explicit.

Agree how questions are raised. A shared issue log with a reference number and a clear question is preferable to leaving decisions scattered across private conversations. Include a response expectation that both sides can reasonably meet, and explain what the operator should do while waiting.

Name a backup for absence and leave. A transition is fragile if a single person holds the only working account, remembers every exception or must approve every routine clarification. Test the backup route before the main owner becomes unavailable.

Choose a pilot batch that can reveal weaknesses

Do not select only the easiest items for the first batch. Include routine work, incomplete inputs, near duplicates and a few known exceptions, with appropriate safeguards. The purpose is to learn whether the new team understands the process, not to stage a reassuring demonstration.

The Plan-Do-Check-Act approach described by ASQ includes testing a change on a small scale, reviewing the results and deciding what to do next. Use that logic to keep the handover reversible while you learn.

Agree the acceptance rules before the batch is processed. Decide which errors require correction, which require a pause and who signs off the result. A small pilot with clear evidence is more useful than a large pilot whose outcome is judged by general impressions.

Review rework as information

When an item is returned, record why it needed correction. Distinguish a missed instruction from an unclear instruction, an incomplete input or a newly discovered exception. These are different problems and should lead to different actions.

Suppose a reviewer returns a record because an address was not abbreviated. If the abbreviation rule was never documented, update the rule rather than labelling the operator careless. If the rule was clear but repeatedly overlooked, consider a checklist, interface prompt or targeted practice.

Review the corrected item as well. Closing a comment is not the same as proving the underlying record is now usable. Keep the original version or an appropriate change history so the team can understand what changed without reconstructing the conversation.

Protect access and plan the return route

Share access deliberately. Confirm which systems the receiving team needs, what each person is allowed to do and who removes access when responsibilities change. Avoid giving broad permissions just because they make the first day easier. Your security owner should approve the actual access design.

Write a fallback plan before increasing volume. If quality drops, a system fails or an important rule changes, identify which work pauses and which team takes over. Keep a clear inventory of unfinished items so a rollback does not create duplicate processing.

For a broader starting point, NIST’s small-business cybersecurity resources include guidance intended to help smaller organisations begin managing cybersecurity risk. Treat that as background guidance, not evidence that a handover checklist establishes security compliance.

Use a one-page readiness check

Before the next batch moves, review these questions together:

• Outcome: Can both teams describe an acceptable finished item?
• Inputs: Is there a visible rule for missing or unusable information?
• Decisions: Are common choices and exceptions documented with examples?
• Ownership: Is there a decision owner, reviewer and absence backup?
• Access: Have the required permissions and restrictions been approved?
• Evidence: Can you trace a received item through processing and review?
• Fallback: Can you pause or return the work without losing its status?
• Learning: Have pilot findings changed the operating instructions?

If several answers are uncertain, reduce the scope rather than forcing a full transfer. A narrower handover can still be useful if it creates a dependable operating boundary.

The aim is not to remove every question before work starts. It is to make questions visible, answerable and reusable. Once that foundation is in place, use the 30-day pilot guide to organise the transition and the SOP guide to turn decisions into instructions people can follow.