What a Team Dashboard Is For: The Shared View of Now

Tuesday, 10:40, at Redbrook Engineering. Priya has run the three-person support desk for three weeks. Colin, the operations manager, has just leaned on the door frame and asked for "a dashboard, something I can glance at on the way past". There is already a screen on the wall. Her predecessor put it there, and it shows twelve numbers in twelve boxes, in a font you can read from about a metre away. Priya asks Joel, who has been on the desk two years, what the top-left number means. "That one's been forty-seven since I started," he says, not looking up. Meanwhile ticket 3318 is for a draughtsman who cannot open his design software because the licence expired on Friday. It has been sitting with no owner since Friday afternoon, and not one of the twelve numbers says so.

A team dashboard is the shared view of now. It has a small number of live figures, visible to the whole desk. Together they answer what is waiting, what is overdue, and who is free to take the next thing. It is not a report about last month, not a scoreboard of who closed the most, and not a decoration for visitors. This article is part of our Team Dashboards series. The series covers what the shared view is for and how to build the queue and personal views that feed it. It covers how to keep the dashboard from turning into surveillance and how to design a wall screen if you have one. It also covers how to keep every number on it honest. The twelve boxes at Redbrook fail all three of the tests in this article, and so, at first glance, will most dashboards you inherit.

It covers the difference between a dashboard and a report, then the three questions a team dashboard must answer. Next comes who reads it and when. It covers the three things it must not become, a scoreboard, a report and decoration, each in turn. Then come the tile test, with a table, and how to build one starting from the questions rather than the tool. It finishes with a short war story and the dashboard purpose card to copy, in that order.

A Dashboard Answers "What Now?", Not "How Did We Do?"

The single distinction that sorts out most dashboard arguments is the one between now and then. A dashboard shows the state of the desk at this moment, is read in a few seconds, and leads to an action in the next few minutes. The action might be to take that ticket, chase that one, or warn that requester. A report shows what happened over a period and is read in a few minutes. It leads to a decision over the next few weeks: hire, train, fix the printer fleet, change the form. Both are made from the same tickets. They answer different questions, for different readers, at different speeds, and a screen that tries to answer both answers neither.

The car dashboard is the one analogy worth borrowing, so borrow it once and then put it down. A car dashboard shows speed, fuel, temperature and a handful of warning lights, because those are the things a driver can act on while driving. It does not show average fuel economy over the last quarter, the service history, or a ranking of the household's drivers by miles per tank. Those are real and useful numbers; they belong in a document you read when the car is parked. The driver who tries to read a quarterly summary at speed is not better informed. They are about to be a different kind of statistic.

The practical consequence is that every figure on a team dashboard must be something that can change in the next hour. It must also be something somebody on the desk would do something about if it changed. "Unassigned tickets: 3" can change in a minute and tells a technician to go and take one. "Tickets resolved this month: 412" cannot change in a way anyone will act on before lunch. It belongs in the monthly report. The format that makes it useful is described in The Monthly Report They Will Actually Read. Two of the twelve boxes at Redbrook were month-to-date totals. They were accurate, large, and read by nobody, which is the natural life cycle of a total on a wall.

The Three Questions It Must Answer

The first question is what is waiting. And it has two parts: how many tickets have nobody promised to work, and how long has the oldest of them been waiting. An unassigned ticket is one the desk has received and no person has yet claimed. So the requester is waiting for someone who does not exist yet. The count tells you how busy the next hour is going to be. The age of the oldest tells you whether the desk kept its promise, and it is the more important of the two. Three unassigned tickets from the last ten minutes is a Monday morning. One unassigned ticket from Friday is a draughtsman who has been unable to work for a day and a half.

The second question is what is overdue, which means which promises have already been broken and which are about to be. Most desks make a promise about time for each ticket, usually by priority, called a service-level target. It promises a first response within so many working hours, a fix within so many more. A ticket past its target is overdue; a ticket inside the next hour of its target is due soon. The dashboard shows both counts, separately, because they call for different actions. The overdue one needs a message to the requester now. The due-soon one needs the owner to know. How the targets themselves are set is the subject of Response vs Resolution Targets; the dashboard only has to count against them.

