One Dashboard Your Monday Meeting Runs On, Instead of Four Conflicting Sheets

It depends on your budget, your team and where your data sits. Power BI suits businesses already in Microsoft 365, with someone who can learn its modelling language, and it handles large models well. Metabase suits teams where somebody is comfortable writing a little SQL and where you would rather host it yourself than pay per user. Looker Studio is free and fine for a handful of views over Google Sheets, BigQuery or advertising data, and gets awkward beyond that. We recommend against the famous option often enough that it is worth asking us before buying licences.

Yes, and it is the most common request we get. Tally can be read through its XML interface or through ODBC from the machine it runs on, which lets us extract the sales register, purchases, ledgers, outstanding balances and stock on a schedule. The practical issues are usually elsewhere: the Tally machine has to be reachable when the extract runs, ledger names have to be consistent enough to match against your CRM, and branch or cost centre tagging has to actually exist in the vouchers. We check those before promising anything.

As current as you need and are willing to pay for, and for most businesses nightly is the honest answer. A refresh that runs at two in the morning gives everyone yesterday’s complete position before the day starts, which is enough for almost every management decision. Hourly or near-live refreshes are possible where the source supports it, and they cost more to build and to run. The question worth asking is what decision would actually change if a number were four hours fresher.

Almost always because there are two definitions rather than two mistakes. Sales counts the order, accounts counts the invoice. One nets returns in the month of sale, the other in the month of return. Branch figures include interbranch transfers in one system and exclude them in another. No reporting tool fixes this, which is why we hold a definitions workshop with your accountant and department heads before building anything, and why that session is often the most valuable thing we do.

Yes, and this is a large part of this work. The usual finding is that the connection points at an Excel export on somebody’s desktop rather than at a real source, so the refresh broke when that laptop changed. Sometimes the model has measures computed inside individual visuals instead of defined once, so two charts on one page disagree. We review what exists, keep what is worth keeping, fix the sources and the model, and remove the pages nobody opens.

Yes, through row-level security, and it should be set up from the start rather than added once somebody notices. Each user is mapped to the branches, territories or customers they are entitled to, and every report filters accordingly, including scheduled deliveries. Margin and purchase rates are often restricted further. Building this later is painful because dashboards and distribution lists have already been designed on the assumption that everyone sees everything.

Not usually, and not at first. If you have one or two sources and reasonable volumes, reporting tools can read them directly or through a light staging database. A warehouse earns its place when you have several sources that need joining, when reading live systems slows them down, when you need history that the source systems overwrite, or when transformation logic has grown beyond what a few views can hold. Building one before those apply is a cost with no benefit, and we will say when you have reached that point.

That depends on the tool and on how many people need access, and we put the running cost in the recommendation before you commit. Power BI is priced per user with capacity options for larger deployments, Metabase has an open-source edition you host yourself alongside paid editions, Looker Studio is free with paid options for scale, and Superset is open source. The cost that surprises people is rarely the licence itself. It is cloud hosting for the data, and the person’s time needed to maintain it.

It will be, and that is normal rather than a blocker. Branch names spelt four ways, items without a category, invoices with no cost centre, customers duplicated across systems. We standardise what can be standardised on the way in, match what can be matched, and list what cannot as an exception report rather than dropping it silently. That exception list usually becomes useful in its own right, because it tells your team exactly which entries to fix at source.

Your team, if you want, and we build for that. The model, the joins, the measure definitions, the refresh schedule and the known exceptions are documented, and we train whoever will own it on how to add a measure or change a view. Many clients keep a small monthly arrangement for new requirements and for someone to call when a number looks wrong before a board meeting. What we avoid is a set-up only we can maintain, because that is a dependency you did not ask for.

They overlap, and the difference is where the weight sits. This work is about the reporting layer: choosing the tool, agreeing definitions, building the model and making dashboards people open. Data engineering is about what sits underneath when the sources get complicated: pipelines, warehouses, transformation and history. For many small and medium businesses, the reporting layer over direct connections is all that is needed. When it is not, the two pieces of work run together, and we will tell you which one you are actually buying.

Mostly how many sources have to be joined and how clean they are. One system with tidy masters is quick. Four systems that disagree about customer names and branch codes is where the effort goes, and it is data work rather than dashboard work. The other drivers are how many roles need their own view, whether row-level security is required, whether a warehouse is needed, how much history has to be loaded, and whether you want scheduled delivery and alerting. We quote after seeing the sources and running the definitions workshop.

Five numbers and one trend, for one person. Resist the urge to build for everybody at once. Start with whoever makes the most decisions, usually the owner, and answer the questions they currently pick up the phone for: what did we sell, what did we collect, what is overdue, what is stuck and how does that compare with last month. Deliberately narrow beats broad, because a screen with five numbers gets opened daily and one with twenty-four charts gets bookmarked once and forgotten.