A support team closes more tickets than ever. Its queue keeps growing. People work harder, customers wait longer, and everyone has a different explanation.
Start by making a model simple enough to check. Define what you are counting, what changes it, and how those changes affect what happens next. That is a useful way into systems thinking.
01 Start with something you can count
Suppose there are 120 unresolved tickets on Monday. That quantity is a stock: an amount measured at a moment. New tickets enter; resolved tickets leave. Those movements are flows, measured over an interval.
With no other changes, the queue ends the week at 120 + 30 − 25 = 125 tickets. The team can be productive and still fall behind. Arrivals exceed resolutions by five per week.
Define the boundary carefully. Do reopened tickets count as arrivals? Do duplicates count as resolutions? Include every way a ticket enters or leaves your definition of “open.” Otherwise the numbers will fail to reconcile.
02 A smaller inflow can still mean a bigger queue
Suppose better documentation reduces arrivals from 30 to 27 a week. That helps. But the team still resolves 25, so the queue grows by two a week. You have slowed the growth; you have not reversed it.
| Scenario | Arrive / week | Resolve / week | After 4 weeks |
|---|---|---|---|
| Baseline | 30 | 25 | 140 |
| Fewer arrivals | 27 | 25 | 128 |
| More capacity | 30 | 40 | 80 |
Even a successful change takes time to remove an accumulated backlog. At 40 resolutions and 30 arrivals a week, the queue falls by ten each week. Under those fixed assumptions, reaching 60 from 120 takes six weeks.
Real rates vary. A hard ticket is not interchangeable with an easy one, and adding a person does not guarantee ten more resolutions. This arithmetic is a baseline for asking questions, not a staffing forecast.
03 Look for a loop
A feedback loop exists when a change travels through the system and returns to affect its starting point. Two possible loops in this queue illustrate the difference.
Reinforcing: a problem amplifies itself
Larger queue → longer waits → more follow-up tickets → larger queue
Balancing: a response opposes the change
Larger queue → more staff assigned → more resolutions → smaller queue
“Reinforcing” does not mean good, and “balancing” does not mean harmless. They describe the direction of the response. Several loops can operate at once.
Delays matter. A new teammate might need weeks of training, while experienced staff spend time helping them. Capacity could initially fall. If you respond to that temporary dip as though the change has failed, you may keep changing the plan before its effects can appear.
Choose a review interval that fits the mechanism. Monitor early signs during a delay, and decide in advance what would justify changing course. Waiting blindly is no better than reacting to every fluctuation.
04 Change one thing. Watch what happens.
The model gives you several places to investigate: prevent a recurring source of requests, reduce handling time, make ticket status visible, or change how work is assigned. The most visible number is not necessarily the best place to act.
Consider an incentive to close more tickets. It could raise the reported resolution rate while encouraging premature closure. Track reopenings and whether customers’ problems are actually solved. An improved counter is weak evidence if the underlying outcome gets worse.
Carry the method into other situations, but keep your claims proportional to what you can observe. Money and inventory can be counted directly. Trust and code quality need careful definitions and imperfect indicators. Drawing a box around something does not make it a measurable stock.