Building a PE Integration Dashboard: From Spreadsheets to a Live Cost Model

When a private equity firm closes a merger of two fiber broadband companies, the integration program that follows is one of the highest-risk and highest-value phases of the entire investment thesis. Systems need to be consolidated, costs need to be rationalized, and the combined entity needs to operate as a single company — all while both businesses continue serving customers without interruption.

We were brought in to support the IMO (Integration Management Office) for exactly this kind of deal: two fiber operators combining under a PE sponsor, with a nine-workstream integration program and a Day 1 target of May 2026. The integration team needed visibility across the entire program — not just a status update slide deck, but a live working tool that the steering committee, workstream leads, and the PE sponsor could all use to track progress, understand cost implications, and make decisions.

The problem with spreadsheets

The integration program started — as they all do — in spreadsheets. One workstream lead had a systems inventory in Excel. Another had an action log in a shared Google Sheet. The IMO had a Gantt in PowerPoint. The CFO had a cost model in a separate Excel workbook. None of these talked to each other, and every steering committee meeting involved someone manually pulling numbers from four different files to produce a single slide.

The specific problems this creates:

• Stale data. By the time numbers reach a steering committee deck, they're already a week old.
• No single source of truth. The PMO's systems list and the CFO's cost model had different system counts and different cost figures for the same systems.
• Invisible dependencies. When a go-live date slipped for one system, no one could immediately see which savings targets were affected and by how much.
• Decision latency. A question like "if we delay the ERP migration by two months, what happens to our Year 1 synergy number?" required an analyst half a day to answer. What we wanted was a tool where that question had an answer in under 30 seconds.

The data model

We settled on a flat JSON data model with five primary objects:

Systems (64 records) — every software system across both companies, with current cost, new/consolidated cost, synergy, savings type (savings, investment, or flat), and the month index when savings are expected to be realized. The month index is a number from 0 to 16, where 0 = May 2026 (Day 1) and 16 = September 2027 (end of program).

Implementation costs (26 records) — consulting engagements and internal resource allocations: the ERP implementation partner, the systems integrator for the billing platform, external PMs, internal SMEs allocated to the integration at fractional FTE. These are one-time costs that don't appear in run-rate but are critical for understanding total investment.

Actions (57 records) — the live action log, with workstream, priority, status, owner, and due date.

Workstreams (9) — Q2C, Finance, Network, D&C, Data Analytics, People Ops, IT Systems, Marketing, and Legal & Admin. Each workstream has a charter goal, staffing model, and Gantt timeline.

The key design decision was keeping implementation costs separate from run-rate costs. Run-rate answers what you'll pay every year after integration. Implementation cost answers what you need to invest to get there. Mixing them produces a cost model that's easy to misread.

The price build visualization

The most useful visualization is what we call the price build — a waterfall chart that tells the full story of integration economics in a single view. It starts with combined current annual spend (~$16.7M across 64 systems), adds implementation cost as an amber bar, then shows each savings event as a green drop in chronological order. The chart lands on the final run-rate — what the combined company pays annually once integration is complete.

For this program: ~$16.7M current combined spend, ~$3.4M in implementation investment, ~$2.8M in annual run-rate savings — a 17% cost reduction. Payback period on implementation investment is roughly 14–15 months.

Some savings are immediate (expired contracts, duplicate tools cancelled at Day 1). Others are contingent on major milestones — the largest single savings event is ERP consolidation, which doesn't land until Month 13. That timeline dependency is invisible in a spreadsheet but immediately obvious in the price build.

What "savings month" actually means

The most important field in the data model is savings_month — which month does this system's cost change? For a simple duplicate SaaS tool, the answer is straightforward: cancel one subscription, from Month 1 you pay half. For a complex system like the ERP, you only realize savings when the new system is live and the old one is decommissioned. That requires a successful implementation, UAT, data migration, and cutover. Any of those can slip.

That's why savings_month is a data field you can update, not a hardcoded chart element. When the ERP go-live slips from Month 11 to Month 13, you update one field and immediately see the updated Year 1 synergy number.

The implementation cost model

One thing that consistently surprises PE sponsors is how much implementation costs matter relative to run-rate savings. For a technology-heavy integration, implementation cost can represent 12–18 months of savings. We tracked costs at the engagement level — billing platform implementation, ERP implementation, each external PM allocation, and internal SMEs allocated fractionally.

The last category — internal resource allocation — is the one most teams undercount. A 0.25 FTE allocation for a senior engineer over 12 months is real cost even if no money changes hands. We added a 15% contingency line, which the CFO flagged as conservative. We kept it. Integration programs almost always find unexpected costs.

Technology choices

The dashboard is built in plain HTML, vanilla JavaScript, and SVG. No React, no build tooling, no npm. This was deliberate — the dashboard needed to be shareable as a single file, opened by a CFO on a Windows laptop with no development environment. Every layer of tooling adds a deployment dependency. A single HTML file has none.

SVG charts are built programmatically using document.createElementNS rather than inline SVG strings — more verbose but completely reliable for tooltip handling. The data is embedded as a <script type="application/json"> tag parsed at boot time.

What's next: moving to a live data backend

The dashboard in its current form requires someone to edit the embedded JSON and reload to update data. The natural next step is connecting to a live backend. For a Microsoft environment:

• Microsoft Fabric — Delta tables for each data object, SQL analytics endpoint for real-time queries
• Azure Functions — thin API layer, one function per data operation, auth via Azure AD
• Azure Static Web Apps — free tier, deploys from GitHub, built-in integration with Azure Functions
• MSAL — every write attributed to a specific person

Delta tables in Fabric keep a full transaction log, so you get audit trail for free — every change recorded with a timestamp and user identity. For a program with financial data under PE scrutiny, that matters.

Live demo

The interactive dashboard is embedded below. All company names and financial figures have been anonymized — software product names are real, costs have been scaled, and the company is a fictional fiber operator. The data model, visualization logic, and program structure reflect a real integration.