Problems that surface months after closing are rarely new. They are old decisions finally showing in the numbers. A customer complaint in month four is the result of a handoff that went wrong in month one. A margin gap in month six is the result of a pricing change nobody tracked.
The temptation is to fix each problem as it appears, and congratulate yourself on staying busy. A better practice is to ask what else the problem touches and what caused it. Those questions find the fault. Use the full post-merger integration checklist for the full task list and the 100 day integration plan for the sequence.
Look under the problem
For each issue, ask five questions. What happened? Who is affected, inside and outside? When did it start, not when did we notice? What changed around that time? What else depends on the thing that broke?
Write the answers down in a log that anyone on the integration team can read. The pattern appears when you put several entries side by side.
Common root causes
A key person left or lost authority, and tasks that depended on them fell through. A system cutover dropped a field, a rule, or an approval. A price or term changed and nobody told the account owner. A handoff between sellers and operations lost a promise. A policy was applied to a group it was not designed for.
These causes show up as different symptoms in different departments, so each department sees only a piece. That is why the integration lead has to look across them.
Follow the dependencies
Draw a simple map for each issue: who it touches, which customers, which people, which processes, and which numbers. For example, a departed technician touches the customers he served, the jobs scheduled, the warranty callbacks, the vehicle he drove, and the training of the person replacing him. Fix the technician question without the rest and you have created five new ones.
For the retention of someone who holds the business, turn to the indispensable employee who resists change. For the effect of one account on the whole, see customer concentration after acquisition.
Hold a short weekly review
Once a week, the integration lead and the function leads review the log for twenty minutes. Which issues are new, which are repeated, which have an owner, which need escalation. Look for clusters. Three issues in the same location or the same team are likely one issue.
Close issues only when the cause is fixed, not when the symptom stops. A symptom that returns is the cause telling you it is still there. I trust a log of small problems more than one confident explanation.
Decision table: is this one issue or several
Apply when a problem comes up. Add the answers to the issue log.
| Question | If yes, it points to | If no, it points to |
|---|---|---|
| Has anything similar happened in the last ninety days? | Treat them as one pattern and look for a common cause | Treat it as a single event, and still log it |
| Did something change just before it started? | Trace the change: a person, a system, a price, a policy | Look for a slow cause: a drift in workload, pay, or service |
| Does it touch more than one function? | Escalate to the integration lead to map the dependencies | Assign it to the function lead, with a date |
| Does it touch a customer or a key person? | Treat as urgent and assign a named owner today | Assign to the function lead |
| Is the cause fixed, not just the symptom? | Close it and record what you learned | Keep it open |
A short example of tracing a cause
Suppose three things happen in the same quarter: two long serving technicians resign, a major customer complains about response times, and overtime climbs. Treated separately, you recruit, apologize, and approve more hours. Traced together, you may find that a new dispatch rule changed how jobs are assigned, shifted the hardest calls to the best people, and wore them down.
The fix is a rule change, not a hiring plan. The log makes that visible because the three entries sit side by side with a date. Without it, each department solves its own piece, and the cause continues to produce new symptoms.
Keep the entries short and factual, and note what you tried. Over time, the log becomes the best record of what your integration approach gets wrong, and the first thing to read before the next deal.
Why this matters
Integration fails slowly. The business keeps running, revenue looks fine for a quarter, and the damage appears in churn, turnover, and margin long after the decisions that caused it. A buyer who treats each problem as isolated keeps paying for the same mistake.
A buyer who looks for the fault learns. The next integration, and the one after, goes better. The log is how you find out where you are losing them.
Get the 100 day integration tracker
The tracker puts an owner, a date, and a status on every integration task from pre-close to day 100, so decisions like this one get made on purpose and followed up.
One email with the download, and occasional Building Results notes. Opt out any time.
Questions
Why do problems keep surfacing months after an acquisition?
Because many problems are old decisions finally showing in the numbers. A handoff that went wrong in month one becomes a customer complaint in month four. Keep an issue log, ask what changed before each problem started, map who and what each one touches, and review the log weekly for clusters. Close an issue only when the cause is fixed, not when the symptom stops.
What should an issue log include?
The issue, who it affects, when it started, what changed around then, who owns it, and what it depends on.
Who should own the log?
The integration lead, with each function lead adding entries.
How often should the team review it?
Weekly for twenty minutes during the first hundred days, then monthly.