The FOIA status page that never emails the requester

Does the portal email when status changes?

If the honest answer is "the requester can check the website," you do not have requester notification. You have a status page. Those are different products.

People file records requests and then go back to their lives. They are not employees with your board open all day. When a request moves from received to clarification needed, or from review to ready for pickup, that move should produce a message they did not have to hunt for. Otherwise they call the clerk, the clerk re-explains, and your "self-service portal" becomes a call generator with a nicer coat of paint.

This is adjacent to, not the same as, the multi-person path inside the agency. We have written about how a records request passes through five people. That note is about internal handoffs. This one is about the person outside who is waiting.

What counts as a meaningful status?

Not every internal keystroke deserves an email. Flooding people with "staff viewed your file" trains them to ignore you. Aim for statuses the requester can act on or that change their expectations: received, needs more information, extended with a new date, ready, denied with a path to understand why, closed.

Each message should say what changed, what if anything they must do, and how to open their request without hunting. If your portal already struggles with deep links, fix that with the same seriousness you would fix a broken parcel tracker. A status email that lands on the homepage is how you recreate the phone call you hoped to avoid.

What if email fails?

People typo addresses. Agency spam filters eat outbound mail. "We sent it" is not the same as "they got it." Keep a visible last-notified timestamp on the staff view. Offer a second channel where law and policy allow—SMS for ready-for-pickup is common in other domains—and always keep the status page accurate so a determined requester can still self-serve.

When you buy software, ask the vendor to show a failed-email path in the demo, not only the happy path. Ask where bounces go and who is responsible for cleaning addresses. If the demo cannot answer, you will staff that gap forever.

What should we put in the RFP or build brief?

Require: outbound notice on the meaningful statuses you define; templates staff can edit without a deploy; audit of what was sent when; requester authentication that still allows a magic link from the email; plain-language status names, not internal codes like REV_2.

Require reporting: count of requests with a status change and no successful outbound notice in N days. That metric keeps the portal honest. Without it, teams optimize for staff throughput and quietly drop the public.

Accessibility and language access belong here too. If your city must offer notices in more than one language, the email path has to honor that, not only the web form.

How this shows up in real weeks

A journalist files Friday afternoon. Monday the clerk needs a narrower date range. Without email, the request sits until the journalist follows up on Thursday, burning most of a week inside a silence that looked like progress on the staff board. Or a resident waits for housing records before a hearing date; ready-for-pickup that never notifies means they miss the window and blame the agency for opacity they experienced as neglect.

Staff feel this too. Clerks who answer the same "any update?" calls all morning are not lazy; they are the human notification layer for software that declined the job. When you staff up for FOIA volume, ask whether you are staffing notice debt.

Vendors sometimes demo beautiful kanban boards for staff and treat requester email as a phase-two checkbox. Believe the checkbox. Phase two rarely arrives before elections and budget season move on. Make outbound notice part of go-live, not part of the roadmap slide.

If legal counsel worries about creating new records by emailing status, involve them early and design templates they approve—silence is still a worse public experience than a lawful, boring notice.

Buying vs building the notice path

If you are buying a portal, insist on seeing a live status-change email in the sandbox with your domain's SPF and DKIM in mind. Ask whether templates are code deploys or staff-editable. Ask for bounce handling. Ask whether magic links expire and what the requester sees then.

If you are building, do not bury notice in a generic notification microservice that other teams can turn off. Records notice is part of the records product. Give it its own templates, its own metrics and its own owner in the clerk's office—not only in IT.

Either path fails the same way when leadership measures intake volume and ignores notice success. Put "percent of meaningful status changes with successful outbound notice" on the same monthly report as request counts. What gets reported gets staffed.

A status the requester never hears is just an internal note with a public URL.

Put this into practice

Train clerks to paste the requester-facing status sentence into the outbound template fields rather than inventing a new email each time; consistency is what makes the audit trail useful. Write it down where peak hires will actually read it. Write it down where peak hires will actually read it.

Start with the ten open requests exercise even if it feels anecdotal. Leadership often believes the portal "already notifies" because a checkbox exists in settings that nobody enabled for production templates. Screenshots of silent status changes convince faster than architecture diagrams.

While you are there, read three requester emails your portal already sends—if any. If they read like internal codes, rewrite them with a clerk, not with marketing. The voice should sound like a public servant explaining a next step, not like a SaaS lifecycle campaign.

Pick ten open requests. For each, list the last status change and whether the requester was notified through something other than "they might have refreshed." If the list is mostly silence, stop buying new intake features and finish notice first. Then put the notice requirement in every vendor renewal that touches records.

We build government and public sector systems where the public path and the staff path stay aligned. If your portal updates quietly, talk to us.

Related work: Sutton|Place.