After signing, a period begins in which most irreversible choices are made: which systems merge, who reports where, which customers notice something first. The temptation is to call this an execution period, as if the plan had already been made. Usually it hasn't. The first hundred days are a decision period, and the quality of those decisions matters more than the speed with which they are carried out.
Not every decision belongs in that period. Some matters can wait until more is known; others become more expensive the longer you wait. Distinguishing between the two is itself already a decision, and it is often skipped because everyone would rather get started than first work out what getting started actually means.
The order in which decisions are made is often more important than the decisions themselves. A choice about the customer system made too early, before it is clear which revenue model will remain, can make a later choice impossible. A choice about reporting lines made too late leaves an organization weeks without clarity about who decides on what.
It helps not to order decisions by what feels most urgent, but by what becomes most costly if it remains unclear. Some uncertainties cost little if left open for a few weeks; others cost money or people every day. Anyone looking to sort these can look at how you rank decisions by the cost of uncertainty, because those costs do not track how important a decision looks on paper.
Every decision about integration should be preceded by a question that is often skipped: should this part actually be merged. Combining two sales teams because it sounds logical can disrupt a well-functioning team without the other side gaining anything from it. Merging two IT environments because it looks simpler can produce years of technical debt for a saving that never materializes.
The question of whether something should be merged at all is not an exception you raise in borderline cases. It is the default question for every part, and the answer can just as well be "keep separate" as "integrate." A synergy baseline, a Day 1 plan and a Day 100 plan are instruments for answering that question per part, not for confirming integration as the starting point.
Some decisions block others. A decision about the ERP system can determine whether financial reporting can be merged. A decision about the brand name can determine whether marketing teams can already get started. Anyone who fails to map these blockages discovers them the moment a team gets stuck and no one can say why.
Mapping which dependencies block the rest of the process is therefore not an administrative step afterward, but part of determining the sequence itself. A decision that looks small on paper can be the bottleneck that ten other decisions are waiting on.
The hundred days are a milestone, not a deadline with a penalty attached. Some decisions are not yet ripe after a hundred days, because information is missing or because the first weeks force other priorities. That is not a failure in itself, but it becomes one if no one determines what happens next.
Anyone who wants to know what to do if the Day 100 plan is not met would do well to think through that scenario in advance rather than discover it on day ninety. It is one of the few moments when the integration office must correct itself without this being read as failure.
An integration office that wants to track every dependency, every decision and every synergy in detail gets bogged down in its own administration. The question is not how much there is to track, but how much needs to remain trackable without the tracking itself becoming a project. For those seeking that balance, it is about how you keep the integration office workable, with tracking that serves to support decisions, not to justify itself.
The three generators and the integration office provide structure: a synergy baseline to measure from, a Day 1 plan for the first week, a Day 100 plan for the period after, and a place to keep track of dependencies and the decision list of what to integrate and what not to. They do not replace experience and do not guarantee an outcome. They structure what there is to decide, so that the people making the decisions do so with an overview instead of loose notes from separate meetings.
This tool is under construction. Anyone who wants first access when it becomes available can join the waiting list.
Once it is clear which decisions fall within the first hundred days, the question naturally follows of who takes on the work behind them: who migrates the systems, who merges the reports, who writes the customer communication. Part of that work is repetitive enough to look at differently. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, so that the capacity that remains goes to the decisions that actually need people.
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.