How to build an internal dashboard for operations

An operations dashboard is one screen that shows the people running the business what needs attention today: orders that will miss dispatch, jobs without a crew, stock below reorder level, invoices overdue. You build a good one by starting from the decisions it supports, defining every number in writing, connecting to the systems where the data lives, and designing the screen around exceptions rather than totals. Many teams can do this with a BI tool on top of data they already have. A custom build is worth it when people need to act from the screen, or when the data sits in systems no BI tool connects to.

Operations dashboards are one of the things our client portals and internal tools service builds, often as the first screen of a larger tool. The seven steps below are the order we work in.

1. Start with the decisions the dashboard must support

Do not start from the data. Start from the morning meeting. Write down the questions people ask there and the decisions that follow:

• Which orders will miss today's dispatch, and who is chasing them?
• Which jobs tomorrow have no crew or no materials?
• Which customers are over their credit limit and should not get another delivery?
• Which suppliers are late on purchase orders due this week?

For each question, note who asks it, when, and what they do with the answer. If nobody does anything differently because of a number, leave it off. Monthly revenue is interesting. It is not operational.

2. Write down a definition for every number

Most dashboard arguments are definition arguments. Sales thinks an order is late when it misses the date promised to the customer. The warehouse thinks it is late when it misses the internal dispatch date. Both are right, and a dashboard that does not say which one it shows will be ignored by half the room.

Agree this table with the people who will use the dashboard before anything is built. It is the cheapest hour in the project.

3. Find where each number lives and how to get it out

A typical operations dashboard pulls from an accounting system, a CRM or order system, a spreadsheet or two, and sometimes a shipping provider or the online store. For each source, there are four ways in:

• An API, the best option when the system has one. API integration explained covers how these connections work.
• Read access to the database, ideally a read-only copy, for systems you host yourself.
• A scheduled export, a CSV dropped by email or file transfer, for older software. Desktop accounting such as Tally needs its own approach; see Tally and Zoho Books integrations.
• A small entry form, for facts that live only in someone's head today.

Copy everything into one database on a schedule, rather than querying five systems every time someone opens the page. Spreadsheets are the weak point as sources: anyone can rename a column and break the sync. If a spreadsheet holds a number that matters, it is often a sign it should become part of the tool, as when to replace spreadsheets explains.

4. Choose between a BI tool and a custom build

Be honest about which one you need. If the dashboard is read-only, the sources have connectors and the audience is internal, a BI tool is cheaper and faster, and we will say so. Custom pays off when the dashboard is where work happens: a dispatcher marks an order as chased, a manager reassigns a job, a client sees their own slice. It is the same reasoning as in custom software vs off-the-shelf, applied to one screen.

5. Design the screen around exceptions

The top of the screen lists what needs attention, with counts: seven late orders, three jobs without a crew, two customers over limit. Each count opens the list behind it, sorted by urgency, with the person responsible next to each row.

Below that, a few trends with a comparison: this week against last, actual against target. Tables beat charts for anything someone has to act on. Keep the first screen to the handful of numbers from step 1, and make it readable on a phone, because managers will open it on the way in. How to build an admin dashboard that staff actually use covers the screen design in more detail.

6. Set refresh times, alerts and an owner

Match refresh to the decision. Dispatch needs data every few minutes; receivables can refresh once a morning. Show "last updated" on every number. A stale dashboard that looks fresh is worse than none.

Heavy queries should be computed ahead of time rather than on every page load. In PostgreSQL, a materialized view stores the result of a query and is refreshed on a schedule:

-- refresh without blocking readers; requires a unique index on the view
REFRESH MATERIALIZED VIEW CONCURRENTLY late_orders;

Run that from a scheduled job. For example, */10 6-21 * * 1-6 runs every ten minutes from 6:00 to 21:50, Monday to Saturday; the cron expression generator builds and explains schedules like this.

Then add alerts. When late orders pass a threshold, message the dispatch lead rather than waiting for someone to look. Every alert needs a named owner, and every sync needs failure monitoring, or the dashboard will quietly show yesterday's world. Why integrations break covers the monitoring side.

7. Launch it in one meeting, then prune

Run the next daily meeting from the dashboard, and switch off the old report the same week. Two sources of truth means the old one wins.

After a month, look at what people actually open. Numbers nobody clicks come off. Questions people still ask out loud become candidates for the next version.

If you are starting today, do step 1 at your next operations meeting: write down every question asked and who answered it. That list is the specification.