Personal Workload Views: The Technician's Own Numbers

Wednesday, 08:55, at Stonebridge Insurance. Amara is one of five on the desk and she has nineteen open tickets with her name on them. Three are due today, one of them by ten. Two have replies from requesters that arrived after she left last night. One, 7781, was resolved on Monday and reopened at 22:14 by a claims handler who wrote "still happening" and nothing else. The team's queue view, on the wall and on her second screen, shows none of this, and it is right not to. None of the nineteen is unassigned, none is overdue yet, and the wall is for the desk's work, not hers. What Amara needs at 08:55 is a view that is hers. It answers "what do I owe today, and what has changed since I last looked?" Nobody else is reading it over her shoulder.

A personal workload view is the set of tickets one technician owns, narrowed to what needs them now and read by that technician alone. The lead is able to see it only for cover. It is the second view a technician opens each morning, after the shared one, and the view they live in between. This article is part of our Team Dashboards series. It is about the four lenses that make up the personal view, and why the figures in it are the technician's own business. It covers how to read it often enough to keep promises without reading it so often that nothing else gets done.

It starts with the four lenses, mine, due today, waiting on me and reopened, with a table. Then it covers why "mine" is the second view and not the first, and each of the other three lenses in turn. Next come why the view is private and what the lead may do with it, and how often to read it. Then comes how many active tickets is too many, as a worked example. A short war story and the personal view specification to copy finish the article.

Four Lenses on One Person's Work

The personal view is four filters on the same list of tickets the technician owns, and each answers one question. Mine is everything open with the technician's name on it, and answers "what have I promised, in total?" Due today is the subset whose service-level target falls before the end of the working day. That target is the time promise attached to the ticket by its priority. This lens answers "what must I finish before I leave?" Waiting on me is the subset where somebody has done something since the technician last touched the ticket. That could be a requester reply, a colleague's note, or a supplier's answer. This lens answers "what has changed that I have not seen?" Reopened is the subset that was resolved and has been opened again, and answers "what did I think was finished and is not?"

Four is the number because each lens starts a different action, and a view that mixes them makes the technician re-sort it in their head every time. The table gives each lens with its filter, its question and when it is read. The filters are built from fields every ticketing tool has, owner, status, due time, last update and who made it. So none of this needs a report or a plug-in. What it needs is the four saved under those names and opened in that order.

Mine Is the Second View, Not the First

A technician who starts the day in "mine" is starting inside their own pocket, and the desk's shared list is what they have skipped. The queue, one list of everything open, with the unassigned and overdue counts read first, is defined in What a Queue Is For. The morning routine is to read that first, take anything unassigned that is older than it should be, and only then open "mine". The order matters because "mine" is comfortable. Everything in it has a name on it, and nothing in it is a surprise. A desk where everyone works from their own view all day is a desk where the shared list belongs to nobody.

The "mine" lens itself does one job well: it tells the technician how much they are carrying before they take anything else. Nineteen tickets is a number. The useful number is how many of the nineteen are active, meaning the next step is Amara's. That is as opposed to parked in a waiting status where the next step is a requester's or a supplier's. Amara's nineteen were eleven active and eight waiting. Eleven is what she compares against the capacity figure described later in this article before claiming a twelfth. The rules about claiming from the shared queue, and what happens when one person claims too much, are in Team Queues vs Personal Queues. The personal view's part is to make the "how many do I already have" question answerable in one glance.

Sort "mine" by last update, oldest at the top, rather than by number or priority. That is because the ticket at the top of that sort is the one the technician has been avoiding. Everyone has one. (Mine was a printer. It is always a printer.) The routine is a weekly look at the top three of "mine" by oldest update. For each, the decision is to work it, hand it over or park it honestly with a follow-up date. That keeps the personal list from growing the quiet layer of tickets that the shared waiting-on-us count will eventually expose anyway, less kindly.

Due Today: Promises With a Time on Them

The "due today" lens is the day's plan. It is sorted by the target time, earliest first, because the order of work is the order of promises. Amara's three were due at ten, at one and at four. So the morning belonged to the ten o'clock ticket and nothing else until it was either resolved or the requester had been told a new time. A target is a promise with a clock on it. The clock side of a desk, response and resolution targets and what to promise, is the subject of the SLA Design series. The personal view's job is only to put today's promises in front of the person who made them, in order.

The rule that makes this lens worth having is that a time about to be missed is told to the requester before it passes, not after. A technician who sees at eleven that the one o'clock ticket cannot be done by one sends a line at eleven: "I will not have this fixed by one; I expect to by three, and I will tell you if that changes." The requester now has a new time and the ticket is still a kept promise in the only sense that matters to them. The same ticket discovered at ten past one is a broken promise, an apology, and a requester who has learned that the desk's times are decorative. Read "due today" after lunch and mid-afternoon as well as in the morning, because the afternoon targets are the ones the morning's surprises push off the edge.

Show the end of the working day, not the calendar day, in the filter. That is because a ticket due at 17:30 on a desk that closes at 17:00 is due tomorrow in every practical sense. A filter that counts it today sends somebody home late for nothing. Most tools that calculate targets on a business-hours schedule place the target inside working time already. Check what yours does with a ticket raised at 16:50 on a two-hour target, and set the lens to match.

Waiting on Me: The Reply You Have Not Seen

The "waiting on me" lens catches the moment a ticket's next step came back to the technician while they were looking elsewhere. It is the lens most tools make hardest to build. The event is simple: somebody other than the owner did something on the ticket after the owner's last action. A requester answered the question, a colleague added a note, a supplier confirmed the part, the lead added a comment. The filter is "owner is me, last update not by me", and where the tool offers it, "updated since I last viewed". Without this lens the technician finds out about the reply when they next open the ticket for some other reason, or when the requester phones to ask why their answer was ignored.

Test what your tool does to the status when a requester replies, because the lens depends on it. On a ticket in a waiting status, some tools move it back to active when the reply arrives. That makes the "waiting on me" lens easy. Some add the reply and leave the status alone. That means a ticket can be "waiting on the requester" with the requester's answer sitting on it. And some do one for e-mail and the other for the web form. Reply to a test ticket from a personal address through every channel you use and watch the status. Where the tool leaves it alone, the technician's first action on seeing the reply is to move the status by hand. The specification at the end records that.

Internal notes from colleagues belong in this lens too, and a desk that uses them well gets a quieter chat channel for free. A colleague who writes "I saw this on the Harbour Street site last week, check the switch in the stock room" as a note on the ticket has put the advice in the right place. The owner will find it in the next read and the next owner will find it in a year. The same advice sent by chat is read once and lost. Notes that survive are the subject of the Ticket Notes That Survive You series. The personal view's contribution is to make sure the owner sees the note the same morning.

Reopened: The Ticket That Came Back

A reopened ticket is one that was resolved and has been put back into an active status. Usually that is because the requester replied to say the fix did not hold. The reopened lens is the first lens read every morning, before "due today", because it is the only one where the desk has already been wrong once. In most tools, and in QuerySolv among them, a requester's reply to a resolved or closed ticket reopens it. In those tools, the lens is simply "owner is me, reopened since my last resolution". Where a tool does not reopen on reply, the lens has to be "resolved by me, with a requester update after the resolution". That is worth building because it is the same tickets. Amara's 7781 is the ordinary case: "still happening" at 22:14, no detail, a claims handler who will arrive at nine and expect to be asked.

Treat the reopened ticket as a new ticket with history, not as a nuisance, and reply within the hour of seeing it. The requester has been failed once and is watching for the second time. The reply that says "I have seen this, I am sorry it has come back, I am looking at it now and will update you by eleven" costs two minutes and returns most of the trust that the reopen spent. What a reopen is telling you, and how to handle one well, is the subject of Handling a Reopened Ticket Well. Here the point is that the reopen must be seen first thing, by its owner, in a lens of its own. That is because a reopen that sits among nineteen other tickets in "mine" is a reopen the requester will notice before the desk does.

Count the lens over a month as well as reading it each morning. That is because a technician's own reopen count is the single most useful figure they can look at about their own work. It is not a verdict. Two reopens in a month of forty resolutions might be two fixes that did not hold or two requesters with a second question. Only reading them tells which. It is, however, the figure that says whether "resolved" has been meaning "fixed" or "replied". It belongs to the technician before it belongs to anybody else.

Private to the Technician

