JIRUH SOLUTIONS FOR COMPLEX GTM

Service requests

The queue your office doesn’t know it’s running

Registrars, records desks and permit counters all run real request queues. Hardly any of them can see theirs, and the delays get blamed on staffing.

Requests arriving by email, walk-in, paper and web portal merging into one visible queue of 186 open requests, then routed to student services, records, admissions and financial aid.

A registrar’s office, a hospital records desk and a city clerk’s counter look nothing alike. Underneath, they’re doing the same thing. Requests come in through several doors, response times swing wildly, and nobody can tell you how many are open right now or how old the oldest one is.

A call centre would never run like that. Queue length and how long people wait are the first things a call centre supervisor looks at every morning. Back offices run the same kind of queue with none of that visibility, then put the delays down to being short-staffed.

Usually the bigger problem is that the queue is invisible.

Too many front doors

One type of request, say a transcript, a records disclosure or a permit, often comes in four ways. A web form, the front counter, a general inbox, and a phone call that ends up on a sticky note.

Each channel has its own way of keeping track, or none. So nobody can see the real size of the backlog in one place.

Pull them into one queue, whichever door the request came through. Do that first, because nothing else works without it. You can’t put a deadline on, assign an owner to, or measure a backlog you can’t see.

Requests die at the boundary

Once intake is in one place, the next weak spot is the handoff between whoever received the request and whoever has to act on it.

A student’s re-enrolment goes from admissions to the registrar to financial aid. At each boundary there’s a real chance it gets put down and not picked up, because no single handoff has an owner or a deadline.

It’s the same pattern we describe in where approvals actually get stuck. The waiting happens between steps, not inside them. The fix is the same as well: an owner for every handoff, a clock on it, and an automatic escalation when the clock runs out.

Before you ask for more staff

It’s tempting, and politically easier, to treat a growing backlog as a headcount problem. “We need two more people” doesn’t make anyone look at how work actually moves.

But add people to a queue nobody can see and you mostly get more capacity sitting at the same broken handoffs. Fix the routing, look at the queue properly, then decide on staffing. You’ll have a stronger case either way, and it’s often a smaller request than the one you started with.

What changes when you can see it

A supervisor can see how many requests are open and how old the oldest is, at a glance. Someone asking how long their request will take gets a real answer. And when an auditor turns up, the trail is already there, with times on it, instead of being pieced together from email.

Fair warning: the first time an office sees its own queue, the oldest open request is usually older than anyone wants to admit. That discomfort is useful. It’s often what finally gets the fix prioritised.

Seeing this in your own teams?

Tell us where work is getting stuck and we’ll tell you whether we can help. No deck.

Send us a message