“Pending” is useful as a system status. It’s terrible as an operating model.
In infusion operations, waiting is unavoidable. A referral may be waiting on a signed order. Benefits may be waiting on updated coverage information. Prior authorization may be waiting on the payer. Pharmacy may be waiting on clinical documentation. Scheduling may be waiting for the case to be released.
None of that means the operation is failing.
The problem starts when Pending is the only answer available.
Because an operations leader doesn’t just need to know that something is waiting. They need to know: what are we waiting for? Who owns the next action? Is that action internal or external? How long have we been here? What should happen next?
Not all waiting is the same
Some of the strongest diagnostic work behind WRA’s Control Tower thinking starts with a simple observation: not every case marked “pending” is stuck for the same reason, and treating them as if they were is where operations lose their grip.
There are at least three fundamentally different conditions hiding inside that one word.
Waiting externally. The operation has completed its current responsibility and is legitimately waiting on a payer, provider, patient, referral source, or another outside party. Nothing internal is broken — the clock is simply running on someone else’s desk.
Blocked internally. Something inside the organization could move right now, but hasn’t: missing documentation needs to be associated with the case, an exception needs review, a handoff hasn’t been accepted, ownership is unclear.
Needs human judgment. The next step genuinely requires someone authorized to make a decision — not more waiting, a decision.
These shouldn’t all collapse into one word. The operational response to each is completely different, and a status that can’t tell them apart isn’t giving leadership anything to act on.
Why “Pending” becomes expensive
This is where the cost shows up — not as a fabricated ROI figure, but as an operational consequence anyone running a team will recognize.
The cost of an ambiguous status isn’t the status itself. It’s everything a person has to do to understand it.
Someone opens another system. Someone reads the notes. Someone checks a payer portal. Someone asks another department. Someone sends a message. Someone puts the case on a spreadsheet. Someone brings it up in the morning huddle. Someone checks again tomorrow.
That’s where management attention, staff time, and elapsed time accumulate — not in the waiting itself, but in the manual work of re-establishing what the waiting actually means. And critically: none of that activity necessarily moves the case forward. Much of it exists simply to reconstruct what the case means, over and over, to whoever needs to know next.
A status needs an operating context
This is the conceptual center of the argument. Instead of one word, “Pending” needs to answer five questions.
State — where is the case right now? Blocker — what’s actually preventing movement? Owner — who owns the next action? Next action — what specifically should happen? Time — how long has it been in this condition, and when should something happen next?
State → Blocker → Owner → Next Action → Time.
It’s simple enough to remember and broad enough to apply well beyond infusion — intake, prior authorization, pharmacy, revenue cycle, and just as easily manufacturing, logistics, or finance. Any operation that runs on handoffs runs into this same problem.
The distinction leadership actually needs
Bring this back to the level a COO or VP of Operations actually operates at.
A useful operations view lets leadership tell the difference between “we’re waiting because someone outside the organization hasn’t acted yet” and “we’re waiting because something inside our own operation hasn’t been owned yet.” Those are not the same problem, and they don’t get solved the same way.
That’s why the executive question was never really “how many cases are pending.” A dashboard that answers only that — 47 Pending — hasn’t told leadership anything they can act on. The real question is: which of those pending cases require action from us today?
Don’t solve this with another status field
This is where the argument connects directly to last week’s point: the answer isn’t necessarily another application or another dashboard.
If every team now has to manually maintain State, Blocker, Owner, and Next Action in yet another system, that’s not a fix — it’s simply more work layered on top of the same problem. The better model is to assemble as much of that operating state as practical from the events already occurring in the systems an operation already runs, and direct people only to the exceptions and decisions that genuinely require a person.
That’s orchestration. Not another platform. Not an AI feature. Not an architecture diagram to admire. Just the operating concept, applied to the systems already in place.
Where to start
Before your next operations meeting, pick ten cases marked Pending. For each one, ask: what exactly are we waiting for? Who owns the next action? Is the wait internal or external? When should something happen next?
If those answers require opening several systems, reading notes, messaging another team, or asking someone who “knows how these cases work” — that’s not a status problem. That’s an operating-state problem. And it’s usually a much better place to start than asking what else you can automate.
Waiting is unavoidable. Unowned waiting isn’t.