The third question is who is free, and it is the one most dashboards forget because it is not a ticket count. A desk of three where two are at a site visit and one is in a meeting has nobody to take the unassigned ticket, however loudly the tile glows. The simplest honest answer is a list of names: who is on the desk now, who leads today, when the next shift change or handover is. Some desks add how many active tickets each person holds, which edges towards a scoreboard and needs the care described later in this series. Names and times are enough for most desks of ten or fewer. Software has been trying to work out who is free for decades; the rota still wins.

These three questions are answered by a handful of standing views inside the ticketing tool. Those are the same views every queue needs whether or not anything is on a wall. The views themselves, unassigned, mine, waiting on the requester, due soon and overdue, are defined and specified in What a Queue Is For. This series does not redefine them. A team dashboard is those views with the lists taken out and the counts left in, placed where the whole team can see them without clicking.

Who Reads It and When

A dashboard has three readers, and each reads it for a different reason at a different time. The technician reads it between tickets, in the gap after finishing one and before taking the next, to answer "what should I pick up?" The desk lead reads it at fixed times, on sitting down, after lunch and before leaving, to answer "is anything about to go wrong that nobody has noticed?" The manager walking past reads it in the time it takes to walk past, to answer "is the desk coping?" That last reader is the one Colin was describing. A dashboard that serves the first two will serve him, while one designed for him alone will serve nobody.

The reading has to be on a schedule or it is not happening. A screen in the corner that everyone could look at is a screen that everyone assumes someone else is looking at. A saved view that anyone could open is one that is opened when a requester phones. Write the times down: who reads which figure, and when. For a small desk, the technician's between-tickets glance plus the lead's three fixed reads a day covers everything. The three fixed reads take about thirty seconds each. A dashboard nobody reads on a schedule is a poster.

Decide, too, what each reader does when a figure is not zero, because a dashboard is only as useful as the action it starts. Unassigned above zero: the free technician takes the oldest. Overdue above zero: the owner, or the lead if the owner is away, messages the requester within the hour. Due soon above zero: the lead confirms each owner knows. Those three rules fit on a card, and the card is what turns a set of numbers into a routine. Without it, the numbers are observed, discussed, and occasionally photographed for a slide.

What It Must Not Become: A Scoreboard

A scoreboard is a dashboard that ranks people, and it is the commonest way a good shared view goes bad. The slide is gentle. Someone adds "tickets closed today, by technician" because it seemed harmless. Then someone sorts it. Then someone notices they are at the bottom because they spent the day on a network fault that was one ticket. By the end of the month the easy tickets are being claimed within seconds. The hard ones are being left for whoever has the least to lose. The ticket that most needed attention has become the one nobody wants to be seen holding. The full account of the damage, and what to put up instead, is in Dashboards That Motivate Instead of Surveil. Here the rule is just that the shared view shows the team's work, not the team's ranking.

Per-person figures have a place, and it is private. Each technician should be able to see their own numbers, their own open tickets, their own due-today list, their own reopens. Those are their own business, in their own view. The lead sees them one-to-one, for coaching, not ranking, and only once there are enough tickets behind a figure for it to mean anything. A technician's resolution time over nine tickets is nine stories, not a number. A sensible floor, and it is a floor rather than a standard, is somewhere between thirty and fifty resolved tickets and at least a month. Only then is any per-person figure read at all, and even then beside a quality figure such as reopens. On the wall, the team's total. On the technician's own screen, the technician's own figures. In the one-to-one, the conversation. That split does most of the work.

What It Must Not Become: A Report

The second slide is towards the report, and it happens because the report's numbers are easier to produce. Month-to-date volume, average resolution time, the satisfaction score, the trend line since January: all real, all useful, all slow. None of them changes in the next hour in a way anyone will act on. So putting them on the live screen teaches the desk that the live screen is background. Once two tiles are background, the eye learns to skip the screen, and the two tiles that were urgent get skipped with them. The report figures are not wrong. They are in the wrong room.

The test for whether a figure is a dashboard figure or a report figure is a question. What would be done differently in the next hour if it changed? Unassigned goes from two to five: somebody stops what they are doing and looks. Average resolution time goes from eleven hours to twelve: nobody does anything before the monthly review, and nor should they, because one afternoon's figure is noise. Which metrics are worth tracking at all, and how to define each so two people get the same number, is the subject of the Handful of Metrics Worth Tracking. The point for the dashboard is that most of that handful belongs in the report. A dashboard that carries them is a report that has been hung on a wall.

