Team Queues vs Personal Queues: Who Owns the Waiting Work

Thursday, 16:40, at the Bellweather Logistics desk. Tomas has thirty-one open tickets assigned to him. Nine of them he has not opened since Monday morning, when he took them at triage "so they would be with someone". The team's unassigned view shows zero, and the operations manager, walking past, reads zero as "all under control" and says so. Omar, who joined three weeks ago, has four tickets and has finished all four. He is reading knowledge base articles because the list he can see looks empty. Two desks away, nine requesters are waiting for a person who is in the building, at his desk, and not working on their tickets. Everything on the screen is accurate.

A team queue is the list of open tickets the whole desk can see and any member can take. A personal queue is the list of open tickets one named person has promised to work. The two are not rivals; a desk needs both, and most of what goes wrong with queues comes from confusing what each one is for. This article is part of our Queues & Routing series. It is about the line between the two: who may see a ticket, who owns it, and what owning it obliges you to do.

It starts with the difference between ownership and visibility, then what the team queue and personal queue are each for. Next comes the rule that unassigned means the team's. Then comes the hoarding problem and why it is worse than leaving tickets unassigned. After that: how many tickets one person should hold at once, with the arithmetic, and how to take a ticket back without a fight. Next is how permissions shape what people can own. It ends with a short war story and a one-page queue ownership policy to copy.

Ownership and Visibility Are Two Different Things

Ownership is one name on the ticket. Visibility is who can see it. The whole subject of team and personal queues comes down to keeping those two separate. Every ticket is visible to the whole team, and every ticket that is being worked has exactly one owner. Confuse the two in one direction and you get a ticket everyone can see and nobody owns, which is the black hole. Confuse them in the other and you get a ticket one person owns and, in practice, nobody else looks at, which is hoarding. Both are failures of the same rule.

Ownership means responsibility for the next step. The owner is the person who will reply, fix, chase or hand over, and the person whose name a requester would be given if they asked "who has it?" There is one owner at a time, because two owners is a way of saying none, and the owner changes only by a deliberate act that leaves a trace. Visibility means the ticket appears in the lists other people look at. A ticket can and should have one owner and many viewers. The owner is accountable; the viewers are the safety net.

The reason the distinction matters is that the two things fail at different speeds. A ticket with no owner is visibly in trouble; it sits in the unassigned view, its clock running, and anyone who reads the view sees it. A ticket with the wrong owner looks fine from every angle except the requester's. The desk sees a name and assumes work. Nothing in the list distinguishes a ticket somebody is working on from a ticket somebody took three days ago and forgot. Visibility is cheap and ownership is a promise, and a promise is only worth what the person does with it.

What a Team Queue Is For

The team queue is the pool new work waits in until a person promises to do it. It is where the web form, the mailbox, the chat widget and every other door deliver tickets. It is the place where the desk's promise to requesters is measured. Every minute a ticket spends there is a minute before anyone has started. The team queue is not a place to work from. It is a place to take from. Its ideal state is nearly empty, with nothing in it older than a few hours. A team queue that stays that way is the clearest sign of a desk that is coping.

The team queue is also the only honest picture of load. If forty tickets are waiting and nobody has taken them, the desk is behind by forty and everyone can see it. If the same forty are distributed across four people's personal lists, the desk is behind by exactly the same forty and nobody can see it. Each person sees ten and ten looks manageable. The operations manager at Bellweather read zero and relaxed. Zero unassigned is the easiest number on a help desk to make look good. You assign everything to yourself.

The whole structure of the queue, the one list and the standing views that narrow it, is in What a Queue Is For. The team queue in this article is that one list, seen through its most important lens: the tickets with no name on them yet.

What a Personal Queue Is For

The personal queue is the list of work one person has promised to do next, and it is the list most technicians spend most of the day inside. It should be short. It should be made up of tickets that person will touch today or tomorrow, plus tickets legitimately waiting on someone else with a date attached. It should never contain a ticket the owner has no plan for. A personal queue is a promise list. The moment it contains something the person is not going to do, it becomes a filing cabinet with a name on the front.

Taking a ticket is a promise, and that is the sentence to pin up. When you move a ticket from the team queue to your own, you are telling the requester something through the tool. A specific person is now responsible for their problem. You are also telling the rest of the desk that they can stop looking at it. Both of those are true the moment you take it, whether or not you meant them. The requester will be told your name if they ask. Your colleagues will skip the ticket in their next sweep. The only person still able to see it is in trouble is you, and only if you look.

