Most dashboards are built for a desk. This one was for a room.
Most of the dashboards I build are for a person sitting alone at a desk. This one was for a room.
In construction sales there's a recurring meeting that most firms run in some form. Pursuit review, pipeline call, whatever the house name is. Leadership and business development sit down and walk the book out loud. Which bids are live. What each is weighted at. What has gone quiet. What needs a go or no-go decision before the deadline closes.
I built the screen you put up during that meeting, and then I sat in one, which changed what I understood the screen to be for.
That was the first surprise. By the time everyone is in the room, most of the real calls have already been made, in smaller circles, by two or three people who talked it through beforehand. The meeting confirms them out loud.
That sounds like a criticism and it isn't. Small groups are where hard decisions actually get made in most organizations, and expecting nine people to reason from scratch about a bid is not realistic. But it means the meeting's function is not what the artifact implies. It isn't a decision forum. It's a synchronization ritual, and its most valuable moments are the ones where somebody who wasn't in the hallway conversation hears the outcome for the first time and says wait, why.
Which is a completely different design target. A decision support screen is optimized to help you choose. A synchronization screen is optimized to make what was already chosen legible fast enough that somebody can object before it hardens.
The go or no-go decisions themselves are less arithmetic than the software implies. Sometimes there's a model, or at least a scoring rubric. More often it comes down to two things: do we have a real relationship here, and can we prove we've done something like this before. Those are the actual criteria, and they're reasonable criteria. They're also almost entirely unrepresented in a standard pipeline view, which will happily show you weighted revenue and tell you nothing about whether you know the owner.
One small thing I noticed and would not have guessed. Nobody refers to a pursuit by its name in the system. They say the client and the location, or the client and the project type. The record has an official name and the room has a different vocabulary, and everybody translates between them without noticing.
A pile of spreadsheets.
The pursuit list in one file. Billing projections in another. Target wins in a third. The best and final offer process, which is the last round pricing move on a competitive bid, running through a separate form in a different tool entirely.
Nobody had a single reconciled picture. Somebody built one by hand before every meeting, and in between, the lists drifted quietly out of sync with each other and with the CRM.
The artifact I was handed to replace was named after the meeting rather than after what it displayed. That naming tells you what the thing actually is. The software was never the point. It was the screen you point at while people talk.
So the goal was never to add one more view alongside the spreadsheets. It was to replace them with one screen, editable in place, that is the record rather than a report about it.
The dashboard leans on win probabilities. When I asked where those percentages came from, there was no methodology behind them. Not a model, not historical win rates by pursuit type, not anything you could reconstruct. Someone had assigned numbers that felt right.
Here's the part I find genuinely interesting. The organization knew this. It wasn't a secret or an embarrassment. There's a widely shared understanding that the percentage reflects the judgment of someone experienced, and that this judgment is itself the qualification. The gap between the number and any underlying method gets accepted, and named expertise.
And there's something real in that. People who have chased work in a market for twenty years do have calibrated instincts about which pursuits are live. I'd trust that instinct over a naive model built on thin data.
The problem isn't the instinct. It's what happens after the instinct becomes a decimal. Sixty-five percent feels like a considered judgment when it's said out loud in a room by someone who's earned the right to say it. The same sixty-five percent gets multiplied by a contract value, summed with forty others, and lands in a board report as arithmetic. Nothing downstream remembers it started as a feeling. The precision is manufactured somewhere between the person and the spreadsheet, and nobody chose to manufacture it.
That's the interesting problem in this space, and I don't think it's solved by taking the judgment away from the people who have it. It's solved by making the assumption visible and checkable, so a seasoned instinct can be compared against what actually happened the last forty times something similar came up. The expertise stays. It just stops being unfalsifiable.
The rest of the inputs weren't much firmer. Executed revenue arrived through a manual export from the accounting system rather than a live connection, so anything labeled actuals was only as current as the last time somebody ran it. And in my own demo environment the goals were mis-scaled by a factor of eighty-five, which meant the forecast cheerfully reported seven thousand percent attainment for a while before I caught it. A dashboard is exactly as honest as the numbers behind it, and mine was briefly lying with enormous confidence.
So I stopped designing for clean data and started designing for missing data.
The win probability layer became adaptive: weighted bands when real modeled numbers exist, a plain by-stage view when they don't. When it became clear the percentages weren't grounded in anything, I didn't delete the math, since the underlying attainment weighting had been reviewed and signed off. I parked the visible percentage instead. The calculation stayed, the number came off the screen.
The AI summary I added later follows the same rule. Aggregates only, never record contents, advisory, and unable to modify a single record.
All of it organized around one idea. This is a meeting screen, so it must never force the presenter to defend a number nobody can stand behind.
Once I'd sat in the meeting I started noticing how often people left the screen, and it wasn't only to find things that were missing. A lot of it was verification. Somebody would look at a total and go check whether it was real.
That's the behavior worth designing against, and it makes a decent general heuristic. Count how many times people leave your dashboard during a meeting, and why. Every exit is the screen failing to make its own numbers credible on their own terms.
A figure with no visible derivation isn't usable in a room no matter how accurate it is. It just moves the argument into a different window.
The numbers were never the hard part. Summing weighted pursuits by region is arithmetic, and any competent build gets it right. What's hard is presenting a total in a way that survives somebody senior asking where it came from.
So the thing I was actually building toward, and I can say this more clearly now than I could at the time, was a single view that explains itself. Every number traceable to what produced it. Drill from a total into the pursuits behind it without losing your place. Correct something on the spot when the room agrees it's wrong, instead of writing it on a legal pad to fix later, which nobody ever does.
Some of that exists. The billing spread swaps views in place and is editable where it needs to be. A lot of it doesn't. The explanation layer in particular stayed mostly an intention, which is the honest status of it.
Activity, and it's the same failure as everything above.
The thing people reached for most often during the meeting was the one thing the screen didn't show. When did we last touch this, and what happens next.
I had built a triage strip flagging what was stale and what was slipping, which is the aggregate version of that question. But the aggregate version is a conclusion, and what the room wanted was the evidence. A badge saying a pursuit has gone quiet is the dashboard asserting something. The date of the last conversation and the name of whoever had it is the dashboard showing its work. You can act on the second one in front of people. The first one you have to go verify, which is exactly what everybody did.
That's a clean miss, and the kind I should have caught earlier. I designed for the report rather than for the conversation happening over the top of it.
This is the thin part and I'd rather leave it thin than dress it up.
It was demonstrated to the customer, who engaged seriously. Seriously enough to push back with specific, informed criticism rooted in how they actually work. They wanted Excel export. They expected billings in every consecutive month, not just the ones with activity. They wanted the best and final offer form to replace their existing one exactly, not approximately. And they challenged the win percentage math directly, which was the right challenge.
That pushback is the real signal. You don't get feedback that precise about something that doesn't already map onto how you work. Vague praise means it didn't land. Specific complaints mean it did.
What I can't tell you is that it became the live screen in a real meeting. It lived in a sandbox and a demo environment. The win percentage question was parked pending a larger conversation with people who hadn't been in the room yet. A key user was still waiting on a login. Every impressive figure in the screenshots is seeded demo data and belongs to nobody.
So the honest word is pre-adoption. It survived contact with real users' criticism. It had not been turned on as the thing they run the meeting from.
For a site that keeps arguing about the gap between built and used, that's a more useful place to end than a number I'd have to invent. Which would be a strange way to close a story about refusing to display numbers you can't defend.