Most digital transformation projects can slip a quarter without anyone outside the team noticing. Statutory information requests are not like that. A Freedom of Information request carries a 20-working-day clock. A Subject Access Request runs to a calendar month, extendable only in genuinely complex cases. These deadlines are set in law, they don't pause for staff holidays or a system migration, and missing them is not a missed KPI - it's a compliance failure with a regulator at the end of it.

That difference in stakes is exactly why information requests are one of the best places a public-sector organization can start its automation journey, and one of the worst places to get it wrong. Here's how to think about doing it well.

Why these requests resist the usual playbook

A lot of casework digitization starts and ends with "put a form on the website." For information requests, the form is the easy 5%. The hard part is everything that happens after submission, and it's hard for reasons specific to this work:

The clock starts on receipt, not on triage. A request that lands in a shared inbox on Friday afternoon and isn't logged until Wednesday has already burned four working days. Any system that doesn't timestamp and start the countdown at the moment of arrival is leaking your deadline before a human has even read the request.

The work is distributed but the accountability is central. A single SAR might require a housing team, a finance team, and a contact-center to each search their own records. The person responsible for the legal deadline usually owns none of those systems. They are chasing colleagues by email and hoping nothing was missed - which is precisely the failure mode that produces both late responses and incomplete ones.

Every step has to be defensible. If a response is challenged, you need to show what was searched, what was found, what was withheld, and why. That audit trail isn't a nice-to-have you add later. It's a core requirement, and bolting it on after the fact almost never works.

Treat information requests like a generic "submit a form, route a ticket" workflow and you'll automate the visible part while leaving the risky part - coordination, deadline tracking, defensibility - exactly as manual and fragile as it was before.

What good actually looks like

A few principles tend to separate the projects that reduce risk from the ones that just digitize it.

Make the deadline a first-class object. The countdown should be calculated automatically from the date of receipt, visible on every case, and driving escalations on its own. Staff shouldn't have to remember a date or do the working-day math; the system should be surfacing "this is due in three days and two contributors haven't responded" before anyone has to ask.

Model the request type, not just "a case." FOI, environmental information requests, SARs, complaints, and elected-member enquiries share a shape but differ in legal basis, deadline, exemptions, and who must be involved. A single rigid template forces staff to work around it; a system that understands request types can apply the right rules and route to the right people automatically.

Coordinate the contributors, don't just notify them. The value isn't an email saying "please search your records." It's a structured task with a due date, a way to attach what was found, and a status the case owner can see at a glance. Turn the invisible chasing into visible, trackable tasks and the central owner stops being a bottleneck.

Build the audit trail as you go. Capture decisions - what was redacted, which exemption was applied, who approved the release - at the moment they happen, as structured data rather than free-text notes. Done this way, defensibility is a byproduct of normal work rather than a scramble when a response is challenged.

Start narrow and prove it. SARs are often the smartest pilot: high-stakes enough to matter, but more self-contained than the full FOI process. Get one request type genuinely working end to end before you generalize the pattern across complaints, FOI, and member enquiries. A working pilot earns the trust - and the budget - for the wider rollout far better than a big-bang program that tries to do everything at once.

The integration question you can't skip

Information requests are, fundamentally, a "go find everything we hold about X" problem. That means the workflow is only as good as its reach into your other systems. If a SAR requires someone to manually log into four applications and export records by hand, you've automated the paperwork and left the actual work untouched.

This is where an API-first posture pays off. The case-management workflow should be able to query other systems for relevant records, and ideally pull what it can automatically rather than relying on a human to remember which systems to check. You don't have to integrate everything on day one - but you should design as if you will, because the manual search step is both the slowest part of the process and the easiest place to miss something you were legally required to disclose.

The payoff

Done properly, the result isn't just "faster." It's a shift in where the risk sits. Instead of a deadline that lives in one person's head and a process held together by reminder emails, you get a system that knows what's due, who owes what, and what's been decided - and tells you before something is about to be late rather than after.

For an organization weighing where to begin with workflow automation, that combination is hard to beat: a problem with genuine legal urgency, a clear and measurable outcome, and a pattern that, once proven on one request type, extends naturally across a whole family of statutory casework. The deadlines aren't going to get more forgiving. The case for getting ahead of them only gets stronger.

Thinking about bringing statutory casework - FOI, subject access requests, complaints, or member enquiries - onto a single, auditable platform? Get in touch to talk through where to start.