Why did we build a separate queue for documents waiting on a decision?
She didn't ask for a new feature. She just scrolled.
Every morning the bookkeeper opened the incoming queue and scanned through everything — resolved items, archived items, things that had nothing to do with her — looking for the two or three documents that were actually waiting on her decision. The pile was mixed together. There was no separation between "done" and "needs you."
That's the situation we started from.
What the problem actually looked like
On the surface it doesn't sound serious. Scrolling through a list takes seconds, right? But it happened every time she came back to the queue — after a break, after a meeting, after lunch. Each time: scan everything, mentally filter out what's already resolved, find the live items, act.
The friction wasn't catastrophic. It was just constant.
And because nothing was broken in an obvious way, there was no ticket, no complaint, no escalation. The queue worked. Documents got processed. The problem was invisible until someone sat next to her and watched.
What we built — and what we didn't
We pulled the "waiting on you" documents into a separate screen. That's the entire change.
No scoring algorithm. No AI prioritization. No analytics dashboard showing throughput metrics. Just a view that contains only the items that require her action right now, separate from everything else.
The resolved items are still there — they didn't go anywhere. They're just not in the same pile anymore.
Why this kind of thing gets missed
Features that solve obvious, loud problems get built first. A broken import, a crash, a missing field — those generate reports and get prioritized.
A queue that works but makes someone scroll too long generates nothing. The person adapts. The workaround becomes routine. The cost is invisible because it's distributed across dozens of small moments rather than concentrated in one failure.
The hard part of building this feature wasn't the implementation. It was recognizing that the pile existed and that it was worth separating. That only happened because someone watched the actual workflow instead of reading about it.
Where this logic doesn't apply
Not every mixed queue is a problem worth solving with a UI change. If someone visits the queue once a day and it has five items total, the separation adds complexity without removing friction. The value of a dedicated "waiting on you" view scales with how often the queue is visited and how much noise surrounds the relevant items.
It's also not a fix for a queue that's disorganized for other reasons — wrong statuses, missing metadata, documents filed to the wrong place. Separating a pile that's already mislabeled just creates two mislabeled piles.
What to look for in your own tools
The pattern here isn't specific to document queues. It shows up anywhere a person regularly has to mentally filter a shared list to find the slice that's relevant to them.
If someone on your team has a routine that involves scanning past things they already know aren't relevant — that's the pile. It probably doesn't have a name yet. It probably hasn't been reported as a problem. But it's there, and it costs something every time they do it.
The way to find it is to watch, not to ask.