Key takeaways
- Stabilize customer service, cash-critical routines and access before changing the operating model. Day-one uniformity is not the goal.
- A workstream tracks a change; a workflow runs a recurring job. Integration needs both, with explicit ownership at the handoff between them.
- Learn local variation from real cases and exceptions before deciding what should be shared, codified or left local.
- Standardize definitions and evidence before systems. A common report built from mismatched meanings only hides the disagreement.
- The sequence is adaptable. It does not replace legal, tax, employment, cybersecurity or transaction advice.
Post-acquisition integration needs a layer beneath the workstream plan
Post-merger integration, or PMI, is the adjacent enterprise term. Search results and integration tools commonly organize the job into workstreams, owners, milestones, risks and Day 1, 30, 60 or 100-day plans. That structure matters. It coordinates change across finance, people, systems, customers and operations.
A recurring process has a different clock. “Transfer dispatch” may be a workstream task with an owner and due date. Dispatch itself starts every time a job changes, reads live records, makes routing decisions, handles exceptions and has to finish with a technician and customer in the intended state. Completing the project task does not make that daily work run.
| Layer | Unit | Evidence of progress | Finish condition |
|---|---|---|---|
| Integration workstream | Change initiative or milestone | Owner, status, dependency, decision log | The agreed change has been implemented and accepted |
| Recurring workflow | One business case or run | Trigger, inputs, rules, approval, exception and effect | The intended operational state is verified |
| Handoff between them | Process transfer | Current procedure, authority, test cases and successor owner | The successor can run and repair it without hidden seller dependence |
Use four stages: stabilize, learn, standardize, operationalize
- 01Stabilize essential serviceHuman approvalConfirm who owns customer-critical work, cash-critical routines, access incidents and open exceptions. Freeze avoidable system and process changes until the team can see the existing state. NIST's contingency-planning guidance is narrower and system-focused, but its core discipline applies: define procedures, alternate paths and recovery before disruption.
- 02Learn local work from casesAI judgmentObserve ordinary and imperfect instances. Record triggers, source evidence, local terminology, seller corrections and the point where authority changes hands. Do not mistake the corporate procedure for the branch's actual exception path.
- 03Standardize definitions and evidenceHuman approvalAgree what “completed,” “billable,” “urgent” or “active customer” means before central reports or shared services depend on the term. Preserve an explicit local variant where the work genuinely differs.
- 04Operationalize selected processesCodeTurn stable steps into deterministic execution, keep ambiguous judgment bounded and place permanent human approvals before consequential effects. Monitor the final business state and maintain a recovery route.
Map each workstream to the recurring process beneath it
| Workstream task | Recurring process | Trigger and evidence | Exception owner |
|---|---|---|---|
| Transfer customer service | Support triage and escalation | New request; ticket history, entitlement and policy | Support lead for policy departures |
| Align job reporting | Completed-job evidence review | Job marked complete; notes, photos and change orders | Branch operations lead for missing field evidence |
| Consolidate weekly reporting | Metric reconciliation | Reporting cut-off; definitions, source extracts and prior exceptions | Controller for definition or adjustment disputes |
| Transfer seller responsibilities | Approval and exception routing | Threshold crossed; source packet and authority matrix | Named successor or accountable executive |
The map stops a common failure: moving a task to a new owner without transferring the conditions that make the task executable. Every row needs a real owner read and a live-case test.
Build a first-window plan around evidence, not calendar folklore
There is no single correct 100-day sequence. Deal size, regulated obligations, customer commitments, employee changes and system risk alter the order. Use dates as coordination boundaries, then let consequence and evidence determine what moves first.
| Window | Operating objective | Exit evidence |
|---|---|---|
| Before and at close | Continuity owners, access plan, open commitments and escalation routes | Named owner and fallback for each essential recurring function |
| Early post-close | Observe high-frequency cases and reconcile definitions | Case records, correction log and agreed local variants |
| After the process is understood | Reverse shadow, test exceptions and introduce controlled execution | Successor-run normal and exception cases with verified effects |
| After stable evidence exists | Select shared services, automation or system changes | Versioned procedure, control owner, release test and recovery path |
Four failure modes are visible before the damage is
- Standardize before learning: one new process erases a local control or customer commitment nobody recorded.
- Track without operationalizing: the workstream turns green while daily cases still route through the seller.
- Centralize ambiguous judgment: a shared-service queue receives cases but lacks local authority, context or an exception owner.
- Automate the happy path: normal cases move faster while the exception backlog becomes less visible and harder to reconcile.
Start with the seller handover checklist and the owner-dependency assessment. They create the process-level evidence that a broad integration tracker cannot infer.
Limitations and when not to use this
- This is an operating framework, not a universal post-merger integration plan. Adapt it to the company, transaction and qualified advisers involved.
- It excludes legal, tax, accounting, employment, cybersecurity, regulatory, valuation and transaction guidance.
- The integration map and sequence are simulated. They do not claim a customer outcome or an all-agents connector.
- Do not operationalize a process until its source evidence, authority, exception owner, human gates and recovery path have been reviewed by the accountable owner.
Sources
- Post Merger Integration Checklist — DealRoom Accessed 5 August 2026
- Contingency planning — NIST Computer Security Resource Center Accessed 5 August 2026
- The Great Ownership Transfer: A new era of business stewardship — McKinsey Institute for Economic Mobility Accessed 5 August 2026
Explore post-acquisition operations
Apply the integration sequence to the recurring work that still depends on the seller.
Explore post-acquisition operationsUli 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.