Module 3 · Reporting and alerts · Lesson 8 of 13 · 15 minutes to build
Build or use a dashboard
Leadership answers its own standing questions, and your Friday summary email stops being a task.
The BMS scenario
Your team wants one page that shows what's moving across the states BMS covers, without anyone assembling it by hand.
When to use it
Once per issue set at the start of session, then daily as a working view.
Why it matters
A dashboard that leadership trusts removes you from the critical path of every status question. If it's built around questions nobody actually asks, it gets ignored and the manual email comes back — so the questions have to come first, not the layout.
Before you start
- A clean, tagged sheet — a dashboard only ever reflects the sheet under it.
- The three questions leadership actually asks, written down.
Field guide
- Component data source
- Always point at the live sheet or filtered view, never a pasted or exported snapshot — a static component defeats the purpose within a week.
- Filter attached to each component
- Filter by issue, state, or stance to match the specific question the component answers, not a general 'everything' view.
- Sharing / access settings
- Share explicitly with the people who need it rather than relying on a broader default; confirm they can actually open it, not just that they're listed.
If your situation is different
- If leadership wants a session-end recap rather than a live standing view, build it as a point-in-time export from the dashboard rather than retrofitting the live dashboard into a static report.
- If different leaders ask different questions, build separate small dashboards per audience rather than one dashboard trying to answer everyone's question at once.
- If the underlying sheet isn't clean yet (missing tags or stances), fix the sheet first — a dashboard on a dirty sheet just makes the mess visible to more people, faster.
Step by step
Steps describe the general Quorum workflow. What your seat shows depends on the BMS subscription — check with your Quorum admin if a control isn't there.
- 1
Get the sheet right first
A dashboard inherits whatever the underlying sheet contains. Confirm the sheet is filtered, tagged and owned before you visualise it.
Do this in Quorum
- 1.1Write the three questions first: 'what moved?', 'what's at risk?', 'where are we opposed?' or your equivalents.
- 1.2Each question becomes one dashboard component — nothing else goes on the page.
- 1.3Confirm the questions with whoever actually reads the dashboard, not just your own guess.
You know it worked when: You can name each component after a question someone actually asked.
- 2
Decide the three questions the dashboard answers
For example: what's new this week, what's moving in committee, and where do we have a stance. Three answers beats twenty widgets nobody reads.
Do this in Quorum
- 2.1Create the dashboard and point each component at the live sheet, filtered by issue, state or stance.
- 2.2Never paste static counts; the point is that it updates without you.
- 2.3Name each component after the question it answers, not the underlying filter.
You know it worked when: Changing a stance on the sheet changes the dashboard.
- 3
Add views by state and by issue
Your team asks questions both ways — 'what's happening in Texas' and 'what's happening on PBMs' — so build both cuts on the same data.
Do this in Quorum
- 3.1Order components the way the conversation runs: status first, then risk, then positions.
- 3.2Delete anything that is interesting but not asked for.
- 3.3Check that the dashboard fits without scrolling on the screen size it'll actually be viewed on.
You know it worked when: The dashboard fits one screen.
- 4
Share it and make it the default link
Put the dashboard link in the recurring meeting invite so nobody rebuilds a status slide.
Do this in Quorum
- 4.1Share it with the people who ask the questions and confirm they can open it.
- 4.2Send the dashboard link instead of a summary the next time you're asked.
- 4.3Ask one recipient to open it live in front of you once, to catch access issues early.
You know it worked when: Someone other than you opened it successfully.
Common mistakes
Building components around what's interesting rather than what was asked.
Fix: Delete any component that doesn't map to one of the three written questions.
Pasting a static count or screenshot instead of linking a live filter.
Fix: Always point components at the live sheet so they update without manual work.
Sharing the dashboard without confirming recipients can actually open it.
Fix: Have one recipient open it live before you rely on it for a real readout.
Letting the dashboard grow past one screen over time.
Fix: Review it periodically and remove components that no longer map to a live question.
Prompts to run in Quincy, inside Quorum
Quincy is the agentic layer in Quorum — it works on your live data. Copy a prompt into Quincy after you log in. If you want the steps explained first, ask the site guide.
- "Turn this dashboard's current state into a three-bullet summary for a leadership email."
- "Which tracked bills changed status this week, grouped by risk level?"
Practice it now
- 1) Rebuild your last manual leadership email as a dashboard and send the link instead.
Done looks like this
- One shared dashboard per standing question.
- No hand-assembled recurring summaries.
When to stop and ask
If a recipient can't open the dashboard or a component doesn't reflect sheet changes, confirm sharing settings and refresh behavior with a Quorum admin or the BMS account team (Michael Fuentes, michael.fuentes@quorum.us) before assuming it's a training issue.