There is a sensible middle: a single "today" line showing tickets arrived and tickets resolved since midnight. It is a total, so it is information rather than a verdict. But it changes through the day and it answers the manager's glance question, "is the desk coping?", better than any average. Give it one tile, colour it as information, never as judgement, and keep it the only total on the screen. I have broken this rule myself, with a tile for "resolved this week" that I was proud of. And I watched the team work out within a fortnight that Friday afternoon was the best time to resolve things. The rule is there because the screen teaches.

What It Must Not Become: Decoration

The third slide is towards decoration, which is what the twelve boxes at Redbrook had become, and the symptom is a figure nobody can explain. Forty-seven had been forty-seven for long enough that it had stopped being a number and become part of the wallpaper. Decoration arrives in two ways. The first is accretion: every request for "one more number" is granted, because each is cheap to add. Nothing is ever removed, because nobody is sure what it was for. The second is default: the tool offers a dashboard with eight tiles pre-selected. The desk turns it on, and nobody ever asks whether the eight are the right eight. Both produce a screen that is looked at and not read.

Every tile must earn its place by naming the decision it changes, and if it cannot, it comes down. This sounds brutal and is the kindest thing you can do for the tiles that remain, because attention is the whole budget. A screen with four tiles that each mean something is read. A screen with twelve, four of which mean something, is skimmed. Skimming is how a red overdue count sits unnoticed between a satisfaction gauge and a bar chart of ticket sources. Dashboards breed when nobody is watching. Leave two tiles unattended and by the spring there are nine.

The table is the tile test applied to the kinds of figures that most often turn up on a desk's screen. The "decision it changes" column is the one to fill in honestly; where it is blank, the verdict follows. Keep means on the live dashboard. Report means it belongs in the monthly or weekly summary. Private means it belongs on the technician's own view and nowhere shared. Drop means it was decoration.

Build It From the Questions, Not From the Tool

Start with the three questions written on paper, before you open the tool's dashboard settings. The settings will offer you things and you will take them. Under each question, write the one or two figures that answer it, who reads each, when, and what they do when it is not zero. That page is the purpose card, and the template at the end of this article is one. Only once the card is full do you open the tool and look for the figures on it. Most tools can show the unassigned count, the overdue count and a due-soon count without any building, because they are the standard views with the lists hidden. If you run QuerySolv, the dashboard already shows what is waiting and what is overdue. In that case, each technician sees their own numbers. The purpose card still decides which of those figures the desk reads, when, and what it does about them. No tool can decide that for you.

Apply the counting test once the figures are up, because a dashboard can be honest about every tile and still miss tickets. The total of open tickets in the whole list should equal what you reach by adding the figures you read, allowing for a ticket that appears in two. If the whole list says twenty-nine and the dashboard's figures account for nineteen, ten tickets are living somewhere the dashboard does not look. That is usually a department nobody staffs or a status nobody filters. The same sum, done weekly on the standing views, is described in the queue article; the dashboard inherits it. Ticket 3318 at Redbrook was unassigned in a department called "Engineering Systems" that the predecessor had created for a project and never closed. It did not appear in forty-seven, or in any of the other eleven.

Build it small and let it be asked to grow, rather than building it large and hoping it will be pruned. A dashboard of four tiles that is read three times a day beats one of twelve that is glanced at from the door. And the four will attract requests for a fifth, each of which gets the tile test. Decline the ones that fail politely and with the test in hand: "What would we do differently if that number changed before lunch?" (Ask it twice. The first answer is usually "I'd just like to see it.") A figure somebody would like to see is a report. Give them the report.

Review the card quarterly, because the desk changes and the questions do not. A new department, a new shift pattern, a new service-level target or a new channel each changes which figures answer the three questions. A tile built for last year's desk can quietly be counting something that no longer exists. The review is ten minutes with the card and the screen side by side. It asks of each tile whether it still answers its question and whether anyone still acts on it. And it is the first half of the routine described in Keeping Dashboards Honest, which owns the harder question of whether the figure is even true.

A Short War Story: The Forty-Seven at Tollgate Foods