Work the personal queue in a fixed order rather than by whim: overdue, due soon, then oldest first. Check waiting tickets once a day for anything that has waited past its date. A technician who picks the interesting ticket each time will leave the dull one until it is the oldest thing on the desk. The dull one is usually the password reset that stops somebody working. Interesting is not a priority. It is a preference, and the queue does not have preferences.

The Rule: Unassigned Means the Team's

An unassigned ticket belongs to everyone who can see it. Anyone who can see it may take it. If it is the oldest or most urgent thing in the view, they should. Nobody saves tickets for a colleague. Nobody waits for the lead to hand them out. Nobody leaves a ticket in the unassigned view because "Marcus usually does those", because Marcus is not a routing rule and may be at the dentist. Unassigned does not mean "awaiting triage" or "for the lead to allocate". It means available, now, to whoever looks.

The rule has a second half that people forget: unassigned at the end of the day is a team failure, not a person's. If a ticket has sat in the shared view since 09:00 and nobody has taken it, the question is not "whose fault?" but "why did four people read that view and leave it?" Usually the answer is that nobody read it. Sometimes the answer is that everyone read it and each assumed another would take it, which is the same answer in better clothes. A desk lead who sees the same ticket unassigned at two sweeps in a row should take it or name a person on the spot, and ask the view question afterwards.

Tools encode this rule to different degrees, and it is worth knowing how yours behaves. In most claiming tools any agent who can see an unassigned ticket can take it. In many, the first public reply on an unassigned ticket claims it automatically, so replying is taking. Check whether yours does this, because it changes what a quick acknowledgment means. Check also what happens when two agents claim at the same moment. The good answer is that one wins and the other is told at once. Check whether an agent who is assigned a ticket by somebody else is e-mailed. Then look at the opposite case: in many tools a breached deadline on an unassigned ticket e-mails nobody, because there is nobody to e-mail. That last behaviour is the rule in its purest form: an unassigned ticket has no alarm except a human reading the view.

Where a tool deals tickets out automatically rather than letting people claim them, the rule changes shape but not meaning. The dealt-to person owns it from the moment it lands, with all the obligations that follow. The "team" moment is skipped. Whether that suits your desk is the subject of Round-Robin vs Skill-Based Routing vs Just Claiming. For a desk of one to ten people, claiming from a shared view is usually the better fit, and it is the model this article assumes.

The Hoarding Problem

Hoarding is taking tickets you are not going to work. The technician assigns a ticket to themselves at triage and does not open it again. Sometimes the motive is good: the ticket looked like theirs, they meant to get to it, the day filled up. Sometimes the motive is comfort: a ticket with your name on it is not sitting accusingly in the shared view, and nobody is going to ask why it is still there. And sometimes the motive is the manager, who read zero unassigned as good news and said so, and taught the desk that zero was the number to produce. (The number was not lying. It was answering a question nobody should have asked it.)

Hoarding is worse than leaving a ticket unassigned, and this surprises people. An unassigned ticket is visibly waiting; it sits in the one view everyone is supposed to read, and the longer it sits the louder it gets. A hoarded ticket is invisibly waiting; it sits in a personal list, looks owned, and everyone else on the desk has been told, by the name on it, to stop looking. A hoarded ticket does not complain. It has an owner. It feels looked after. The requester, meanwhile, is waiting for a person who exists, is in the building, and has no intention of opening their ticket this week.

The signs are easy to read once you know to look. One person's open count climbs while the others' stay flat. The last-update dates on that person's tickets are old, and the latest entry on several is the requester asking for news. The person reports being swamped, which is true, while closing about as many tickets a day as everyone else, which is also true. And the shared view is empty, every day, by 09:30, which is impressive. The desk lead should treat that as a reason to open the per-person counts rather than a reason to relax.

The cure has three parts and none of them is a telling-off. First, make per-person holdings visible to the person and to the lead. Most tools have a workload-per-agent report or a filter by assignee that gives the lead the numbers. They also have a counter on each agent's own screen that shows them their own pile. If the tool lets you choose, show each person their own number privately and do not publish a ranked list. A leaderboard turns holdings into a score, and a score is something people manage rather than something they read. The point is for the person to see their own number, not for anybody to be ranked by it. Second, add a daily release to the routine. At a fixed time, every technician puts back into the team queue anything they will not touch today, with a one-line note saying why. Third, state the rule in the policy and read it aloud once: taking a ticket is a promise to touch it today, not a way of giving it a home.

