The Approval Queue That Stalls at Month-End
A purchasing team runs a 6-step approval process. Each step is a User Input Task assigned to a group via a dynamic group picker. At month-end, the volume triples to about 900 new instances per day. Analysts report that approval tasks sit in their queues for 2-3 days even though the group has 40 members and most tasks take under 5 minutes. Investigation shows tasks are assigned to the group, but only 3 people ever pick them up because the queue is sorted by a stale priority field and the highest-value items are buried. There is also a 4-hour SLA that is silently being breached with no escalation. The process model has a single escalation timer that fires at 8 hours.
1. Diagnose why throughput is low despite adequate staffing, and propose the highest-leverage fixes ranked by impact.
Read the worked answer
Diagnosis. The bottleneck is not capacity; it is work distribution and visibility. Three compounding issues:
- Assignment model. Group-assigned tasks with no individual routing create a shared-pool problem - nobody owns a task, so pickup is voluntary and skewed to a few members. With 900/day and a 5-minute average, the true workload is ~75 person-hours/day, easily absorbable by 40 people. The gap is behavioral, not mathematical.
- Sorting/prioritization. Sorting by a stale field means the queue does not reflect urgency or value, so members cherry-pick or ignore it.
- SLA mismatch. The escalation timer (8h) is longer than the stated SLA (4h), so breaches are structurally invisible and no escalation ever fires before the SLA is already blown.
Fixes, ranked by leverage:
- Align the timer to the SLA (fire escalation at or just before 4h, with a second escalation at 4h+). This alone makes breaches visible and triggers reassignment. Highest impact, lowest effort.
- Introduce load-balanced or round-robin individual assignment so each task has an owner, with reassignment on timeout. Converts a shared pool into owned work.
- Fix queue prioritization so the sort reflects business value/urgency, not a stale field. Consider a computed priority on the task.
- Add a visible SLA indicator on the task form and in the queue so analysts see time remaining.
Do the timer fix first - it is a configuration change, not a redesign, and it unlocks measurement for everything else.
2. A stakeholder proposes adding a 7th approval step to catch high-value purchases. What questions must be answered before adding the step, and what is your recommendation?
Read the worked answer
Adding a step increases cycle time and WIP for every instance unless it is conditional. Before agreeing, establish:
- Is the step conditional? It should only trigger for high-value instances (e.g., a threshold expression on amount), not all 900/day. An unconditional step multiplies the existing queue problem.
- What decision does the step actually make? If it is a rubber-stamp, it is governance theater and adds latency without control. Define the decision criteria and the rejection path.
- Who owns it and what is their capacity? A new group with 2 members becomes the new bottleneck.
- What is the SLA for the new step, and does the overall SLA still hold? Recompute end-to-end time.
- What happens on timeout? Escalation and reassignment must be defined, or the step becomes a black hole.
Recommendation: Fix the existing distribution and SLA problems first - adding a step to a process that already breaches SLA will make month-end worse and confound the diagnosis. If the control is genuinely needed, implement it as a conditional step gated on value, with its own SLA and escalation, and pilot it on a subset before rolling out. Measure cycle time before and after.