How to build an executive KPI dashboard

What matters here

• An executive dashboard is four parts: few metrics, a target and owner on each, trend over point-in-time, and a visible refresh state.
• The hard part is subtraction. Forty numbers is a report; twelve is a dashboard, and choosing them is a leadership argument rather than a build task.
• Every metric needs a named owner who would defend it. A number nobody owns generates a question nobody answers.
• Show trend and target together. A number on its own tells a leadership team nothing about whether to act.
• Put the last refresh time on the page. A dashboard that is silently stale is worse than one that is honestly late.
• Link each metric to its definition, or the meeting spends its first twenty minutes rediscovering that two teams count revenue differently.

Who this is for

You run a leadership meeting, or you prepare for one. Every function arrives with its own numbers and they do not agree. What you want is one page everybody trusts, with few enough numbers that people actually read it.

How it works in practice

What happens between the data changing and a leadership team making a decision about it.

1. 1

   The list is short, and stays short

   Ten to fifteen metrics with a cap enforced in the app, because every function will want theirs added.

2. 2

   Every metric has a target and a named owner

   Without a target it produces discussion; without an owner, an unanswered question.

3. 3

   Numbers refresh on a schedule and say when they last did

   A metric past its cadence reads as stale rather than showing an old figure as current.

4. 4

   Trend and target sit beside the value

   Coloured by progress against target rather than direction, because some metrics going up is bad.

5. 5

   The owner writes a line before the meeting

   What moved, why, and what they are doing. That turns an agenda item into a decision.

6. 6

   Period end is frozen

   So the September figure still reads the same in December, and later corrections show as a difference rather than a rewrite.

1. 1

   The short list, and saying no to the rest

   The build is easy. The subtraction is the work.

   Copy

   In this Helix project, build me an executive KPI dashboard.
   
   A metrics table: name, a one-line definition in business language, the
   function it belongs to, the unit, the target for the current period, a
   named owner, and how often it refreshes.
   
   Keep the list short. Ten to fifteen. Build a hard cap into the app with a
   warning when somebody tries to exceed it, because the pressure will
   always be to add rather than remove, and a dashboard with forty numbers
   is a report nobody reads.
   
   Require an owner on every metric, and require a target. A metric with no
   target produces a discussion, and a metric with no owner produces a
   question nobody answers.
   
   Link each metric to its full definition, including what it deliberately
   excludes. Most leadership disagreements about a number are about the
   exclusions, and having the answer one click away saves the first twenty
   minutes of the meeting.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. The cap is the feature. Without it, every function adds theirs and within two quarters you have the report you were trying to replace.

2. 2

   Trend and target, together

   Because a number on its own is not a decision.

   Copy

   Now the display, and never show a bare number.
   
   For each metric: the current value, the previous period, the same period
   last year, the change as an amount and a percentage, the direction, and
   progress against target.
   
   Chart the trend rather than only the latest figure. A leadership team
   needs to know whether something is improving, and a single number cannot
   say.
   
   Colour by whether the metric is on track against its target, not by
   whether it went up. Some metrics going up is bad, and a dashboard that
   does not know which is which teaches people to ignore the colour.
   
   Handle missing data honestly. If a metric has not refreshed, say so
   rather than showing the last known value as though it were current.

3. 3

   Make staleness visible

   Because the expensive failure is a quiet one.

   Copy

   Add refresh handling, and put it on the page rather than in a log.
   
   Each metric records when it last updated successfully and what its
   expected cadence is. Show the timestamp next to the number, and flag
   anything that has missed its cadence.
   
   If a source fails, the metric shows as stale rather than showing an old
   figure as current. A number nobody knows is out of date is the one that
   ends up quoted in a board pack.
   
   Let me snapshot the whole dashboard at period end and keep it, so what
   was reported in September still reads the same in December even after the
   underlying data is corrected. Corrections then show as a difference
   between the snapshot and the live figure, which is a useful thing to see
   rather than a problem to hide.

4. 4

   Commentary, and the drill-down

   The part that turns a chart into a meeting worth having.

   Copy

   Two last things.
   
   Let the owner of each metric add a short comment for the period: what
   moved, why, and what they are doing about it. Prompt for it before the
   meeting rather than during. A number with the owner's explanation
   attached is a decision; a number alone is an agenda item.
   
   And let me drill from any metric to the detail behind it, or link out to
   the functional dashboard that owns it. The executive view should be the
   top of a path rather than a dead end.
   
   Then report: metrics on and off target over time, which metrics change
   owner or definition most often, which is usually a sign the metric is not
   settled, and how often each metric was stale when the meeting happened.

   Worth knowing. The owner comment is the highest-value field and the one most likely to be skipped. Prompting for it before the meeting is the only way it gets written.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Snowflake>. Read most metrics from the warehouse, where the definitions
   have already been applied consistently.
   
   <Salesforce>. Read pipeline, bookings and retention where they are not
   already modelled in the warehouse.
   
   <NetSuite>. Read revenue, margin and cash figures for the finance metrics.
   
   <Looker>. Link each metric to the functional dashboard that owns it, so
   the executive view is the top of a path rather than a dead end.
   
   <Okta>. Read the group that says who is on the leadership list, which is
   the only thing the app should check before showing performance against
   target.
   
   <Amplitude>. Read product engagement metrics, which are usually the ones
   missing from the finance systems.
   
   <Zendesk>. Read support volume and satisfaction, which leadership asks
   about and nobody has to hand.
   
   <Slack>. Remind each owner to write their commentary before the meeting
   rather than during it.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This shows company performance against target, so set Access Control before sharing and be deliberate about who sees the whole page.

What it connects to

An executive dashboard is almost entirely reads, from every system that holds a number somebody quotes.

• Snowflake

  Read most metrics from the warehouse, where the definitions have already been applied consistently.

• Salesforce

  Read pipeline, bookings and retention where they are not already modelled in the warehouse.

• NetSuite

  Read revenue, margin and cash figures for the finance metrics.

• Looker

  Link each metric to the functional dashboard that owns it, so the executive view is the top of a path rather than a dead end.

• Okta

  Read the group that says who is on the leadership list, which is the only thing the app should check before showing performance against target.

• Amplitude

  Read product engagement metrics, which are usually the ones missing from the finance systems.

• Zendesk

  Read support volume and satisfaction, which leadership asks about and nobody has to hand.

• Slack

  Remind each owner to write their commentary before the meeting rather than during it.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides