Should This Dashboard Request Become a Dashboard, a Decision Brief, or a Workflow Change?

Should this dashboard request become a dashboard, a decision brief, or a workflow change?

A dashboard request should become a dashboard only when the same team needs recurring exploration against stable definitions. If the need is one bounded call, use a decision brief. If the real problem is ownership, cadence, or handoff behavior, make a workflow change instead.

That sounds obvious when written cleanly.

It almost never arrives cleanly.

What usually arrives is some version of this:

• “We need a dashboard for pipeline quality before next week’s forecast review.”
• “Can someone build a dashboard so marketing and sales stop debating this in meetings?”
• “Leadership wants a dashboard for board prep.”
• “We should probably have a dashboard for this handoff.”

Those requests all use the same noun. They are not asking for the same job.

That is why dashboard backlogs get messy so fast. The queue fills up with requests that sound buildable, but the intake never forced the room to separate a recurring operating need from a one-time call or from a workflow habit that should change whether a dashboard exists or not.

This article is not another general complaint about dashboards. The Myth of the Marketing Dashboard already makes that point. The Reporting Artifact Hierarchy already explains the bigger menu of reporting formats.

The gap this piece is trying to close is narrower and more practical:

When someone says, “we need a dashboard,” what should the intake owner do in the next 15 minutes?

Why this intake decision matters more than teams think

The wrong artifact does more than waste design time.

It locks the room into the wrong operating behavior.

A dashboard built for a one-time decision teaches the team to maintain something nobody really needed to revisit. A dashboard built on unresolved definitions teaches everyone to keep arguing with prettier charts. A dashboard built for what is really a workflow problem teaches people to ask for more reporting instead of fixing the handoff, review, or meeting rhythm that keeps creating the same confusion.

Salesforce’s State of Data and Analytics research found that 63% of data and analytics leaders say their companies struggle to drive business priorities with data.¹ That is exactly the kind of environment where intake discipline matters. When the room is already under pressure, the team does not need another reporting object by default. It needs the narrowest output that can actually improve the decision.

The operator-level tell is simple: if every urgent ask becomes a dashboard request, the business is using BI intake as a substitute for better translation.

The three honest outcomes

Before you draw the tree, anchor on the three outcomes you are actually choosing between.

1. Dashboard

A dashboard is the right answer when one audience needs recurring visibility into the same metric family and genuinely needs to inspect movement, segments, or operational drift over time.

This is a reusable operating surface.

Good fit:

• weekly channel review where the same owner revisits the same metrics
• recurring pipeline inspection by segment, source, or stage
• repeatable QA view for a RevOps or marketing operations owner

Bad fit:

• one leadership call that mostly needs a recommendation
• a political fight over whose definition wins
• a process break that no chart can repair

2. Decision brief

A decision brief is the right answer when the room needs a tighter story for one bounded call.

That usually means one recommendation, one comparison, or one planning decision where the reader does not need to explore the data forever. They need enough evidence, caveats, and framing to decide what to do.

Good fit:

• should we change paid budget mix this month?
• which attribution caveat matters for the board update?
• which KPI definition should leadership adopt for the next quarter?

The operator detail that matters here is shelf life. If the output only needs to survive one planning cycle, campaign decision, or meeting sequence, a dashboard usually creates more maintenance than value.

3. Workflow change

A workflow change is the right answer when the reporting request is really pointing at a behavior problem.

That could mean:

• the weekly meeting has no named decision owner
• the handoff between teams is messy
• approvals happen too late
• definitions are still resolved socially instead of operationally
• the same exception keeps appearing because nobody changed the process

In those situations, building a dashboard is often the most expensive way to avoid changing the operating rhythm.

A dashboard can reveal the mess. It cannot own the handoff.

The decision tree I would use in a real intake meeting

This is the branching sequence I would use when someone asks for another dashboard.

The tree is intentionally strict. It is supposed to slow the request down just enough that the room has to say what kind of problem it is actually trying to solve.

Gate 1: Is there one audience and one decision?

Start here because this is where a lot of dashboard requests should fail fast.

If one request is trying to serve executives, channel operators, finance, and a cross-functional meeting all at once, it is not a dashboard spec yet. It is a mixed intake problem.

Same if nobody can answer these questions clearly:

• who opens this first?
• what choice changes if the number moves?
• which meeting or workflow is driving the urgency?

If the audience and decision are still blended, the real next move is usually a workflow change or an intake reset. You may need a tighter meeting structure, a named owner, or a translation pass before any reporting artifact is honest.

This is exactly where Translate the Ask tends to create leverage. The business often does not need more reporting yet. It needs the request de-mixed into something buildable.

Gate 2: Is this question recurring or one-time?

This is the easiest branch for teams to skip because dashboard language sounds permanent by default.

But shelf life matters.

