A dashboard should lead to a decision.
From scattered updates to a clear next action.
An approach to Smartsheet reporting and operational systems that puts ownership, clear status, and the next action in view.
TLDR
The short versionStart with the decision a dashboard needs to support. Define the fields, ownership, and reporting periods before choosing the charts.
Connect exceptions to a next action and the record behind them. This article draws on my operational experience at Razorfish without sharing client data or proprietary implementation details.
A dashboard should help someone decide what to do next. That is a more useful brief than asking which charts to include.
My operational work at Razorfish has included Smartsheet systems across media planning, media operations, project and product operations, historical reporting, status tracking, and creative handoffs. Looking across those areas, I think of reporting as part of the working process. The value comes from the connection between the information and the person who can act on it.
This article explains that approach at a general level. It does not reproduce a client system, internal data, or proprietary implementation.
Start with the decision
Before building a view, finish this sentence: the person opening it needs to decide what to do about something specific.
A project lead may need to know which handoffs are blocked. An operations manager may need to identify work that is slipping. A person responsible for reporting may need to compare the current fiscal period with a prior one. Those are different jobs, even when they draw from some of the same records.
Give each view a clear audience and purpose. A master dashboard can provide an overview, while a focused report helps someone work through the details. Trying to make every view answer every question usually makes the important information harder to find.
Agree on what the fields mean
Reliable reporting begins before the chart. People need a shared meaning for the fields they update.
For example, a status of “in progress” tells you very little unless the team agrees on what has started and what would move the work to the next stage. A due date also needs context. It might represent an internal review, a delivery commitment, or the date another team needs an input.
Keep those distinctions visible. Name the owner, define the status, and explain the relevant date. If a field has to be interpreted differently by each person, the dashboard inherits that ambiguity.
For historical reporting, preserve the period definition as carefully as the result. A fiscal-year comparison only makes sense when the records on both sides are being grouped consistently. If the definition changes, explain the change alongside the comparison.
Make exceptions easy to work through
A useful operational report narrows attention. It should help someone see what needs action without requiring them to inspect every healthy item first.
Revenue-at-risk reporting, blocked tasks, and overdue handoffs are examples of that kind of view. The important design decision is what happens after an item is flagged. Show the reason it needs attention, the person responsible, and the next step. A warning without a path forward creates more interpretation work.
Consider an illustrative project handoff. A task is approaching its due date, but a required input is missing. A useful report identifies the missing input and its owner. The person reviewing it can then resolve the dependency rather than sending a general request for an update.
The next action belongs beside the status.
Connect the overview to the record
Summary views and detailed records should support each other. A person should be able to move from an exception on a dashboard to the information needed to understand it.
That is why task tracking, individual reports, and master dashboards need to be considered together. The overview answers where to look. The underlying record explains what is happening. Keeping the relationship clear also makes it easier to question an unexpected result and trace it back to its source.
Automation can help move information between stages or prompt a handoff. It still needs a clear trigger and a defined recipient. Decide what is ready to move, what must be checked first, and where an unresolved item should remain visible.
Review one dashboard this week
Choose a dashboard you already use. Identify the decision it is meant to support. Open one item that needs attention and follow it to its source. Check whether you can find its owner, understand its status, and name the next action without asking someone to translate it.
If that path is unclear, improve the path before adding another chart. You may need a better status definition, a more focused report, or a clearer handoff. A small change at the source can make the entire view more useful.
You can see the scope of my work in the Smartsheets case study. It covers the different operational and reporting needs as part of one connected body of work at Razorfish.



