Most of the delay we find sits in a shared inbox, a group folder, or a channel that four people watch and nobody reads. The work is not lost. It is simply waiting to be noticed.
How a queue loses its owner
It rarely starts that way. Someone sets up a shared address so that requests do not sit with one person while they are on holiday. That is a sensible reason. Then the volume grows, and the person who used to check it takes on something else, and the queue quietly becomes everyone's job.
A queue that is everyone's job is checked when someone has a quiet morning. On a busy week it is not checked at all.
What it looks like from the outside
Customers describe it as inconsistency. The same request takes a day one week and a fortnight the next, with no visible difference between them. Inside, the difference is simply who happened to be looking.
That inconsistency is often what brings a team to us, described as a capacity problem. It usually is not one. The work is being done at the same speed. It is waiting a different length of time before it starts.
The fix is smaller than people expect
- Give the queue a name. One person, on a rota if you like, responsible for it during their shift. Not for doing the work, for moving it on.
- Agree what a complete request looks like. Half the reopening and chasing comes from things arriving without what the next person needs.
- Make the wait visible. A queue you can see the age of gets emptied. A folder does not show you that something has been sitting there since Tuesday.
When a system is the answer
Sometimes it is. If the volume is high and the routing is genuinely complex, a tool will help. But we would rather see a named owner and an agreed definition of "ready" running for a month first, because a tool laid over an unowned queue produces an unowned queue with better reporting.
Most of the time, the thing that was missing was a person, not a platform.