Notifications vs. Queues: How People Should Find Out There's Work to Do

Push alerts versus pull-based work queues, and why most teams need fewer pings and a better list of what to do next.

Ask someone on your team how they know what to work on today and you will get one of two answers. Either “I check my inbox and chat and piece it together,” or a long pause followed by “I just sort of know.” Neither is a process. Both are how work quietly goes missing.

When teams move off a spreadsheet, the first instinct is to add alerts for everything the old sheet couldn’t do. That fixes visibility for about a fortnight. Then the alerts become wallpaper and you are back to people “just sort of knowing.” The better answer for most work is a queue.

Push and pull, in plain English

There are two basic ways a person finds out there is work waiting for them.

Push means the system interrupts you: an email, a chat message, a phone notification. The work comes to you, whether or not you are ready for it.

Pull means you go to a list when you have capacity and take the next item. The work waits for you, in order, in one place.

A queue is simply a pull-based list with rules: what belongs on it, what order it’s in, and what happens when you pick something up. A supermarket checkout line is a queue. A pile of sticky notes on someone’s monitor is not, even though it contains work.

Post 17, “Automations That Actually Save Time (And the Ones That Just Create Noise)”, covers how alert spam happens and how to prune it. This post is about the thing you build instead.

Why notifications fail as a work system

Notifications are good at one job: telling you something changed. They are poor at telling you what to do next, for a few reasons.

They have no memory. Once a message scrolls off the screen, the work it described is invisible unless someone remembers it.
They have no order. Twelve alerts arrive in the order events happened, not the order the work matters.
They don’t know who’s busy. A notification sent to five people is frequently handled by none of them, because each assumes another did it.
They can’t be counted. You cannot easily ask “how many requests are waiting?” of a chat channel.

Picture a facilities team of four handling maintenance requests. Every new request pings the whole team. On a busy morning that’s 20 messages. By Thursday, a broken door closer reported days earlier has sunk beneath a lunch order thread, and the person who reported it is emailing the office manager directly. The request was “sent” to everyone. It was owned by no one.

What a good queue looks like

A queue that people trust has a small number of properties. Most internal tools can do all of them with filtered views; you rarely need anything special.

Property	What it means in practice
One place	Every item of this type lands in the same list, however it arrived.
Clear entry rule	An item appears when it reaches a specific state, e.g. “Submitted” and not yet assigned.
Clear exit rule	It leaves when someone claims it or it moves to the next state. Nothing lingers by accident.
Sensible order	Sorted by due date, priority, or age, and everyone knows which.
Visible age	Each item shows how long it has waited.
Claiming	Picking an item puts your name on it, so two people don’t do it twice.

For the facilities team, the queue is a view of maintenance requests where status is “New” or “Unassigned,” sorted oldest first, with an “age in days” column. Someone starts the day by opening it, claiming two or three items, and moving them to “In progress.” Their own claimed items appear in a second view, “My open requests.”

Designing personal and team queues

Most teams need two layers.

Team queues hold unclaimed work. They answer “what’s waiting that nobody has picked up?” Keep one per type of work, or per team, not one giant list of everything.

Personal queues hold what you’ve claimed. They answer “what am I on the hook for?” This view should be someone’s default landing page in the tool.

A few design choices make a big difference:

Put the deciding information in the list. If people have to open every item to know whether it’s urgent, they’ll stop scanning. Show due date, requester, and a short summary.
Separate “waiting on someone else.” Items blocked on a supplier or customer clutter a personal queue. Give them their own state and view.
Cap work in progress softly. If one person has 25 claimed items, the queue is lying about capacity. A visible count per person is often enough to prompt a conversation.
Make the empty queue meaningful. An empty team queue should mean “everything has an owner,” not “we stopped looking.”

Where push still earns its place

None of this means switching notifications off entirely. Push is the right tool when timing matters more than order. Keep alerts for:

Assignment to you specifically. If someone hands you an item, you should hear about it once.
Genuine urgency. A safety issue or a customer-facing outage should interrupt people. Define “urgent” narrowly and write it down.
Ageing beyond a limit. One alert to a lead when an item has sat unclaimed for, say, two working days. This is an escalation, not a status update.
A daily digest. One message each morning summarising the queue (“7 waiting, oldest 3 days”) nudges people towards the list without replacing it.

A useful rule: notifications should point at the queue, not substitute for it. Every alert should link to the item or view where the work actually lives.

Introducing queues to a team used to pings

People who have lived in their inbox for years may feel anxious when the pings stop. Their worry is reasonable: “What if I miss something?” Answer it with routine, not reassurance.

Agree when the queue gets checked. For the facilities team, it’s first thing, after lunch, and before leaving. Make the lead responsible for the team queue at those times for the first month. Show the “oldest item” figure in the weekly meeting, so people see the queue working.

Within a few weeks, the question changes from “did you see my message?” to “is it in the queue?” That shift is the whole point.

Where to start this week

Pick one type of work that currently arrives via alerts or chat, and list every channel it comes through.
Build a team queue view with a clear entry rule, oldest-first sorting and a visible age column.
Build a “My open items” view and make it the default landing page for the people who do the work.
Cut the alerts down to direct assignment, true urgency, one escalation rule and an optional morning digest. Turn the rest off and see who notices.