Skip to content
Expedify
Expedify in an Afternoon
Course contents

Module · Doing the same things by conversation

Building a dashboard by asking

Lesson 37 of 40 · 5 min

In Asking your business a question the rule was: conversation for the thing you do once. This is what you do when the answer is no longer once — and it is the same conversation, asking for something permanent.

Four asks, one dashboard

You: I want to see how much money is sitting in each stage of the pipeline.

You: Chart it — bars, value per stage.

You: Put it on a dashboard I can send to the branch manager.

You: Show me what it says.

That is the whole build, captured on 2026-08-19. No query builder, no chart configuration screen, no dragging a tile into a grid — and at the end of it there is a real dashboard that a branch manager can open.

But it is three objects, and that matters

Asked for in one conversation; three things afterwards.

A dataset

What it is
The question, saved as a named read-only query
When you would change it
The numbers are wrong or the filter is wrong

A chart

What it is
How to read that dataset — bars, a dimension, a measure
When you would change it
It should be a line, or grouped differently

A dashboard

What it is
Where charts live, and what a client opens
When you would change it
Something else belongs next to it

Clients change dashboards constantly, and almost always they mean one of those three. “Can we see it by month instead” is the chart. “That number looks wrong” is the dataset. “Can the branch manager get this too” is neither — it is sharing. Knowing which you are being asked for is most of handling the request well.

The dataset is the one to look after. A chart is a rendering and a dashboard is a container, but the dataset is a claim about the business, written in SQL, that somebody will make decisions on. It is worth reading properly before it goes in front of anybody — which you can also do by asking.

And it comes back with real numbers in it

The last ask returns the dashboard with its data — the same thing the branch manager would see. So the check is immediate: read the numbers against something you already know, and you have verified it without opening a browser.

Do check. A dashboard is confident by nature: it renders whether or not its dataset asks the right question, and a client will believe it. The pipeline numbers on this one can be checked against the board you read in The deals board and the seven stages in about ten seconds.

Why this is the one clients ask for first

  • It is the thing they can see. Workflows are invisible when they work. A dashboard is a screen somebody opens on a Monday, and it is how a client feels the system is theirs.
  • It is the cheapest thing you will ever build for them. Four sentences here; an afternoon in most tools; a project in some.
  • It reveals what they actually care about. Whatever a client asks to see first is the number their week is judged on. That is worth knowing before you design anything else.

Which is also the trap. A dashboard is easy enough to build that you will build several, and a client with nine dashboards looks at none of them. Build the one they asked for, watch whether they open it, and build the second only if they do.

Change one thing — build the Monday dashboard

  1. Ask for the number you would put in front of a branch manager on a Monday morning. One number, not six.
  2. Ask for it as a chart, then on a dashboard.
  3. Ask to see it with its data, and check one figure against the board by hand.
  4. Now ask for the same thing broken down differently, and notice which of the three objects had to change.
  5. Delete all of it when you are done — a demo org with [TEST] dashboards in it is not a demo org.

Try it

  1. Ask for a dashboard whose dataset you know to be subtly wrong, and see how convincing it looks anyway.
  2. Work out what you would say to a client who asks for a dashboard of everything.

Next: The same thing, inside the product — everything you have just done, without leaving the product.