The personal view is private, which means the technician reads it. The lead can open it for cover and for the one-to-one. It is never on the wall, never ranked, and never read aloud at a team meeting. The reason is not secrecy. It is that a technician's figures, their nineteen open, their two reopens, their three due today, are the raw material of their own judgement about their own day. The moment the same figures are displayed beside a colleague's they stop being information and become a score. A score changes behaviour in the direction of the score, which is the subject of Dashboards That Motivate Instead of Surveil. The rule here is the simple one: the shared view shows the team's work, and the personal view shows the person's. Each stays where it belongs.

The lead may open any technician's view for two reasons, and should say which. The first is cover: a technician is off, unexpectedly or on leave, and somebody has to see what they hold in order to reassign it. That is the routine in Vacation Coverage Without the Pile. The second is the one-to-one, where the lead and the technician look at the technician's figures together, for coaching and not for ranking. The figures are read only once there are enough tickets behind them to mean anything. A reopen rate over nine tickets is nine stories. A minimum of thirty to fifty resolved tickets and at least a month is a reasonable floor before a per-person figure is read at all. Even then, it is read beside a quality figure rather than alone. The careful version of cutting a metric by person, and why satisfaction in particular needs the most care, is in Satisfaction by Category, and Carefully by Agent.

Most tools make the private view the default and the shared one the thing you build, which is the wrong way round for the desk and the right way round for this article. In QuerySolv each technician sees their own numbers in their own view. That is the private half of the split this series argues for. The shared half shows what is waiting and what is overdue for the whole desk. It is the team's view and is the one that goes on a wall if anything does. On any tool, the test is whether a technician could, in principle, see a colleague's reopen count without asking. If they can, the view is not private, and the behaviour described in the next article in this series has already started.

Reading It Without Living in It

The personal view is read at fixed moments, and the moments are the morning, between tickets, after lunch, mid-afternoon and before leaving. The morning read is reopened first, then due today, then waiting on me, then a glance at the size of mine. Between tickets it is waiting on me and due today only, because those are the lenses that change while you work. The before-leaving read is due today one last time, to be sure nothing with today's date is still open without the requester having been told. It also includes waiting on me, so that nothing answered at four sits unread until nine. That is five reads of about a minute each, and a technician who does them does not need the view open all day.

Leaving the view open all day is the mistake, and it is a mistake of attention rather than of diligence. A view that updates as you watch it pulls the eye every time a reply lands, and each pull costs the thread of whatever ticket was being worked. The technician who answers every reply within a minute of its arrival feels responsive and is, measured by tickets resolved, slower than the one who answers them in batches at the fixed reads. The requester cannot tell the difference between a reply in one minute and one in forty. They can tell the difference between a fix today and a fix tomorrow.

Write the read times on the specification and keep them for a month before changing them. That is because the first week of any routine feels wrong and the fourth week tells you whether it is. Amara's five reads at Stonebridge took, in the second month, about six minutes a day in total. The number of times a requester phoned to ask whether she had seen their reply went, by her own count, from several a week to one in the month. That was a reply the tool had filed under a different ticket. Six minutes a day is not a cost. It is the price of the other seven hours being spent on tickets rather than on apologies.

How Many Is Too Many: A Worked Example

The "mine" count is only useful against a capacity figure, and the capacity figure comes from your own desk, not from anywhere else. The method is to watch, for a month, the number of active tickets each technician held at the morning read. Compare it against whether they missed a due-today target that day, and find the count at which misses started. At Stonebridge, across five technicians and a month, misses were rare below eight active tickets, began at about eight to ten, and were routine above twelve. The desk wrote "between eight and twelve active" on its specification as the range at which a technician stops claiming and starts handing over. The desk reviewed that range the next quarter. That is Stonebridge's range, from Stonebridge's tickets, for Stonebridge's mix of work. A desk whose tickets are mostly ten-minute resets will find its figure far higher, and a desk doing project work beside support will find it lower.

Active is the count that matters, not total, and the distinction is the reason the "mine" lens shows both. Eight tickets parked in waiting statuses with honest follow-up dates cost the technician a few minutes a day of checking. Eight active tickets each cost real work. A technician with twenty-five open tickets, eighteen of them waiting on suppliers, may have plenty of room. One with nine, all active, may have none. Counting total and calling it workload is how a desk ends up praising the person who parks everything and worrying about the one who does the work.

What a technician does on reaching the range is the part to write down, because the moment of reaching it is the moment of least judgement. The rule at Stonebridge is that a technician in the range stops claiming from the unassigned view, tells the lead in one line, and hands over any active ticket they cannot touch today. The lead reassigns or takes it. Nobody waits for the count to be fifteen and the misses to prove the point. Capacity is not a target to be reached. It is the edge of the shelf, and the shelf does not warn you twice.

