Choosing the right view for the right audience

In this lesson

Match report detail level to what a specific audience needs to decide
Recognise when a dashboard is the wrong format for the question being asked

The most common reporting mistake in ProFinda is building one comprehensive view and sending it to everyone. It satisfies nobody. A partner scanning a dense utilisation dashboard for thirty seconds before a meeting needs something entirely different from an operations lead who will spend twenty minutes deciding where to reallocate people next week.

Start from the reader’s question

Before opening the report builder, write down the one question the report needs to answer for its specific reader. “Are we over- or under-resourced this quarter” is a partner’s question, answerable in three numbers and a trend line. “Which teams have the most people below target utilisation, and since when” is an operations lead’s question, and it needs the breakdown a partner would never ask to see.

What a partner needs

Partners generally need the smallest possible number of figures that let them decide whether something needs their attention: overall utilisation against target, direction of travel, and perhaps one flagged exception. A dense grid of every team’s numbers is more likely to be skimmed and set aside than a chart with three data points and a one-line note underneath it.

What an operations lead needs

An operations lead making staffing decisions needs the breakdown a partner would find overwhelming: utilisation by team, by grade, against target, with enough history to see whether a dip is a blip or a trend. This is where a fuller dashboard view earns its complexity, because the reader is going to act directly on the detail, not just note a headline.

One dataset, several reports

The same underlying utilisation data can support both views without duplicating effort. Build the detailed operational view first, since it contains everything, then build the partner summary as a smaller, filtered view drawing from the same source. This way, when the data updates, both reports update together, and you are not maintaining two separate exports that can quietly drift apart.

Write the reader’s question in one sentence before opening the report builder.
Decide how many numbers actually answer that question - usually far fewer than the data allows.
Build the detailed view first if more than one audience needs the same underlying data, then derive summary views from it.

The next lesson walks through building one of these reports end to end.

Key takeaways

A partner needs three numbers; an operations lead needs the breakdown behind them
The right view answers the reader's actual question, not everything you know
One dataset can support several different reports, each built for a different reader