Leadership at a multi-team service company was making weekly decisions from three different screens, none of which agreed with each other. We built a single dashboard that pulls from the tools they already use and shows each role the numbers that matter to them.
The problem
The company ran a healthy operation across several teams: field and service delivery, finance, and a sales function feeding the pipeline. Each of those teams ran on its own software. Sales lived in a CRM. Finance lived in an accounting package and a stack of spreadsheets. Operations lived in scheduling and job-tracking tools. Every system was fine on its own. The problem was that nobody could see across them.
For the leadership team, this meant decisions were being made blind, or close to it. To answer a basic question, such as whether the month was tracking ahead or behind, someone had to open the CRM for booked work, export figures from the accounting system, and reconcile both against an operations spreadsheet that was usually a few days stale. By the time the picture was assembled, it was already out of date, and two people often assembled it two different ways.
The hidden cost was report-building overhead. A manager was spending a meaningful share of each week pulling numbers from separate tools, pasting them into a deck, and chasing down discrepancies before the leadership meeting. That is skilled time spent on assembly rather than judgment. It is the same build-versus-buy and tribal-knowledge trap we describe in our writing on internal tools versus off-the-shelf software: the data existed, but no single product on the market joined it in the shape this business actually needed.
The approach
We did not rip out any of the existing tools. The CRM, the accounting system, and the operations software were all working. The gap was the layer above them, so that is what we built. We started by mapping how decisions actually got made, which numbers mattered to which person, and where each number truly lived, before writing a line of code. That methodology is core to how we approach operational dashboards.
The build had three parts. First, a data aggregation layer that pulls from the existing tools on a schedule and normalizes the figures into one consistent model, so a booked job, an invoice, and a completed work order all reconcile instead of contradicting each other. Second, role-specific views, because the owner, the finance lead, and an operations manager do not need the same screen. Third, real-time metrics with thresholds, so a number that crosses a defined line is flagged rather than buried in a table, with drill-down from any top-line figure straight to the underlying records.
We deliberately built this as focused internal infrastructure rather than another broad platform to administer. The same reasoning that informs our work on operational software for service and construction businesses applied here: the tool should map to how this company runs, not force the company to adopt someone else's workflow. Because finance figures fed several of the headline metrics, we also aligned the dashboard with the structure of their billing and invoicing data so revenue and collections read accurately rather than approximately.
What you would see
The company's real data is private, so the descriptions below stand in for the live screens rather than reproducing them. They are representative views, not actual screenshots.
A single top-of-funnel-to-cash summary: pipeline and booked work from the CRM, revenue and outstanding receivables from finance, and active jobs and on-time delivery from operations, all on one screen and refreshed against live sources. Metrics that cross a defined threshold, such as receivables aging past terms or jobs slipping behind schedule, surface as flags rather than sitting unnoticed in a spreadsheet.
Representative view. Figures shown in the real build are drawn from the client's connected systems.
From any headline number, a user clicks through to the records behind it: an outstanding total expands into the individual open invoices, a delivery metric expands into the specific jobs running late. Each role lands on the view scoped to its decisions, so the finance lead sees cash and collections while an operations manager sees scheduling load and completion status, without wading through numbers they do not own.
Representative view. Drill-down paths reflect the client's own data hierarchy.
The outcome
The operational pattern this produces is consistent across builds like this one, so we describe it honestly as a pattern rather than inventing a metric. Leadership gets one shared, current picture instead of three conflicting exports, which means meetings start from agreed numbers rather than reconciling them. Decision cycles get faster because the question and the answer live on the same screen, and a flagged threshold prompts action before a problem compounds instead of after. The weekly report-assembly work shrinks, because the deck that used to be built by hand is now the dashboard itself, which frees skilled time for the judgment it was meant to support.
Just as important is what the build leaves behind: a single source of truth that does not depend on one person knowing how to stitch the systems together. The visibility is the deliverable, but the durable result is that the company no longer runs its leadership view on tribal knowledge. If your operation has the same shape, scattered data in solid individual tools and no shared view above them, see more of our selected work or read how we think about building custom operational systems at Warren & Sabb.