A Short War Story: The Reopen Nobody Saw at Northgate Retail

At Northgate Retail, a technician called Leo resolved a ticket from the Harbor Street store about a till that printed blank receipts, after replacing the printer's paper roll and testing it. The store manager reopened it two days later with the line "doing it again on till two now". Leo's personal view had three lenses, mine, due today and waiting on me, and no reopened lens. That was because nobody had thought a reopen needed one. The reopened ticket landed in "mine" as one of twenty-two, with a last update that put it in the middle of the list. Its clock, which the tool had restarted from the original target, showed it as neither due today nor overdue. The store ran on handwritten receipts for eleven working days. Two customers complained to head office about not being able to return goods. The regional manager asked Leo's lead why the desk had "closed a ticket that was still broken". That was not what had happened and was what it looked like. The cost was eleven days of a store half working, two complaints, and a conversation about trust that the desk had not earned. The desk added a reopened lens to every personal view that afternoon and made it the first read of the morning. A reopen that lands in a list of twenty-two is a reopen the requester will find before the technician does.

The Personal View Specification

The specification below is one page per desk, not per person, because the four lenses are the same for everyone and only the names differ. Section A defines each lens as a filter, in reading order, so that every technician's "waiting on me" means the same thing. Section B records what the tool does with replies and reopens, tested rather than assumed, because two of the lenses depend on it. Section C is the reading schedule, and section D is the capacity range from your own month of watching. Section E is the privacy rule, written down so that it survives the next manager who asks for the figures on a wall.

PERSONAL VIEW SPECIFICATION — ONE PAGE, ONE DESK
Desk: ______________________   Prepared by: ______________   Date: ____________   Next review: ____________

A. THE FOUR LENSES, IN MORNING READING ORDER
   1. REOPENED
      Filter: owner is me, reopened since my last resolution
      Action: reply within the hour of seeing it; work it as a new ticket with history
   2. DUE TODAY
      Filter: owner is me, target before the end of the working day (____:____), sorted by target time
      Action: work in due order; tell the requester a new time before any time I will miss
   3. WAITING ON ME
      Filter: owner is me, last update by someone other than me since my last action
      Action: read the change; reply or act; move the status by hand if the tool did not
   4. MINE
      Filter: owner is me, any status except resolved or closed; shown as active ____ / waiting ____
      Action: compare active against the range in D before claiming anything

B. WHAT THE TOOL DOES (tested from a personal address, every channel)
   Requester reply on a waiting ticket:  [ ] moves it to active   [ ] adds the reply only   [ ] differs by channel: ______
   Requester reply on a resolved ticket:  [ ] reopens it   [ ] adds the reply only   [ ] opens a new ticket
   Target after a reopen:  [ ] restarts   [ ] continues from the original   [ ] none
   Ticket raised at 16:50 on a two-hour target is due:  [ ] today   [ ] next working morning

C. WHEN IT IS READ (about a minute each)
   Morning ____:____  reopened, due today, waiting on me, size of mine
   Between tickets    waiting on me, due today
   After lunch ____:____  waiting on me, due today
   Mid-afternoon ____:____  due today
   Before leaving ____:____  due today, waiting on me
   Weekly ____________  top three of mine by oldest update: work, hand over, or park with a date

D. CAPACITY (from one month of our own tickets)
   Active tickets at the morning read at which due-today misses began: between ____ and ____
   On reaching the range: stop claiming; tell the lead in one line; hand over what I cannot touch today
   Reviewed on: ____________

E. PRIVACY
   Read by: the owner
   Opened by the lead only for: [ ] cover during absence   [ ] the one-to-one, for coaching
   Never: displayed on a shared screen, ranked, compared, or read out
   Per-person figures read only after ____ resolved tickets and ____ month(s), beside reopens

Amara's desk at Stonebridge filled in the specification in the week after her Wednesday. The only argument was about section D, where two technicians wanted the range higher and the month of watching settled it. Ticket 7781 turned out to be a different fault from the one she had fixed on Monday. The claims handler explained that at 09:04 when she replied to him at 09:01. "Still happening" had not conveyed it. He mentioned, in passing, that he had not expected an answer before lunch. The reopened lens had been the first thing she read.

Frequently Asked Questions