What a Nonprofit Dashboard Should Actually Show

A board asks for a dashboard. Somebody exports what the database can produce, arranges it into charts, and sends it round. It is colorful, it is comprehensive, and within two meetings nobody opens it before the meeting starts.

The failure is almost never the tool. It is the direction the thing was built in.

Build backwards from the decision

Most dashboards are built forwards. Here is the data we have, here is what can be charted, here is the chart. The result answers questions nobody asked and omits the one thing a director needed on Tuesday.

The useful ones start at the other end. Name the handful of decisions leadership actually makes in a quarter. Should we extend this program. Is the intake backlog getting worse. Are we on track for what we promised the funder. Then ask what a person would need to see to make each of those decisions well.

What it should never become

• A data dump. More fields and more pages do not create insight. They create a page people skim and stop opening.
• A reward for vanity metrics. Volume looks impressive and moves without anybody doing anything. If a number only ever goes up, it is not telling you much.
• A reporting burden. If producing it takes a person two days a month, it will quietly stop being produced, usually in the busiest quarter.
• A performance review. The moment a dashboard is used to judge individual staff, the numbers start being managed rather than reported.

The board view and the team view are different documents

This is the most common structural mistake, and it is made with good intentions: one view, shared with everyone, so that everybody sees the same thing.

But a board meets quarterly and decides on strategy, risk and resourcing. A program team meets weekly and decides who to call back. The first needs one page, few numbers, direction of travel, and a plain note on anything off track. The second needs detail, recency, and the ability to filter down to a caseload.

Build both from the same underlying measures. Do not force them into the same page.

Decide what off track means before it is

A number on its own is not information. Ninety-one is good or bad depending entirely on what you expected.

So agree thresholds in advance: what you are aiming for, and the point at which something warrants a conversation. Writing it down in a calm month is what stops the argument in a difficult one, because the disagreement about whether a result is acceptable has already been had.

This is also what lets a view carry color honestly. A status that reflects an agreed threshold means something. A status somebody set by eye the morning of the meeting does not.

Every number needs a name beside it

Not a department. A person, who is accountable for producing that number on schedule and for being able to say what it means.

Dashboards decay quietly. A data source changes, a form gets edited, somebody leaves, and three months later a chart is confidently displaying something that stopped being true in March. Named ownership is the only reliable protection, and it costs nothing to assign.

Make it boringly easy to refresh

The single best predictor of whether a dashboard survives its first year is how long it takes to update. Under fifteen minutes and it gets done. Over half a day and it gets done twice, then abandoned with an apology.

That usually argues for fewer measures pulled automatically rather than more measures assembled by hand. It is better to have five numbers that are always current than twenty that are four months old, and it is a design decision rather than a software one.

Where the public version fits

Some of this belongs in front of funders and the community, and that is a different job again. An internal view exists to prompt a decision. A public one exists to earn trust, which means context, honesty about what did not work, and plain language instead of sector vocabulary.

Organizations that do this well tend to put a small, current, carefully chosen set of figures on their own website, rather than burying them in an annual report nobody downloads. It is the same measurement work, presented for a reader who owes you no attention.

A reasonable first version

One page. Five or six measures. A baseline and a target beside each. A plain status. A name against every number. One sentence of commentary where something moved.

That is genuinely enough to change a meeting, and it can be built in a spreadsheet this month. Everything more sophisticated should wait until the simple version has been used for two quarters, because by then you will know which numbers you actually reach for, and that is a far better specification than anything you could write now.