Dashboards and Reporting in Openbook: Numbers Without Spreadsheet Sprawl

Here is how reporting works at most companies. On Thursday afternoon, someone exports the project board to a spreadsheet. They massage it into a pivot table, screenshot two charts into a slide deck, and present it Friday morning — at which point the numbers are already a day old and the spreadsheet joins forty of its siblings in a folder no one will open again. Next Thursday, the whole ceremony repeats.

The problem isn't effort. It's architecture: the numbers live where the work happens, but the reporting happens somewhere else, so a human has to ferry data between the two — every week, forever.

Openbook removes the ferry. The Dashboard is one of Openbook's 18 room types: a drag-and-resize reporting canvas whose widgets are wired live to your boards. The board is the source of truth; the dashboard is a window onto it. When a card moves or a status changes, the dashboard is already right. Nobody exports anything, and Thursday afternoon goes back to being a workday.

This guide covers the whole practice: the widget catalog, how to wire widgets to boards, how to design views for executives versus teams, where manually entered data fits, and — the part most teams skip — the review rituals that keep a dashboard from becoming wallpaper.

Where dashboards live in Openbook

Quick orientation for new readers: Openbook organizes work as Organization → Space → Room. A space belongs to a team, department, or project, and it's composed of rooms — a Kanban Board for sprints, a Table Board for structured data, a Feed for updates, and so on. A Dashboard is just another room you add to the space.

That placement has consequences:

• A dashboard sits next to its sources. The boards it reads from are rooms in the same workspace, one sidebar click away. Anyone who wants the story behind a number can walk from chart to cards without changing tools.
• You can have several. Dashboards are rooms, so a space can hold more than one — a team-facing operational view and a stakeholder-facing summary view, each scoped to its audience.
• Access is governed like everything else. Space roles (Owner/Admin/Member/Viewer) and per-room visibility apply, which is what makes exec and client views practical. More on that below.

Dashboards are part of Openbook's Pro plan ($15/user/month, $12 annual), which carries a 14-day free Pro trial — so you can build everything in this guide before paying anyone.

The widget catalog

The Dashboard canvas offers a deliberately small set of widgets. Small is a feature: every widget type answers a distinct question, and a dashboard built from them stays readable.

Widget	The question it answers	Typical use
Stat tile	"What's the number right now?"	Open bugs, deals in pipeline, tickets this week
Progress bar	"How far along are we?"	Sprint completion, quarterly goal, migration status
Bar chart	"How does it break down?"	Cards by status, deals by stage, requests by team
Donut chart	"What are the proportions?"	Work by type, pipeline by source
Recent-cards table	"What's actually moving?"	Latest cards from a board, live
Manual-data widget	"What about numbers outside any board?"	Revenue, headcount, NPS
Text widget	"What does this mean?"	Context, definitions, owner and cadence notes

Three of these deserve emphasis.

Stat tiles are the workhorses. A row of four tiles across the top of a dashboard — the numbers this team is actually accountable for — does more than any chart forest below it. If a visitor reads only the top row, they should leave correctly informed.

The recent-cards table is the credibility widget. Charts summarize; the recent-cards table shows the real, current cards from a board — which is what convinces a skeptical stakeholder that the dashboard isn't a brochure. It's also the bridge from "the chart looks wrong" to "here's the card that explains it."

Text widgets are the most underused. A dashboard without words forces every viewer to guess what "Active" includes or why the target is 40. A two-line text widget — what this measures, who owns it, when it's reviewed — converts a chart collection into a report.

Wiring widgets to boards

The live connection is the whole point, so it's worth understanding what feeds it. Board-connected widgets — the stat tiles, progress bars, bar and donut charts, and recent-cards tables — read from your Table Board and Kanban Board rooms. What they can show is a function of how those boards are structured, which leads to the first law of dashboarding: your dashboard is only as good as your board hygiene.

Concretely, the structure that makes boards chartable:

