Most broadband deals look right at close.
The model works. The systems are in place. The path to growth is clear.
Then execution starts.
Revenue takes longer to convert than expected. Launch timelines slip. Integration effort runs higher than planned.
Nothing breaks in a way that forces a reset.
The business moves forward.
But the return starts to drift.
How the Economics Drift
The deal assumes execution is consistent.
When it is, the economics hold. When it isn’t, the economics start to move. Quietly at first.
Revenue conversion slows against plan. Time-to-market becomes inconsistent. Integration costs don’t normalize.
The return depends on operations getting more efficient over time. The operating layer is often what stops it.
These aren’t one-time misses.
They accumulate.
And they don’t show up as a single issue you can isolate and fix. They show up in margin, in timeline, and ultimately in EBITDA.
The business still grows.
But it carries more effort than the deal assumed.
Why Diligence Misses It
Most diligence confirms the systems exist. It doesn’t prove the platform can support the business needs that drive the return.
A platform can perform cleanly in a controlled setting and still struggle under normal operating conditions. The question is what happens when execution has to carry real volume, real variation, and real integration pressure.
That’s where the gap shows up.
Where the Risk Actually Shows Up
The risk doesn’t show up in system diagrams. It appears in how the platform behaves when something changes.
A pricing update should move through the system. Instead, it turns into coordination across teams.
An acquisition should follow a defined integration path. Instead, it introduces new mapping, new exceptions, and new support logic.
A standard order path should complete consistently. Instead, edge cases accumulate until they become the norm.
None of this looks like failure. It looks like variability.
And variability is what the underwriting doesn’t price in. Because it doesn’t stay contained. It spreads into timelines, into cost, and into how much of the business depends on intervention to keep moving.
What to Actually Test
This doesn’t require deep technical diligence. It requires the right questions.
Can products change without redistributing logic across systems? Do orders complete without intervention? Do integrations follow a repeatable pattern? Is data ownership clear, or negotiated each time? Does execution live in the platform, or in a small number of people?
The answers separate quickly. Responses that describe system behavior signal a platform doing its job. Responses that describe individuals signal a platform that isn’t carrying its own weight.
The Platform Has to Carry the Return
A broadband platform can look complete and still undermine the economics behind the deal.
The question isn’t whether something can be done. It’s whether it can be done repeatedly, without adding effort each time.
That doesn’t show up in a demo. It shows up in how quickly revenue converts, how reliably launches hit their window, and how consistently integrations deliver against plan.
That’s what diligence needs to prove. Not that the systems exist. Rather, diligence needs to prove that the platform can carry the return, at scale, without depending on the same few people to keep it working.
