← All work
Case study 05 · Public sector · Casework
FOI Case Manager.
A council's Freedom of Information requests, taken off spreadsheets and answered on time.
Case study 05 · Public sector · Casework
A council's Freedom of Information requests, taken off spreadsheets and answered on time.
Anyone can ask a public body for the information it holds, and under the Freedom of Information Act the body has 20 working days to answer. In many councils the process is still manual: requests land in a shared inbox, someone types them into a spreadsheet, counts the deadline by hand and forwards each one to a department by email.
That is where it slips. Bank holidays get missed in the count, the clock isn't paused properly when a requester is asked to clarify, departments get chased by email, and questions that were answered last month get researched again from scratch.
So the brief: one service from request to response, where the system does the counting and routing and officers make every decision.
I used the GOV.UK Design System, the same patterns government and NHS services use: start page, one question per page, check your answers, confirmation panel. Public users already know how it works, and a council team could adopt it without a redesign.
The deadline is counted in working days, skipping weekends and bank holidays, and it pauses while the council waits for a requester to clarify. Every queue is sorted by time left, so the next request at risk is always at the top.
The service suggests a department and shows why (the words it matched) along with a confidence level. Officers confirm or change it, and the timeline records whether they accepted the suggestion. Nothing is routed or sent automatically.
Broad asks like "all emails" are flagged against the 18-hour cost limit, commercial detail against section 43, and names against section 40, so the officer can ask the requester to narrow it on day 2 instead of day 19.
If someone asks for their own records, the service tells them on the check answers page that this is a subject access request, and flags it for the officer. Getting the route right early saves a wasted 20 days.
At intake the service looks for similar answers already in the disclosure log and shows them to the requester and the officer, which cuts repeat work and supports a section 21 response.
Each case shows the request, the statutory deadline, who owns it and a full timeline. The triage panel sits next to the request with the suggested department, the reason, and the things to check before anything is released.
Exemptions are a checklist with the suggested ones tagged. Ticking one rebuilds the draft response from the council's template, including the internal review and ICO wording, ready for the officer to edit and send.
This is a concept on synthetic cases, so these are targets, not results.
I designed and built this, and made the product calls: what the clock counts, what the service may suggest and what only an officer can decide, and which risks to flag at intake. Triage is rules-based on purpose, so every suggestion can be explained.
It's a concept: Westmere Borough Council, the requesters and every case are made up, and no email is sent.
"In public services the win isn't automation for its own sake. It's making the deadline impossible to miss while the officer keeps every decision."