• Status columns and board columns. A bar chart of cards by status is only meaningful if statuses are used consistently. Five well-defined statuses beat eleven improvised ones.
• Number columns. Table Boards support number columns among their 9 column types (text, number, status, people, date, tags, checkbox, dropdown, progress) — deal values, hours, counts. Numbers you want to aggregate must live in number columns, not in text.
• Progress columns and story points. Progress-style data gives progress bars something honest to show; a Kanban board's story points make "how much is left" a real quantity rather than a card count.
• Groups. Table Board's colored draggable groups (pipeline stages, request categories, quarters) give charts their natural breakdowns.

The workflow, then, is a loop: build the board for the work first, wire widgets to it, and when a widget can't answer a question you care about, fix the board — add the status, the number column, the group — rather than working around it in the dashboard. Teams that do this find their boards improve as a side effect of reporting, because vagueness that survives on a board becomes visible on a chart.

One discipline note: resist wiring a widget to someone else's board without talking to them. A chart is an interpretation, and the people who maintain the board should agree it's a fair one — otherwise your dashboard will win arguments it shouldn't.

Building your first dashboard: a walkthrough

Here's the method, using a software team's delivery dashboard as the example. The same steps apply to any team.

1. Write the questions before touching the canvas. A dashboard is a set of answers; list the questions first. For this team: How is the sprint going? What's our bug situation? What shipped recently? Anything at risk? Four questions — which is about right. If you have ten, you're building two dashboards.
2. Add a Dashboard room to the space. Name it for its audience ("Delivery — Team View"), because you'll likely add a second view later.
3. Lay the top row: stat tiles. Open bugs. Cards in the current sprint. Cards done this sprint. Wire each to the relevant board. Top-left is the most-read position on any dashboard — put the number you'd want to be asked about first there.
4. Add the progress bar for sprint completion, wired to the sprint. This is the glanceable "are we on track" answer.
5. Add one bar chart — cards by status — and, if work type matters, one donut of the sprint by card type (feature/bug/chore). Two charts. A dashboard with eight charts answers nothing quickly.
6. Add the recent-cards table showing the latest cards from the board, so the dashboard ends in reality: actual work, moving.
7. Annotate with text widgets. One at the top: what this dashboard covers, who owns it, that it's reviewed Fridays. One next to anything with a non-obvious definition.
8. Drag and resize until the layout tells the story. The canvas is freeform: importance = size and height on the page. Big tiles up top, detail below, nothing that requires scrolling to understand the headline.

Total build time for a team with clean boards: well under an hour. If it's taking a full day, the boards are the problem — go fix them first, and the dashboard becomes easy.

Example builds for three teams

Sales pipeline (Table Board source). Start the board from one of the Table Board's roughly 40 templates — there's a sales pipeline among them — with groups as stages and a number column for deal value. Dashboard: stat tiles for open deals and new-this-month; a bar chart of deals by stage (your funnel, live); a donut by source; a recent-cards table of the latest deals. The Friday pipeline meeting stops beginning with "let me pull the numbers."

Marketing content calendar (Table Board source). Board groups by month or campaign, status column for draft/review/scheduled/published, tags for channel. Dashboard: tiles for in-production and published-this-month; bar chart by status to spot the review-stage pileup; donut by channel to show mix; recent-cards for what just shipped.

Ops request queue (Kanban source). Tiles for open requests and completed-this-week; bar chart by status to make the backlog visible; recent-cards for what's in flight; a text widget stating the team's response expectations, so the dashboard doubles as the SLA's public face.

Different teams, same grammar: top-row tiles, one or two breakdowns, live cards, words.

Manual data and text: the numbers outside your boards

Not everything lives on a board. Revenue, headcount, NPS, uptime — some numbers come from systems outside Openbook or from a monthly finance close. The manual-data widget exists for exactly this: you enter the figure, and it sits alongside the live widgets so the dashboard can tell a complete story.

