Most "where is my application?" calls are a status problem.
If people keep calling to ask where their application is, more phone staff won't fix it. They need to see what state it's in, what happens next, and whether anything is waiting on them.
When a public service gets constant calls asking for status, the fix is usually visibility, not more phone staff. Define a few states a person can understand, such as received, being reviewed, waiting on you, and decided. Show each with what happens next and what the person can do. Notify them when it changes, give staff the same view, and only promise timeframes you can keep.
Dear service lead,
We're writing about the calls. You know the ones. Someone applied for a permit, a benefit, a license, or a grant a few weeks ago, and they haven't heard anything. So they call. They wait on hold. They reach someone on your team, who looks the case up, finds it's moving along normally, and tells them so. The person thanks them and hangs up. Tomorrow, someone else calls about a different case and the same conversation happens again.
Your team is doing good work in those calls. They're patient, they find the answer, they reassure people. But most of those calls didn't need to happen. They're not really questions about the service. They're a person telling you they can't see their own case.
We're writing because this is one of the most fixable problems in public service, and it's often treated as a staffing problem instead. More people on the phones will shorten the hold time. It won't stop people calling.
What the calls are really asking
If you listen to a sample of status calls, the questions tend to collapse into a few:
- Did you get it?
- Is anything wrong with it?
- Are you waiting on me for something?
- When will I hear?
None of those require a person to answer, if the person asking can see the case. And the third one is the expensive one. When an application stalls because something is missing and the applicant doesn't know, it stalls quietly until they call, and then it starts again from wherever it was.
It's also worth noticing what people don't usually ask: they rarely want the internal detail. They don't need to know which unit has it or what the step is called inside your system. They want to know whether they need to do anything, and roughly when something will happen.
A status call is a person telling you they can't see their own case.
Four states a person can understand
Your case system probably has a dozen or more statuses, and they make sense to the people who work in it. For the person waiting, start with four, written in plain language:
Received. We have your application. Here's the date, and here's a reference number.
Being reviewed. Someone is working on it. Here's what usually happens next, and roughly how long this stage takes.
Waiting on you. We need something from you to continue. Here's exactly what, how to send it, and by when.
Decided. Here's the outcome, what it means, and what you can do next, including how to appeal or ask questions.
Map your internal statuses onto these. Several will collapse into "being reviewed," and that's fine. The point is that each state answers the person's real question and tells them what, if anything, they need to do.
Then tell them when it changes. A short message by email, text, or letter, depending on how they applied and what they prefer. Most status calls happen because nothing has arrived in a while. A short message saying "still being reviewed, nothing needed from you" can be enough. It feels almost too simple to matter. It's often the single change that makes the phones quieter, because it answers the question before anyone has to pick up the phone and wait on hold to ask it.
How the work moves
Four states a person can understand
- Received
We have it. Date and reference number.
- Being reviewed
What usually happens next and roughly how long this stage takes.
- Waiting on you
Exactly what's needed, how to send it, and by when.
- Decided
The outcome, what it means, and how to appeal or ask.
What staff need on their side
The same visibility helps your team. When someone does call, the person answering should see exactly what the applicant sees, plus the internal detail behind it. That way they're never guessing what the applicant was told.
It also changes what happens with "waiting on you." If a case is stalled waiting for a document, staff should be able to see how long it's been waiting, whether a reminder went out, and whether the applicant opened it. After a set time, the case should come to someone's attention, rather than sitting until the applicant calls.
This is the part that usually needs real work behind the scenes. Status lives in more than one system, cases move between departments, and some of the information sits in email. Bringing it into one shared view of what happens next, without asking staff to re-enter anything, is where most of the effort goes.
Decision guide
Status for the office, or for the person waiting
| Consideration | Status for the office | Status for the person waiting |
|---|---|---|
| Names | Internal step and unit codes. | Plain-language states that say what happens next. |
| Updates | Visible when someone looks it up. | A short message whenever the state changes. |
| Missing items | Noted on the file. | Told exactly what's needed and how to send it. |
| Timing | Target dates in a policy document. | Honest ranges based on how long stages really take. |
| Phone calls | Staff look up the case from scratch. | Staff see what the applicant sees, plus the detail behind it. |
Keep the promise small and true
One caution, because this is an easy one to get wrong. When you start showing status, it's tempting to show a precise date. "Decision by November 14." If that date is a guess, you've traded a status call for an angry call.
Show what you can stand behind. A range for each stage, based on how long that stage really takes, not how long it should take. A clear sign when a case is taking longer than usual, and what that means. And a way to reach a person when something genuinely needs one.
Plain language and accessibility are part of this too. The status page and messages need to work for someone using a screen reader, someone on an old phone, and someone who doesn't read English as a first language. Requirements vary by jurisdiction and service, so agree them for your service at the start rather than bolting them on later.
A first step, and a signature
If this sounds like your service, here's where we'd start. Pick the one service that generates the most status calls. Listen to twenty of them, or ask the team to note the question behind each call for a week. Write the four states for that service in plain language. Then find out where the information for each state actually lives today.
That's usually enough to see whether the fix is a small change to the messages people already get, or a proper shared view across systems. Either is worth doing.
This is the work we do in government and public sector: tracing a real service journey with the team that runs it, building clear digital steps for the people using it, and connecting the work behind them, with accessibility, permissions, traceability and handover planned from the start. If your team spends its days answering "where is my application?", write back. We'd like to hear which service it is, and what the people calling most want to know.
Sincerely,
TWIMCO, from the studio
Related work: PatientIQ.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.