Most dashboards are not read. The three to five reports founders open daily, and what makes a report stick versus what kills it.
By Mohammad Jamnagarwala · Simply Five Studio
Two years into a custom ERP build for a Mumbai cutting-tool group, the operations head pulled up the system's analytics module to show me what the founders looked at. There were forty-two reports configured. Each took effort to build. Six were opened daily. Eleven more were opened weekly or monthly. The other twenty-five had not been opened in the last three months by anyone.
This is the standard distribution. Founders ask for reports. Reports get built. Reports get used briefly. Most reports then quietly retire, because they did not answer a question the founder genuinely had on a recurring basis. The six that survived are the ones worth understanding, because they tell you what reporting actually has to do.
Across the CFX multi-tenant ERP for the cutting-tool group, the AKSD distributor system, and roughly a dozen other operational systems we run, the pattern of what founders actually read converges to a small set.
Cash position. What is in the bank, what is committed against pending payments, what is expected to come in this week. The founder opens this first thing in the morning. The number is the same number a CFO would look at, simplified to the form a founder uses to decide whether the firm is in a position to make a commitment that day.
Top five outstanding. The five customer accounts with the largest overdue receivables. Name, amount, days overdue, last contact. The founder uses this to decide whose collection call to make personally, versus whose to leave to the team.
Pipeline-to-close this month. The opportunities that are expected to close this month, with the probability-weighted value and the next action against each. The founder uses this to know whether the month is going to land where it should and where to intervene if not.
Days of stock. The inventory items running low, with days-of-cover against current consumption. The founder uses this to make procurement decisions, especially for items where the supplier has a long lead time.
Today's deliverables. The orders, jobs, or commitments that have to be completed today. The founder uses this as the daily standup material, not as a personal action list but as the briefing on whether the team is set up to land the day.
A sixth, depending on the business: the day's interactions. New enquiries, customer calls, vendor escalations. The founder uses this to sense the daily tempo of the firm.
The reports that survive share four properties. They answer a recurring question the founder actually has. They open quickly. They show a small number on the screen the founder can read in one glance. They let the founder drill in if they want to, but they do not require drilling in to be useful.
The recurring-question test is the most important. A report that answers a one-time question gets opened once. A report that answers a question the founder has every morning gets opened every morning. The question has to be one the founder is actually asking, not one the software team thinks the founder should be asking.
The speed test matters more than founders admit. A report that takes six seconds to load is a report that gets opened once a day at most. A report that takes 800 milliseconds is one that gets opened multiple times. The friction of waiting is small per instance and decisive in aggregate.
The single-screen test is what separates a useful report from a research project. The founder is checking a number, not analysing a trend. The single screen has to deliver the answer. The deeper exploration belongs in a separate view the founder opens when they have five minutes, not on the dashboard they open in between calls.
The drill-down test is the safety net. The founder sees the number, recognises it is off, and wants to know why. The report lets them click through. Without drill-down, the founder has to call the team to ask, which creates a loop the dashboard was supposed to eliminate.
Reports die for predictable reasons.
Too many numbers on one screen. The founder cannot tell what to look at first. The cognitive load is high enough that the report becomes a chore. The founder stops opening it.
Stale data. The report runs against last night's batch. The founder wakes up and the numbers are sixteen hours old. The first time the founder calls the team and gets a different number from the live system, the report loses its authority.
Wrong unit of measurement. The founder thinks in rupees. The report shows hours. The founder has to do mental arithmetic to use the number. The friction is small enough that the report still runs, large enough that the founder stops trusting it.
Reports that exist because someone built them, not because someone asked. These are the worst category. They consume engineering time, they clutter the dashboard, and they pull attention away from the reports that matter. The discipline of removing dead reports is harder than the discipline of building them.
The pattern across systems that hold up well is restraint. Six to ten reports on the main dashboard. Each answering one specific recurring question. Each loading in under two seconds. Each with a clear drill-down for the founder who wants to know more.
The essay on decision infrastructure frames why this matters. The point of operational software is not to capture data; it is to make the data legible to the founder who has to act on it. A report that does not get read is data captured for nothing.
The discipline of "what do you actually read in the morning" is the discipline that produces the dashboard that matters. The CFX founders in Mumbai went through exactly this exercise as part of the second year of the engagement. The forty-two reports got reviewed. Twenty-five were retired. The remaining seventeen got grouped by which were daily, weekly, or monthly, and the dashboard was rebuilt around the daily six. The result is a dashboard the founders open every morning, deliberately, because it tells them what they actually need to know.
When evaluating an operational system, the question to ask is not "how many reports does it have." It is "which reports will I read every morning, and how easy are those to build to my exact need." A system with three hundred preset reports and no way to add a customised one is worse than a system with no reports and a builder for the six that matter.
The fit problem covered in the SaaS-versus-custom-build essay shows up here clearly. A generic SaaS comes with reports designed for a generic business. The founder's actual six rarely overlap exactly. The customisation tax is paid in unread reports and missing ones.
A fitted system is built backwards from the six reports. The internal systems practice starts every engagement with this question explicitly: what does the founder want to see at 9 a.m. every morning? The data model, the workflows, and the inputs all get designed to feed the answer.
If your current system has a dashboard you do not open, the dashboard is not the problem. The problem is that nobody asked you what you actually wanted to read. Start a Conversation.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
Tally is the financial system of record. An ERP is the operational system of record. Most founders buy one and assume it is also the other. The confusion costs years.
The contact form takes about two minutes. The reply comes from the founder within two working days.