Use it deliberately, because manual data reintroduces the one failure mode live widgets eliminated: staleness. Three rules keep it honest:

1. Every manual widget has an owner and a cadence — stated in an adjacent text widget ("Updated monthly by finance, first week"). An unlabeled manual number is a rumor with a font size.
2. Update it inside a ritual, not from memory. If the monthly review opens with "refresh the manual widgets," they're never stale; if updating depends on someone remembering, they always are.
3. Prefer wiring over typing when possible. If a number could live as a number column on a Table Board that a team actually maintains, put it there and wire it — the manual widget is for genuinely external figures, not for avoiding board hygiene.

Used this way, manual-data widgets are how a leadership dashboard mixes "live from the work" metrics with "official as of the close" metrics without pretending they're the same kind of number.

Exec views and stakeholder views

The team's dashboard and the executive's dashboard answer different questions, and forcing one canvas to serve both ruins it for both. Build two rooms:

• The team view is operational: statuses, queues, recent cards, the numbers the team steers by daily.
• The exec view is a one-page summary: a handful of stat tiles, one or two trends' worth of breakdowns, RAG-relevant progress, and text widgets giving the "so what." If it doesn't fit without scrolling, it isn't an exec view yet.

Openbook's access model makes the split cheap. Give stakeholders the Viewer role — they see everything they need and can't move a card by accident — and use per-room visibility to control which rooms each audience sees at all: the exec dashboard visible broadly, the working boards and team dashboard scoped to the team. Agencies run the same pattern for clients — a client-facing dashboard room in the project space, wired to the delivery board, with the internal rooms invisible to the client. The full access model is covered in our permissions setup guide, and the agency version in running an agency on Openbook.

One pairing worth adopting for exec reporting: dashboard plus Project Status room. The dashboard carries the numbers; the Project Status room carries the narrative — standing questions answered on a cadence, a goals board with RAG status, and updates with a history timeline. Numbers without narrative invite misreading; narrative without numbers invites spin. A stakeholder who gets both, async, stops scheduling meetings to ask for either.

Analytics already built into rooms

Not every metric needs a dashboard you assemble — several Openbook rooms ship their own analytics, and knowing what's already there saves you from rebuilding it:

• Kanban sprint insights — how the sprint went, natively, feeding sprint reviews and retros.
• Check-in Team Pulse — mood and participation trends from async check-ins and pulse surveys, with publishable digests.
• Q&A analytics — what's being asked, revealing documentation gaps.

The division of labor: room-native analytics serve the team inside the room's own ritual; the Dashboard room composes the cross-room, cross-audience picture. Use each for what it's for, and don't hand-copy a room's analytics onto a canvas — link people to the room instead.

Scaling up: portfolio and leadership reporting

Once one team runs a live dashboard, the pattern scales upward naturally, because dashboards are rooms and rooms compose.

Each team's space keeps its own operational dashboard, wired to its own boards. For leadership, create a dedicated space — call it Leadership or Portfolio — containing a Dashboard room built for the cross-team question: a stat tile row per team or per initiative, progress bars for the quarter's major commitments, manual-data widgets for the company-level figures (revenue, headcount) that no team board holds, and text widgets naming an owner for every number. Pair it with a Project Status room where each initiative lead answers the same standing questions on the same cadence, with RAG status on goals — so the portfolio view is numbers plus narrative, not numbers plus a meeting.

Two practices keep a portfolio view honest. First, don't duplicate team dashboards upward; summarize. Leadership needs the tile, not the team's recent-cards table — and anyone who wants depth can open the team's space, since it's all one workspace with one global ⌘K search across it. Second, review the portfolio view on its own cadence — monthly is typical — and let that review be where kill-or-continue questions get asked. A portfolio dashboard that never changes anyone's plans is a screensaver. For the broader discipline, see running a portfolio of projects without losing the plot.

