The first hundred days after an acquisition are not filled with decisions that all carry equal weight. Some must happen immediately: who signs for what, which system stays on, who communicates to customers. Another part can wait, and sometimes waiting is the better choice. The question that is often missing is not "what needs to happen" but "what happens if this decision is made two weeks later" — and who watches over that gap in the meantime.
The order of decisions in the first hundred days is often set up like a project schedule: what can run in parallel, what must happen sequentially. That is part of the story. The other part is uncertainty. A decision that is small in itself may still need to be at the front because it keeps five other teams in the dark about what happens as long as it hasn't been made. How you make that distinction is explained at the method for sorting decisions by the cost of uncertainty instead of by scheduling. Without that sorting, a list emerges that feels logical but leaves the most expensive uncertainties at the bottom.
There is an assumption that a Day 100 plan must be complete: everything related to the integration, scheduled somewhere. That assumption is incorrect. Some decisions are better postponed until after day one hundred, because by then information is available that isn't yet, or because whether that part will be merged at all is not even certain yet. What can wait and what the conditions are for monitoring that postponement instead of forgetting it, is described at the overview of what may land after day one hundred and who keeps tracking that. Postponing a decision is a decision; it should have an owner, even if the action itself has not yet taken place.
The question "who watches over that" is just as important as the question of which decisions exist. A list of decisions without an owner per decision is a document, not steering. In most integrations, that monitoring lies with an integration office: a small team or a single person who checks weekly whether the decisions that were due that week have actually been made, and who makes it visible when that is not the case. How such an integration office remains workable — not growing into its own bureaucracy, not fading into a form nobody fills in anymore — is described at the approach for keeping the integration office light and functional.
Decisions in the first hundred days are rarely independent of each other. The decision about which CRM system stays determines when the sales teams can be merged. The decision about the legal structure determines when invoicing can integrate. Part of the delay in integrations does not come from slow decision-making, but from dependencies that were not mapped out in advance. Which dependencies block the rest of the schedule and how you monitor that is described at the way to identify blocking dependencies before they bring the schedule to a halt.
Day one hundred is a milestone, not a guarantee. Plans run late, decisions are made later than foreseen, and the question then is not whether that is a problem, but what the next step is. Rescheduling without derailing the entire process is a separate issue, with its own approach.
Some of the decisions in the first hundred days run through specific people: the one who knows the customer relationship, the one who manages the system, the one whose signature is needed. If that person leaves, is on vacation, or becomes overloaded, the decision stalls without that being visible in the schedule. Who these key people are and how you prevent one absence from stalling the schedule is described at the approach for identifying key people in an acquisition and managing their unavailability.
Every decision within these hundred days should come with a question that is not self-evident: does this part actually need to be merged? Integration sometimes destroys value rather than adding it — merging two systems that both work is not automatically better than letting them exist side by side. That question should be asked for every part, not as an exception but as a standard part of the decision.
This page describes a framework: which decisions carry weight, in what order, and who monitors them. It is not a track record and not a completed project to point to — it is a tool that offers structure to a period that quickly clogs up without structure. The tool that supports this framework, with generators for the synergy baseline, the Day 1 plan, and the Day 100 plan, is under construction. Those who want to use this can sign up for the waiting list.
Part of the hundred days consists of work that is not made up of decisions but of execution: merging reports, transferring data, drafting communications. For that part, a different question is relevant: how much of that work can be taken over by AI. The work scan from FTE TO AI calculates per task which part of the work qualifies for that, giving an indication of where in the integration capacity can be freed up for the decisions that remain human work.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.