Every growing service business reaches a point where the founder decides the reporting is not good enough. The numbers are late. The dashboards do not match what the team is actually experiencing. The monthly review meeting spends more time reconciling different versions of the same metric than discussing what the metric means. The founder concludes that the answer is better reporting, and often invests in a dashboard tool, a business intelligence platform, or a consultant who specialises in reporting design.
Some of that investment pays off. Most of it does not, or at least does not produce the transformation the founder was hoping for. The reason is consistent across the industry: the reporting problem the founder is trying to solve is almost never actually a reporting problem. It is an operational problem that shows up at the reporting layer, because reports can only surface what the operational systems below them have captured, and if the operational systems have not captured it, the report cannot show it, no matter how sophisticated the reporting tool is.
This is one of the most common misdiagnoses in growing service businesses. The founder is not, in fact, short of reports. They are short of a coherent operational picture, and reports are the visible manifestation of that shortage. Fixing the reports without fixing what sits beneath them produces prettier versions of the same problem, and founders who have done this once and been disappointed often, understandably, become sceptical of reporting projects in general. The scepticism is misplaced. What actually needs to change is not the ambition to have better reporting. It is the recognition that a real reporting layer is the top of a stack, and the layers below it are where the work has to be done.
What most reporting actually is in a growing business
If you look honestly at how most growing service businesses produce their reports, the picture is consistent and unglamorous. Someone, usually the founder or an operations lead, spends time each week or month pulling data together from multiple places. The CRM has some of it. The accounting system has some of it. Spreadsheets kept by different people have the rest. The data gets combined, sometimes in a master spreadsheet, sometimes in a slide deck, sometimes in a document that gets shared over email. The report gets produced. It contains the numbers the team looked at last time, plus one or two new ones the founder wanted this month.
The report is often approximately correct. It is rarely fully trusted. Everyone involved knows the assembly process. Everyone knows that a number could easily be slightly wrong because of how it was pulled together, and no one has the time to fully audit it before the meeting. So the meeting happens, the numbers get discussed, and the discussions are less confident than they should be, because the underlying data is less trustworthy than the surface of the report suggests.
This is the state of reporting in most growing service businesses, and it is worth being direct about what it is. It is not really reporting. It is a rhythm of manually assembled summaries that give the appearance of an operational picture without providing the substance. As covered in the piece on why founders don’t trust their numbers, the erosion of trust in the reporting layer is one of the most commercially significant problems in a growing business, and it happens because the reports are being manufactured rather than surfaced. Manufactured reports carry the risk of manufacturing errors. Surfaced reports do not, because they are not being built each time.
The distinction between manufactured and surfaced is the whole game. A real reporting layer surfaces what is already true in the operational systems below it. A manufactured report is the founder’s best guess at what is true, assembled by hand under time pressure, with all the fragility that implies.
What a real reporting layer requires beneath it
A reporting layer that actually surfaces the operational picture requires three things to be in place beneath it, and this is where founders who try to fix reporting alone consistently run aground.
The first is that the operational data has to be captured consistently in the systems that produce it. If the sales pipeline is only partly maintained in the CRM, with some deals living in the founder’s inbox and some in a consultant’s head, the reporting layer cannot show a coherent pipeline picture, because the coherent picture does not exist anywhere yet. If project status is tracked differently by different team members, the reporting cannot produce a consistent view of delivery health. Data capture discipline is not glamorous work. It is often what makes the difference between reports that surface reality and reports that describe a fiction.
The second is that the systems have to be connected in the right way for the data to be combinable. A CRM that holds client information and an accounting system that holds financial information can produce genuinely useful reporting when the two are linked, so a client record can be seen alongside its billing history and its payment status. When they are not linked, the reporting either treats the two as separate pictures, which means the founder still has to mentally combine them, or produces a manually reconciled combined view, which puts the fragility back into the report. The connective layer between operational systems is what lets the reporting layer draw a single coherent picture. As covered in the piece on how to migrate from spreadsheets to a proper business system, the operational architecture beneath the reporting is what determines whether the reporting can be useful.
The third is that the operational structure has to include the concepts the reporting is trying to describe. This is the most subtle of the three, and often the most overlooked. If the business wants to report on “the health of the client base”, the concept of client health has to be operationally defined somewhere, whether through a status field, a rating, a set of activity metrics, or something similar. If the concept exists only in the founder’s mind, the reporting cannot show it, because there is nothing operational to report on. This is why some reporting projects fail even when the systems and the data capture are broadly in place: the concepts the founder wants to see reported on have never been made operationally concrete, and no amount of reporting work can surface a concept that does not exist in the systems.
These three conditions together are the work that has to happen before a real reporting layer produces value. They are not exotic. They require deliberate operational design work, sustained over months, and they usually involve some combination of CRM discipline, systems integration, and operational definition of the concepts the business wants to track. As I cover under reporting and financial visibility, the reporting layer is the visible surface of a larger operational system, and investing in the surface without investing in what sits beneath produces exactly the disappointment founders describe.
What a real reporting layer actually does
When the underlying operational structure is in place, the reporting layer does several things that a manufactured report cannot.
It updates in near-real-time rather than at the end of a monthly assembly cycle. The founder can look at the pipeline, the project health, the financial position, or the client status whenever they need to, and see the current picture. This changes the tempo of decision-making. Decisions get made against current information, not reconstructed history from three weeks ago.
It is trusted, because the underlying data is not being reassembled each time. The team knows the report reflects what is actually in the systems. The founder knows the numbers are current. The confidence in the reporting itself removes an entire layer of hesitation from every conversation that depends on the numbers, and the aggregate effect on decision quality is substantial.
It surfaces things the manual reporting rhythm never would have. A properly integrated reporting layer can produce views the founder never explicitly asked for, but that emerge from the way the data connects. A client whose engagement has slowed. A project whose cost trajectory has diverged from its budget. A pipeline stage that is stalling more deals than the others. These are the insights that manual reporting misses, because manual reporting only produces what was explicitly built. A real reporting layer produces what the data reveals, which is a fundamentally different category of output.
And it scales without additional operational cost. Once the reporting layer is built and the underlying systems are producing the data cleanly, adding more views, more dimensions, more segments, or more comparisons is inexpensive. This is the opposite of manual reporting, where each additional dimension is another few hours of assembly work per cycle. The scaling economics of automated reporting are what make it a durable operational asset rather than a rolling cost.
Why founders build reporting before they build the layer beneath
The order matters, and most founders do it backwards. The reporting problem is visible. The operational problem beneath it is not. So the founder invests in reporting, gets partial results, and concludes reporting is harder than it looks. What actually happened is that the reporting was built on a foundation that could not support it, and the reporting is showing the founder the true state of the operational structure beneath, which is that the structure is not yet coherent enough to produce coherent reporting.
The honest sequence is operational structure first, reporting second. Build the CRM discipline. Connect the systems. Define the operational concepts the business wants to track. Then, and only then, build the reporting layer that will surface all of it. Founders who do this in the right order produce reporting that transforms how the business is run. Founders who do it in the wrong order produce reporting that looks better than the previous version but does not actually change anything, because the foundation is still fragile.
This is one of the more consequential ordering mistakes in a growing service business, and it is worth stating plainly. If your reporting is not producing the clarity you want, the problem is very unlikely to be the reporting itself. The problem is what sits beneath it. Fix that, and the reporting will follow. Try to fix the reporting in isolation, and the result will disappoint.
If your spreadsheet has become the system, tell me what it does and I will tell you whether it is worth replacing. Start a conversation, or read about reporting.