Post-Acquisition

An Integration Checklist Tracks Work; It Does Not Make the Work Run

For an integration practitioner with a polished plan and recurring work that still routes through the seller, branch manager or a private spreadsheet.

Uli PrantzBuilds and operates all-agents
Published
Key takeaways

Key takeaways

  • A playbook coordinates finite change. A recurring workflow must handle each new case after the workstream has closed.
  • The failure usually sits at the handoff: task marked complete, but trigger, evidence, authority, exception ownership or verification is missing.
  • Do not discard project tools. Add a process acceptance record beneath material tasks and test it with live normal and imperfect cases.
  • If every acquisition requires hidden local workarounds, the reusable artifact is too abstract. Preserve explicit parameters and branches.
Post-acquisition integration playbooks fail operationally when they stop at assignment and status. The project task may be complete, yet the recurring job beneath it lacks a trigger, usable source evidence, decision authority, exception route or verified finish. Keep the playbook for coordination. Add a process acceptance record and require the successor to run normal, exceptional and recovery cases before closing the handoff.

The project clock ends; the operating clock starts again tomorrow

Both layers are necessary and neither substitutes for the other.
LayerUnit of workUseful statusFinish
Integration playbookMilestone, decision or change taskOwner, due date, dependency, riskDeliverable accepted
Recurring workflowOne customer, report, exception or requestState, evidence, decision, effectBusiness result verified
Process handoffTransfer of the recurring jobProcedure, authority, test cases, successorSuccessor runs and repairs it

DealRoom and Ansarada correctly present workstreams and checklists as ways to organize integration. The missing layer is not an indictment of those tools. It appears when a team interprets “transfer dispatch complete” as proof that tomorrow's dispatch case can run without the seller.

Five gaps hide behind a green task

Inspect the first failed case to identify which contract is absent.
GapSymptomRepair
EventNobody knows a new case has startedObservable trigger and unique business key
EvidenceSuccessor searches messages or asks sellerApproved source map and freshness rule
DecisionProcedure says “use judgment”Criteria, examples, refusal and authority
ExceptionNormal work passes; backlog grows invisiblyClasses, clocks, owners and escalation
VerificationTask ran but final state is unknownDestination check and reconciliation

Add a process acceptance record beneath material workstream tasks

  1. 01Name the recurring jobTrigger
    Use a verb and object with a real event, such as “reconcile Friday branch pack.”
  2. 02Link the current procedure and authorityHuman approval
    Name the effective version, process owner and decisions the successor may make.
  3. 03Attach test casesAI judgment
    Include one normal case, two contrasting exceptions and one recovery case with expected states.
  4. 04Run with the successor in controlHuman approval
    Log every intervention and question. A corrected result can still be a failed transfer.
  5. 05Close on reconciled evidenceCode
    Verify the final record, exception destination and procedure maintenance owner.

The workstream closes before the first imperfect case appears

Simulated playbook handoffSimulated example data

Northline marks “transfer weekly reporting” complete after access, training and a successful Friday pack. The next week, one branch submits a late correction after the cut-off. The successor cannot tell whether to reopen the pack or carry the correction.

The project task had valid completion evidence, but the recurring process lacked an exception rule. The team reopens only the process acceptance record, adds cut-off authority and a correction ledger, then tests both routes. The integration tracker remains the coordination system.

Reuse the skeleton and preserve the variation

  • Common: event envelope, evidence contract, state model, exception record and verification.
  • Parameterized: thresholds, clocks, calendars, source mapping and approval role.
  • Local branch: customer promise, physical condition, jurisdiction-specific duty or relationship judgment.
  • Never hidden: an unknown owner, unsupported connector, private credential or consequential decision without authority.

The workflow mapper is the fastest way to expose whether a green task has an executable path beneath it.

Limitations and when not to use this

  • A playbook remains useful for integration governance and project coordination. This guide does not claim project software is unnecessary.
  • A process acceptance test supports one bounded handoff. It does not certify the company, integration or workflow as complete.
  • Consequential financial, employment, legal, safety or security work still needs qualified review and accountable human decisions.
  • Northline is simulated. No product, connector, transaction or customer outcome is represented.

Sources

  1. M&A Integration PlaybookDealRoom Accessed 9 August 2026
  2. Post-Acquisition Integration ChecklistAnsarada Accessed 9 August 2026
  3. Eliminating ToilGoogle, The Site Reliability Workbook Accessed 9 August 2026

Map the recurring work beneath one task

Turn the project handoff into an explicit process acceptance record.

Map the recurring work beneath one task
About the author

Uli 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.

Bring one process. We will scope it in 30 minutes.

You leave the call knowing whether it is a fit, what can become code and what still needs a person.

Book a discovery call