After a deal, the assumption is often already in place: what can be combined, should be combined. That assumption costs value in places nobody is watching, because attention goes to the visible components — the systems, the reporting lines, the management. Meanwhile, a team that has just found its rhythm gets merged with a team that works differently, and exactly the reason the deal was attractive disappears.
The question "does this need to be combined" should be asked for every component, not only the ones that stand out. This is not an exception rule for difficult cases. It is the default question, with integrating as one of two possible answers.
A decision list breaks the integration down into separate components — systems, teams, processes, customer relationships, brands — and forces a choice per component: merge, keep separate, or something in between. Without that breakdown, integration becomes a feeling instead of a set of decisions. With the breakdown, it becomes visible which choices rest on assumptions and which rest on a reason.
Per component, it comes down to a few fixed questions. Does merging deliver synergy that outweighs the loss of what currently works? Is there a dependency that forces a single system, or is that a habit carried over from previous integrations? Who bears the risk if it goes wrong, and is that risk greater than the payoff?
There are recognizable patterns where integrating is not the neutral choice, but the costly one.
A sales team that runs on relationships loses strength the moment it is merged with a team that runs on process — the culture clash hits directly the revenue that was supposed to justify the deal. A customer system with its own history and its own integrations often carries more risk in migration than efficiency gain, especially when that gain exists mainly on paper. A brand with its own customer loyalty loses that loyalty when it is absorbed into a larger brand without any customer having asked for it.
The common thread in these cases: the synergy on paper is narrower than the disruption integration causes. What this means concretely for systems is worked out at which systems are better left standing, and the broader question of when this pattern occurs returns at when does integrating destroy value, and how do you recognize it.
Keeping something separate is sometimes read as postponement, as something that still has to happen. That is a misunderstanding. Deliberately keeping something separate is a decision with a reason, just as merging is a decision with a reason. The difference is that the reason for keeping something separate is often documented less, because there is no action attached that needs to be planned.
Precisely for that reason, the reason for "keeping separate" should be recorded just as sharply as the reason for "merging" — otherwise it becomes impossible to revisit later if the situation changes. Where this can be recognized before the decision is made is worked out at what do you deliberately keep separate, and how do you recognize that beforehand.
With a single acquisition, the decision list is fairly fixed: two organizations, one set of choices. With buy-and-build, that changes. Each subsequent acquisition adds components to a platform that has already made choices, and the question becomes not only "merge with the platform or not", but also "according to which pattern, and does this case rightfully deviate from it".
The decision list from the previous acquisition is then a starting point, not a template that automatically applies. What this means for the approach is at what does buy-and-build mean for your integration approach, and how to reuse an earlier plan without blindly repeating it is at how do you reuse an integration plan.
The generators for synergy baseline, Day 1 plan and Day 100 plan, together with the integration office for benefit tracking and dependencies, structure these decisions. They record which component received which choice, which dependency forces that choice, and which synergy stands against it. They do not take over the decision. There is no completed engagement being referenced as proof that this works — it is structure for a choice that has to be made anew for every component, with the possibility that integrating is the wrong outcome. What this means concretely for a specific case is worked out at how do you decide per component whether or not to integrate, and how do you recognize that.
The tool is under construction. Those who want to work with it can sign up for the waiting list.
Once it is settled which component stays separate and which component merges, a follow-up question arises: who carries out the work created by that choice, and how much of it is routine enough to organize differently. When two administrations, two customer service departments or two reporting lines are merged, duplicate work often emerges that can be narrowed down before it is set up permanently. The work scan from FTE TO AI calculates per task which part of that work can be taken over by AI, independent of the question of whether the component itself should integrate — a second look at the same decision list, this time from the perspective of the tasks it creates.
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.