If the answer only needs to support one budget call, one board-prep sequence, one campaign postmortem, or one planning choice, a decision brief is usually the better first move. It gives the room a recommendation, a caveat frame, and a next step without creating a new object that now needs maintenance, permissions, stakeholder review, and future explanation.

A useful test is: Will the same person reopen this next week for the same job, or are we really trying to get through one call cleanly?

If the answer is one call, build the brief.

Gate 3: Are definitions and owners stable enough to reuse?

This is where a lot of requests drift from “dashboard” into “workflow change” even when the need is recurring.

A recurring need does not automatically deserve a dashboard if the logic underneath it is still socially negotiated every week.

Pressure-test:

• do adjacent teams agree on what the metric includes and excludes?
• is there a named owner for the number?
• does one system win consistently for this use case?
• would the same caveats show up every week anyway?

If the definitions, owner rules, or source hierarchy are still unstable, the request is not ready to become a reusable dashboard surface. The honest next move is to fix the operating disagreement or trust break first.

Sometimes that means a metric-alignment sprint like Three Teams, Three Numbers. Sometimes it means deeper source logic or warehouse cleanup. Either way, that is a workflow and governance problem before it is a reporting build.

Gate 4: Does someone need exploration, or does the team really need a behavior change?

This is the last branch because it separates a real dashboard from a process patch.

Even after the request passes the earlier gates, you still need to ask whether the user needs to explore the data or whether the team actually needs a tighter operating rule.

A dashboard is right when the user needs to inspect variation, filter, compare, and revisit the same metric family repeatedly.

A workflow change is right when the answer should become something like:

• a standing threshold in a weekly meeting
• a named owner review before budget moves
• a CRM handoff rule
• an approval checkpoint
• a cadence change in how the room uses the number

That distinction matters because recurring does not always mean exploratory. Sometimes the room is really asking for an easier way to enforce one operating behavior.

A comparison table for the intake call

If the room gets stuck, this is the fastest way to lower the temperature.

Three examples that make the distinction real

Example 1: Weekly paid performance review

If the same growth lead and channel team need to inspect spend, pipeline, CAC, and conversion by channel every week, and the definitions already hold well enough for operating use, that is a dashboard candidate.

The operator observation that matters: the team is not looking for a one-time answer. They are looking for a reusable place to see movement and ask follow-up questions.

Example 2: “We need a dashboard for the board”

This is often not a dashboard request at all.

Boards rarely need open-ended exploration. They need narrative, framing, risk, and explicit confidence. If the request is really about one board-ready readout or one pre-board decision, a decision brief is the better fit.

That is one of the easiest ways teams accidentally build the wrong artifact well.

Example 3: Marketing and RevOps keep fighting about MQL-to-pipeline numbers

This is where teams usually waste time if they jump to another dashboard.

If the handoff rules, source authority, and definition logic are still unsettled, a dashboard will not settle them. It will just give the next meeting a cleaner screenshot for the same argument.

The honest move is a workflow change:

• name the winning definition for the use case
• set owner authority
• document fallback logic
• tighten the review rhythm

Then decide later whether a dashboard is worth building on top of that cleaner operating model.

What a usable intake meeting should produce

By the end of the meeting, I want the room to leave with one sentence that sounds like this:

• “This should be a dashboard for weekly channel review.”
• “This should be a one-time decision brief for the Q3 budget shift.”
• “This should become a workflow change in the Tuesday pipeline meeting before we build anything.”

If the room cannot say that clearly, the intake is not done.

That sounds blunt. It saves a lot of wasted reporting work.

The room does not need full architecture at that moment. It needs one honest next move.

What to do if the answer is still uncomfortable

If the request keeps collapsing back into “but can we just make a dashboard for now,” that is usually a signal that the business wants the artifact to carry ambiguity it has not resolved yet.

That is the moment to push back a little.

Not because dashboards are bad.

Because the wrong reporting artifact trains the organization to keep asking for representation instead of resolution.

If the ask is still mixed, use How to Translate Business Questions Into Data Requirements next. If the bigger issue is the reporting shape itself, use The Reporting Artifact Hierarchy as the follow-on frame. If the trust fight is cross-functional, that is when Three Teams, Three Numbers becomes the sharper route.

The practical bottom line

A lot of teams do not have a dashboard shortage.

They have an intake discipline shortage.

The right first question is not, “What should the dashboard show?”

It is:

Should this request become a dashboard at all, or are we really looking at a one-time decision brief or a workflow change?

If you force the room to answer that honestly before the build starts, you prevent a lot of reporting theater.

And if the room keeps asking for dashboards because the ask itself is still blurry, that is exactly the kind of problem Translate the Ask is meant to solve.

Sources

1. Salesforce, State of Data and Analytics (2023). https://www.salesforce.com/news/stories/state-of-data-and-analytics-report/