At Tollgate Foods, a food distributor with a four-person desk, the wall screen had shown a tile labelled "Open" reading forty-seven for most of a quarter. The desk lead, a man called Darren, had come to treat it as the desk's natural weight, the way you stop noticing the hum of a fridge. The forty-seven was open tickets across every department. Thirty-one of them belonged to a "Warehouse Systems" department that had been set up for a scanner rollout. They were routed by a form that was still linked from the warehouse intranet page. The department had been staffed by nobody since the rollout ended. The tickets in it included a scanner that would not charge and a label printer that printed blanks. They included a shift supervisor who could not log in to the stock system and had been given a colleague's login instead, for eleven weeks. The desk found them when the warehouse manager complained to the finance director. The director asked Darren why the screen said forty-seven if the desk was "on top of things". The cost was about thirty hours of catching up on tickets that should have taken minutes each when fresh. It included one audit finding for the shared login and a conversation with the finance director that Darren described afterwards as "character-building". A number nobody can explain is not a number. It is a place for tickets to hide in public.

The Dashboard Purpose Card

The card below is one page, filled in once per dashboard and pinned beside the screen or saved beside the view. It is the whole design. Fill in the three questions first, then the figures that answer them. Then fill in who reads each and when, then the action for each when it is not zero. Section D is the tile test for anything somebody asks to add; a figure that cannot complete the "decision it changes" line does not go on. Section E is the counting test, done weekly. The card is deliberately short, because a dashboard that needs a long card to explain it has already become something else.

DASHBOARD PURPOSE CARD — ONE PAGE
Desk: ______________________   Dashboard: ______________________   Owner: ______________
Where it is shown: [ ] wall screen  [ ] browser tab  [ ] tool start page   Date of this card: ________

A. THE THREE QUESTIONS AND THE FIGURES THAT ANSWER THEM
   What is waiting?
     Figure: unassigned count ............ definition: open, no owner, in departments: ______________
     Figure: age of the oldest unassigned . shown as: ____ minutes / hours
   What is overdue?
     Figure: overdue count ............... definition: open, past the service-level target
     Figure: due in the next ____ ........ definition: open, target inside the window, not yet past
     Figure: waiting on us, untouched .... definition: next step is the desk's, no desk update for ____
   Who is free?
     Figure: names on the desk now ....... source: the rota   next handover at: ____:____
     Figure (information only): arrived / resolved since midnight

B. WHO READS WHAT, AND WHEN
   Technician ......... between tickets: unassigned, due soon
   Desk lead .......... on sitting down, after lunch, before leaving: all figures
   Manager passing .... arrived / resolved today, overdue
   Fixed read times today: ____:____   ____:____   ____:____

C. THE ACTION WHEN A FIGURE IS NOT ZERO
   Unassigned > 0 .......... the free technician takes the oldest; if nobody is free, the lead assigns
   Overdue > 0 ............. owner (or lead if owner away) messages the requester within the hour
   Due soon > 0 ............ lead confirms each owner knows the time
   Waiting on us > 0 ....... owner touches it today or hands it over
   Oldest unassigned > ____  lead stops project work and takes it personally

D. THE TILE TEST (for anything someone asks to add)
   Figure proposed: ____________________________   Asked for by: ______________
   Question it answers: ________________________________________________________
   Decision it changes in the next hour: _________________________________________
   Verdict: [ ] keep   [ ] report   [ ] private view   [ ] drop

E. THE COUNTING TEST (weekly)
   Total open tickets in the whole list: ____
   Sum of tickets covered by the figures above (less double counts): ____
   Difference: ____   Where the missing tickets live: ______________________   Fixed: [ ]

F. NOT ON THIS DASHBOARD, BY DECISION
   [ ] any figure ranked by person     [ ] any month-to-date total except arrived / resolved today
   [ ] any average                     [ ] any figure whose definition is not written above

Priya filled in the card at Redbrook on the Tuesday afternoon and took down nine of the twelve boxes on the Wednesday. That prompted one complaint, from the person who had built them, and no others. The screen now shows unassigned with the age of the oldest, overdue, due in the next hour, and waiting on us. It shows the three names on the desk, and arrived against resolved for the day. Colin glances at it on the way past, as requested. Joel reads it between tickets, which nobody requested, and the forty-seven has not been seen since. Ticket 3318 was claimed within four minutes of the unassigned tile going live, by Joel, who said he had been meaning to look at that department.

Frequently Asked Questions