How Many Tickets One Person Should Hold

There is no universal number, and anyone who gives you one without asking about your desk is guessing. There is, however, a piece of arithmetic that gives you your own number in a minute. Take the tickets a person holds and divide by the tickets they close in a day. The result is the number of working days before the ticket they took this morning gets any attention. Tomas at Bellweather holds thirty-one and closes about six a day. The ticket he took at 09:10 "so it would be with someone" will, on current form, be opened a week from Thursday. That is the honest waiting time of a ticket in a hoarded queue, and it is longer than the time it would have waited unassigned.

Work the arithmetic the other way to get a ceiling. Decide the longest you are willing for a ticket to sit in a personal queue before being touched, which for most small desks is one working day for anything active. Multiply by the daily close rate. A technician who closes six a day and promises to touch everything within a day should hold about six to eight active tickets. Add whatever is genuinely waiting on a requester or a supplier with a date on it. More than that and the arithmetic says some of them are lying about being worked. Fewer and the technician should be in the team queue taking the next one.

Waiting tickets complicate the count, and the honest way to handle them is to count them separately. A ticket that is waiting on the requester for a part number, with a follow-up due on Thursday, is not idle. It is parked with a date, and it costs the technician nothing until Thursday. Count active tickets against the ceiling and waiting tickets against a second, looser one, and insist that every waiting ticket has a date. A waiting ticket with no date is an active ticket pretending, and the follow-up rhythm that stops it pretending for long is in Follow-Up Cadences That Keep Tickets Moving.

The table turns the arithmetic into something the lead can read in a glance across the team. The bands are for a generalist desk technician who closes five to eight tickets a day. A specialist who closes two complex tickets a day will have smaller numbers and the same logic. I once held fifty-two tickets and called it being organized. The table is what I wish someone had shown me that month.

Taking a Ticket Back Without a Fight

Reassigning a ticket away from someone is not an accusation, and the desk that treats it as one will stop doing it. The lead's weekly look at holdings will always find a few tickets that have outlived their owner's plan, and the right response is to move them, say so, and move on. "I have taken 7308 and 5520 off your list; you have had them a week and I would rather they moved than waited." That is the whole conversation. The technician who hears it twice will start releasing tickets before the lead gets there, which is the point.

The mechanics matter more than the words. Reassign through the tool, never by asking the person to do it, because the record should show who moved it and when. Leave a one-line internal note saying why, so the next owner does not spend ten minutes guessing. Make sure the new owner is told. A tool that e-mails an agent when a ticket is assigned to them by someone else does this for you. A tool that does not needs the lead to say it out loud. And never reassign to a group, a role or an empty name. A ticket moved from one person to nobody has gone from hoarded to unassigned, which is progress, but only if the team queue is read before the day ends.

Transfers that cross a boundary, to another department or to someone covering leave, have their own etiquette, because the receiver may not know the requester, the history or the promise already made. That handover, and the note that stops it being a dump, is in Transferring a Ticket Between People or Departments. The rule that carries over is simple: whoever moves a ticket owes the next owner one honest sentence about why.

Permissions Shape What People Can Own

Who can see the team queue decides who can take from it, and permissions are where that gets set. Most tools let you restrict what an agent sees, and the lowest setting is usually "only tickets assigned to me". That is a reasonable place to start a brand-new technician, and it has a consequence that is easy to miss. A person who can only see their own tickets cannot see the team queue at all. So unassigned does not mean theirs, because they will never know it exists. Everything they work has to be handed to them by someone else, and the lead becomes the router.

Most tools draw this boundary with roles or permission levels, and the names vary: trainee, restricted, agent, member, junior. Whatever yours calls them, the two lowest levels usually mark exactly this line. The lowest sees only its own assigned tickets and can reply and write notes. The next sees the whole team or department queue and can take from it, set priority and escalate. The step between them is the step from "work what you are given" to "take what is waiting". Check how thoroughly the restriction is enforced in your tool. A good one applies it to the queue, search, direct links, the dashboard and reports alike. So a restricted agent cannot see the team queue by a side door. A weaker one hides the view and leaves the search open, which is confusing rather than dangerous. A desk that leaves everyone on the lowest level for six months has a team queue in name only; one person is dealing, and the dealing is the bottleneck.