Where the AI assistant fits

Openbook's global AI assistant takes real actions across the workspace — around 25 tools, with confirmation required before anything destructive, and bring-your-own-key support for Anthropic, OpenAI, and DeepSeek. For reporting work, it earns its keep in three places:

• Preparing sources. Pasting a messy list of requests and having the assistant create the cards puts data on the board — which is what makes it chartable — without the transcription slog.
• Narrating numbers. Ask it to summarize the current sprint or draft the weekly status update from the board's state; the dashboard shows the what, the assistant drafts the so-what, and a human edits before posting.
• Answering the long tail. The one-off questions ("how many cards did we close this month?") that would otherwise spawn a temporary widget can just be asked. Dashboards are for the recurring questions; the assistant absorbs the rest, which keeps your canvas small.

The assistant drafts and fetches; the review ritual and the humans in it stay responsible for what the numbers mean.

Anti-patterns: how good dashboards go bad

A short field guide to the failure modes, so you can name them when they appear:

• The wall of charts. Twenty widgets, no hierarchy, nothing readable in under a minute. Cause: adding without pruning. Fix: return to the question list; one dashboard per audience, one screen per dashboard.
• The vanity board. Every number only ever goes up, and none has ever changed a decision. Fix: for each widget ask "what would we do differently if this moved?" No answer, no widget.
• The stale manual tile. A manual-data widget last touched two months ago, quietly poisoning trust in the live ones beside it. Fix: owner and cadence in a text widget, refresh inside the ritual, or delete it.
• The secret dashboard. Numbers about a team that the team can't see breed exactly the status anxiety they were meant to cure. Fix: default dashboards open to the people they measure; use per-room visibility for genuinely sensitive views, not for convenience.
• The re-export. Screenshotting live widgets into a weekly deck resurrects the ferry this whole system was built to retire. Fix: send the dashboard's room link, grant Viewer access, and let the deck die.

The review ritual: dashboards decay without one

Here's the uncomfortable truth about every dashboard in every tool: unread dashboards rot. Not the data — Openbook's live wiring keeps the numbers current — but the relevance. Teams change what they care about, and a dashboard nobody reviews keeps answering last quarter's questions with this week's data.

The fix is to attach every dashboard to a recurring ritual:

1. The team dashboard opens the weekly review. Five minutes, top row first: what moved, what surprised us, which number demands a decision. If a widget hasn't influenced a decision in a month, remove it — empty space is more honest than an ignored chart. Our weekly review guide covers the surrounding agenda.
2. The exec view anchors the reporting cadence. The status update posted in the Project Status room references the dashboard rather than restating it; stakeholders learn the numbers are always live, which is what finally kills the "can you send me the latest deck" email.
3. Manual widgets refresh inside the ritual, per their stated cadence.
4. Quarterly, prune. Rewrite the question list from step one of the build; delete widgets that no longer answer a live question. A dashboard that only ever grows is a dashboard on its way to being ignored.

And a norm worth stating out loud: dashboards are for steering, not surveillance. The moment a dashboard is used to rank individuals, people start managing the metric instead of the work, and every number on the canvas gets quietly worse. Measure the work; discuss the people in person. On honest goal reporting and the RAG discipline that pairs with it, see goals that stick.

Next steps

The whole practice, compressed:

1. Fix one board — clean statuses, real number columns, sensible groups.
2. Write four questions the team keeps getting asked.
3. Build one dashboard answering them: tiles on top, two charts, recent cards, text widgets for meaning. Under an hour.
4. Attach it to one ritual — the weekly review — and let the Friday export ceremony die unmourned.
5. Add the exec view once the team view has survived a month of Fridays.

Dashboards ship with Openbook's Pro plan ($15/user/month, $12 annual, 14-day free Pro trial) — details at pricing, platform overview at /product. The spreadsheet folder can keep its forty pivot tables as a museum. Your numbers live with the work now.