If the status says approved, can they act?
The portal shows Approved in a comforting green. The resident still cannot book the inspection, print the license, or stop visiting the desk. Status labels that describe your backlog instead of their next step waste everyone's morning.
Rewrite public statuses so each one names what the person can do next, what you are still doing, and whether a desk visit is required. Pair every status with a single next action in the interface. If Approved does not unlock an action, it is the wrong word.
The green word that lies politely
People refresh portals the way they once called clerks. They see Submitted, In review, Additional information needed, Approved, Closed. Approved feels like the end. Then they learn they still need a badge photo, a wet signature, or a Tuesday appointment two weeks out.
A status is a promise about the next move, not a label for your internal queue. When the word describes your swimlane and not their agency, you manufacture duplicate calls, lobby traffic, and distrust—exactly the load digital services were supposed to reduce.
Staff feel the pain too. Clerks re-explain the same green word fifty times a day because the portal and the desk script diverged. Status honesty is an operations intervention that looks like copywriting.
Argue from the resident's job
The resident's job is not "know which queue my PDF sits in." It is "know whether I can operate, drive, build, sell, or enroll tomorrow—and what I must do if not."
Test every status string with one question: if this is the only sentence they read on their phone in a parking lot, can they decide what to do in the next ten minutes? If the honest answer is "call us to find out," the status is unfinished work.
This is why putting the PDF online is not the same as putting the service online—we have written about that pattern before. Status honesty is the same family of problem as paying online and still visiting the desk: the digital step completed something, not everything.
Accessibility matters here: screen readers should announce the next action, not only a color name. "Approved" as the sole text content of a badge fails that test when the real meaning is "pay and schedule."
How the work moves
Rewrite a public status
- Parking-lot test
Can a resident decide the next ten minutes from the sentence alone?
- Split meanings
Separate our progress, their permission, and their chore.
- One action
Pair the status with a single primary button or an explicit wait.
- Desk script
Give clerks the same sentence the portal shows.
- Measure
Watch where-is-my-case calls on that status.
A status is a promise about the next move, not a label for your internal queue.
Separate three meanings people collapse
Most confusing portals smash three ideas into one colored pill:
- Our progress — a staffer has or has not finished a review.
- Your permission — the law or policy now allows you to act.
- Your next chore — upload, pay, appear, wait for mail.
"Approved" often means (1) only. Speak (2) and (3) out loud. "Approved — book your inspection" and "Approved — license prints after fee posts" and "Decision complete — desk visit still required for ID check" are longer. They are also true.
If you need an internal code for the case management system, keep it. Do not show it. Map internal codes to public sentences owned by the program lead, not by whichever vendor themed the CSS.
Multilingual portals need the same discipline. A translated "Approved" that still hides a desk visit is not localization—it is a wider blast radius for the same confusion.
Decision guide
Internal queue label vs resident-facing status
| Consideration | Internal label | Resident-facing status |
|---|---|---|
| Audience | Staff swimlanes and SLAs. | Someone deciding what to do today. |
| Vocabulary | Codes, queues, reviewer names. | Permission and next chore in plain words. |
| Approved | Reviewer finished a step. | You may act—or here is the remaining step. |
| Pending | Sitting in a backlog. | Waiting on you / waiting on us / waiting on mail. |
| Success | Case closed in the CMS. | Resident stops calling to ask what it means. |
Design the screen around one next action
Every status view should offer exactly one primary button that matches the sentence: Upload documents, Pay fee, Schedule appointment, Download certificate, or Nothing to do — we will email you. When the next action is wait, say what will change the status and how they will hear.
Secondary links can explain process. They should not compete with the action. If your government and public sector service has five competing CTAs under Approved, you are asking residents to solve a puzzle you already solved internally.
Track the "where is my application" calls by status. The statuses that generate the most calls are your rewrite queue—see also our note on where-is-my-application calls.
If the next action is offline (mail a form, visit a county office), say the address, hours, and what to bring. A status that dumps people into a PDF attic is how "digital transformation" recreates the filing cabinet.
Make the argument in governance, not only in UX
Product and engineering can rename strings. Program owners must agree what each string authorizes. Put a one-page matrix in the runbook: status → legal meaning → channel message → desk script. When policy changes, the matrix changes in the same release as the portal.
Without that, marketing language creeps back in ("You're almost there!") and clerks invent spoken definitions that diverge from the screen.
When vendors configure case management defaults, insist the public labels are in your acceptance tests. Otherwise a patch can restore internal jargon on a Friday deploy and regenerate Monday's call spike.
A before-and-after sentence pair.
Before: "Approved." After: "Approved — pay the fee, then schedule your inspection. Desk visit not required." Before: "Pending." After: "Waiting on you — upload the missing insurance certificate." Before: "In review." After: "With our team — typical review takes up to ten business days; we email when the next step is yours."
Those sentences are longer on purpose. Portals have room. Confusion is more expensive than pixels. If a vendor theme truncates status text, fix the theme; do not shorten the truth until it fits a chic pill.
Pilot the rewrite on one high-volume case type before a global string catalog change. Clerks and call-center partners need the same week of notice you give residents. A portal that updates overnight while desk scripts lag creates a new species of confusion: two authoritative-sounding answers that disagree.
Publish a tiny glossary on the portal itself: three or four statuses with one-sentence meanings. People in stress do not open a twenty-page FAQ. The glossary should match the matrix in the runbook character for character. When policy changes, update glossary, portal strings, and desk script in one release train.
If your contact center uses a different case tool than the public portal, integrate or duplicate the public sentence into the agent desktop. Hearing "the system says approved" while the resident reads "desk visit required" on their phone is an avoidable own-goal.
When in doubt, read the status out loud to someone outside your agency. If they ask a follow-up question before they can act, the sentence is not done.
Put this into practice
This week: export your top ten public statuses. Rewrite any that fail the parking-lot test. Ship one painful rewrite with a matching primary button. Measure call volume on that case type for two weeks.
If the case system cannot express next actions yet, that is the backlog item—not another shade of green. Talk to us when you want the status model and the desk script designed together.
Related work: Wellthie.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.