Plan the step deliberately. A new technician on the "own tickets only" setting for their first two or three weeks is sensible. They learn the tool, the replies and the requesters without the pressure of the shared view, and the lead hands them a steady trickle. After that, open the department queue to them and tell them the rule out loud: unassigned means yours too. Omar at Bellweather had been on the restricted setting for three weeks and was reading knowledge articles while nine tickets waited. The list he could see was accurate and empty. The permission was doing its job. Nobody had told it the job had changed.

A Short War Story: Forty-Four Tickets at Stonebridge Insurance

The Stonebridge Insurance desk had four technicians, and Ravi, the most experienced, held forty-four open tickets while the other three held nine, eleven and six. Nobody questioned it, because Ravi was the one who knew the claims system and the unassigned view was empty every morning by half past nine. Among the forty-four was a request for claims-system access for a newly hired adjuster. Ravi took it on the adjuster's first day and did not open it again for twelve working days. During that time, the adjuster shadowed colleagues, read manuals and processed nothing. The desk found out when the claims manager asked HR why a hire was costing a salary and producing no claims, and HR asked the desk. The cost was twelve days of a salaried adjuster unable to do the job and a backlog of claims that took the team three weeks to clear. The cost also included a conversation between Ravi and the desk lead that should have happened on day two. Ravi's handover note from that fortnight read "all assigned", which was accurate. A ticket assigned to someone who is not working on it is not owned; it is hidden in plain sight.

The Queue Ownership Policy

The policy below is one page, written for a desk of one to ten people, and it says in plain rules what this article has said in prose. Fill in the blanks with your own ceiling and times, read it aloud once at a team meeting, and pin it where the queue is read. It is deliberately short, because an eleven-page queue policy is a document about a queue rather than a rule for one. Nobody has ever consulted page seven at 16:40 on a Thursday.

QUEUE OWNERSHIP POLICY — ONE PAGE
Desk: ______________________   Effective from: ____________   Owner: ____________

VISIBILITY
  Every open ticket is visible to every member of the desk who has
  completed their first ____ weeks. Nobody keeps a private list.
  New starters see only their own tickets until the lead opens the
  department queue to them, which happens by week ____.

OWNERSHIP
  Every ticket that is being worked has exactly one owner.
  The owner is responsible for the next step: reply, fix, chase or hand over.
  Ownership changes only through the tool, never by conversation alone.

UNASSIGNED MEANS THE TEAM'S
  Anyone who can see an unassigned ticket may take it.
  Take the oldest or the most urgent, not the most interesting.
  Nobody saves a ticket for a colleague. Nobody waits to be allocated.
  An unassigned ticket older than ____ hours is raised at the next sweep.
  An unassigned ticket at end of day is a team failure, not a person's.

TAKING IS PROMISING
  Take a ticket only if you will touch it today or tomorrow.
  Replying to an unassigned ticket makes it yours.
  Do not take a ticket "so it has a home".

HOLDING CEILING
  Active tickets per person: no more than ____ (default 8).
  Waiting tickets must each have a follow-up date.
  Over the ceiling? Release at the daily release time: ____:____.
  Releasing means: back to the team queue, one-line note saying why.

REASSIGNMENT
  The lead reviews holdings weekly on ____________.
  Tickets past the owner's plan are reassigned through the tool with a note.
  Reassignment is not an accusation. Hearing it twice means release sooner.
  Never reassign to a group, a role or nobody without telling the team.

AWAY
  Before any planned absence, release or hand over every active ticket.
  The lead reassigns the tickets of anyone off sick by ____:____ that day.
  A leaver's tickets are reassigned on their last day, every one.

Two lines in the policy do most of the work, and if you keep only two, keep these: taking is promising, and unassigned at end of day is the team's failure. The first stops hoarding before it starts. The second stops the team queue from becoming the black hole that hoarding was trying to avoid. Tomas read the policy, released nine tickets on Friday morning with a note on each, and Omar took five of them by lunch. The unassigned view showed zero again by two o'clock. This time the zero was true.

Frequently Asked Questions