Key takeaways
- An integration tracker can assign the handover, but recurring work still needs a trigger, inputs, rules, evidence, exception ownership and a finish condition.
- Observe real cases before standardizing. The seller's corrections reveal thresholds and exceptions that an interview or recording will usually miss.
- Stable steps can become deterministic workflow steps; ambiguous judgment stays bounded, and consequential approvals stay with an accountable person.
- A handover is complete only when the successor can run a normal case and an exception while the seller is unavailable, then prove what happened.
The overlap window is short; the operating problem is specific
This page is for an operating partner, portfolio-operations lead, integration lead or new operator who already has an acquired business and a seller departure date. It is not a guide to sourcing, financing, valuing or negotiating an acquisition.
The warning sign is easy to recognize: ordinary work appears delegated, yet a quote, schedule change, supplier problem, service recovery or month-end exception still reaches the seller. The team may have files and meetings. It does not yet have successor-controlled execution.
The market context is real. McKinsey's February 2026 ownership-transfer research estimates that millions of US small and midsize businesses will face ownership transitions by 2035. That does not tell any individual buyer what to acquire. It does make the operating handover a repeatable problem worth treating as its own discipline.
| Artefact | What it proves | What it cannot prove |
|---|---|---|
| Meeting notes or recording | What somebody said | That a successor can find the trigger, choose the rule and finish the case |
| Readable SOP | What the intended process is | That it matches live exceptions or produces the intended effect |
| Controlled workflow plus run evidence | What ran, with which inputs, decision and approval | That leadership, relationships or every novel judgment has been transferred |
Build the operating handover from real work
- 01Inventory what still routes through the sellerHuman approvalList recurring jobs, decisions, relationships and exceptions. Use the owner-dependency assessment to choose a first three rather than documenting everything at once.
- 02Observe normal and imperfect casesTriggerWatch real work from trigger to verified result. Capture the source record, the decision actually made and every correction. Abstract interviews are useful orientation; the exception is where the rule becomes precise.
- 03Write the operational contractHuman approvalFor each job, name the trigger, inputs, output, time expectation, authority, exception destination and evidence of completion. Keep local variants visible instead of forcing a universal recipe.
- 04Separate fixed steps from judgmentAI judgmentStable lookups, calculations and routing can become deterministic code. Ambiguous classification can remain bounded model judgment. Consequential commitments, payments and accountable business decisions keep a human gate.
- 05Run with the successor in controlCodeReverse-shadow the process, reconcile the final effect and test an agreed seller-unavailable window. A successful run includes recoverable evidence, not merely a green task status.
- 06Repair the definition when reality differsHuman approvalTreat a new exception as a proposed change. Review it, version the procedure and retest affected cases before the new path becomes routine.
A Transition Automation Sprint starts with one bounded process
A sensible sprint candidate is frequent enough to observe during the seller overlap, has source evidence the team may use, and ends in an effect that can be checked. It also has a named successor and an accountable owner for decisions that must remain human.
The output should be useful even before automation: a current SOP, a decision table, approval boundaries, an exception queue and a test record. Automation follows only where the evidence supports it. A high-consequence step with unclear authority is a stop condition, not an invitation to let a model decide.
| Question | Good first candidate | Hold or narrow it |
|---|---|---|
| Can we observe several live instances? | Weekly or event-driven work due during the overlap | Annual work or a process that will not occur before departure |
| Can we verify the finish? | A source-system state, acknowledged handoff or reconciled report | A vague sense that the issue was handled |
| Are authority limits explicit? | Named approver, threshold, expiry and escalation | The seller decides case by case with no successor authority |
| Can failure be contained? | Proposal-first updates, reversible fields or an approval before effect | Irreversible external action with no recovery path |
Northline shows the difference between a project task and a running process
Northline is a fictional two-branch service business. The seller reviews completed jobs each afternoon before billing preparation. The project plan says “transfer invoicing process” and names a new controller.
Observation reveals the missing operating layer: job status is only one input. The seller checks technician notes, photographs, approved change orders and a short list of customer-specific billing instructions. Missing evidence returns to the branch; contract ambiguity goes to the controller; invoice approval remains with an accountable person.
The handover artefact is therefore not one task or an autonomous invoice action. It is a trigger, evidence checklist, deterministic readiness rules, a bounded exception packet, approval authority and a reconciled record that the intended downstream state occurred.
Measure successor control, not documentation volume
- Unassisted completion: normal cases completed without the seller, with the correct final state verified.
- Exception ownership: open exceptions with a named owner, response clock and escalation path.
- Correction rate: cases the seller or successor had to change before effect, kept visible as learning evidence.
- Evidence completeness: runs whose inputs, decision, approval and final effect can be reconstructed.
- Seller interrupts: contacts caused by missing authority or knowledge, classified by process rather than celebrated as “quick questions.”
Use the seller handover checklist to track the transfer and the reliability guide to design evaluation, monitoring and recovery after a workflow begins running.
Limitations and when not to use this
- This scope begins after an acquisition decision. It is not legal, tax, financial, employment, cybersecurity, valuation or transaction advice.
- Automation does not remove leadership or relationship risk. Some decisions and commitments should remain with a named accountable person permanently.
- The Northline company, systems and cases are simulated. No customer outcome, connector or system-specific product capability is claimed.
- A Transition Automation Sprint cannot guarantee a seller departure date or a complete knowledge transfer. It should begin only where real work and usable evidence can be observed.
Sources
- The Great Ownership Transfer: A new era of business stewardship — McKinsey Institute for Economic Mobility Accessed 5 August 2026
- 2026 Search Fund Study: Selected Observations — Stanford Graduate School of Business Accessed 5 August 2026
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 5 August 2026
Assess what still depends on the owner
Build an operational dependency profile and choose the first three processes to observe during the overlap window.
Assess what still depends on the ownerUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.