When a swap request sits unanswered for most of a day, it's tempting to read it as a manager being slow to decide. More often, the delay has nothing to do with the decision at all.
Ask a shift manager how long they spend deciding whether to approve a swap and the honest answer is usually seconds. They know the roster, they know the people, and most requests are unremarkable. The decision isn't the hard part.
The delay is almost always in everything that happens before the decision: noticing the request exists, gathering enough context to judge it, and finding a moment to respond.
Where the time actually goes
Consider a common arrangement — swap requests arrive as messages in a team chat. Nothing about that is unusual, and it's how a great many teams operate. But it creates three specific problems.
- The request has to be found. It sits between a delivery photo and a question about the ice machine, in a feed where everything looks equally urgent.
- The context isn't attached. To judge the trade, the manager has to open the schedule, check who's already on, and confirm both people are trained for the role.
- There's no state. A message can be read and forgotten. There's no list of outstanding decisions, so nothing indicates when the queue is clear.
None of these are failures of attention. A manager on the floor is doing the job they're there to do. The request simply landed somewhere that requires them to be at a screen, and looking, at the right moment.
Why effort doesn't fix it
The usual response is to try harder at it — reply faster, set tighter rules, keep a separate spreadsheet. This tends not to help much, because the problem isn't skill or diligence. It's routing.
“If the delay is in noticing the request, no amount of urgency, reminders, or policy will shorten it.”
Overhead created by where a request lands can't be removed by personal discipline. It has to be removed by moving the request — which is also why coverage work quietly consumes so much of a manager's week.
What tends to help
Three changes address the underlying structure rather than the symptom:
- Give the decision its own surface. Pending swaps belong in a dedicated list, not a general conversation. An empty list should mean there's nothing to decide, and that should be obvious at a glance.
- Attach the context to the request. Who is handing off, who is taking it, which shift, whether both are qualified, and whether it creates a conflict — all in one view, so no cross-referencing is needed.
- Reduce the action to a single step. Approve or decline, from the list itself, on a phone. Every additional screen is another place a request can stall.
A better question than 'how fast?'
Response time is easy to measure but can be misleading. A more useful question is what share of requests are resolved before the shift in question begins. A swap approved after the shift has started isn't a slow approval — functionally, it's an absence with paperwork attached.
If your approvals feel slow, it's worth measuring the gap between a request being made and first being seen, separately from the gap between seeing and answering. If most of the time sits in the first gap, the request is in the wrong container — and that's a fixable problem.
I am an entrepreneur driven by innovation and real-world problem-solving. ShiftScout was inspired by my own experience of working shifts from an early age. I often wished there was a solution like ShiftScout to make finding and managing shifts easier. That personal experience became the foundation for building ShiftScout and turning a real challenge into a scalable business solution.
