How to Make a Records Request Painless (for the Team Answering It)
A records request lands in the inbox and a small dread settles over the office. Someone has the legal right to a set of documents, there is a clock attached, and the documents in question are scattered across email threads, a shared drive, three people's laptops and a filing cabinet whose key situation is unclear. The request itself is reasonable. The panic it causes is entirely self-inflicted, and it was inflicted months ago.
Here is the reframe that changes everything: a records request is not a research project you start when it arrives. It is a withdrawal from an account you have either been funding all along or have not. The teams who answer requests in an afternoon are not faster on the day. They made different filing decisions a year earlier, when no request was in sight and there was no pressure to do so.
Why the same request costs one team a day and another a month
Two organizations get an identical request: all records relating to a particular contract over a two-year period. The first team knows where that lives, because every document about that contract was filed against the contract from the day it began. They pull a folder, review it, redact what the law requires, and respond. The second team starts a manhunt — searching inboxes by keyword, asking former staff what they remember, hoping the relevant version of a document is the one that actually got saved.
The difference is not effort or talent. It is that the first team treated the record as a permanent asset and the second treated it as exhaust from getting work done. The request did not create that gap. It just shone a light into it, on a deadline, in front of someone with the authority to be unhappy about what they find.
Build for the request before it arrives
You cannot predict which request will come, but you can make any request cheap to answer. The work is unglamorous and it is entirely front-loaded:
File by subject, not by sender. A document about a project belongs with the project, not buried in the inbox of whoever happened to email it.
Keep one authoritative version. The single most expensive moment in a request is realizing you cannot tell which of five drafts is the one that actually went out.
Make metadata a habit: date, author, what it relates to. These are the handles a future search will grab. A file with no handles is a file you will read one by one.
Decide retention deliberately. Knowing what you are required to keep, and for how long, is half the answer before the question is asked.
Assume someone outside the team will read it. The test for any record is whether a stranger could understand it without the context that lives only in your head.
Every one of these is a small decision made at the moment a document is created. None of them can be made retroactively under a fourteen-day clock, which is precisely why the unprepared team cannot simply work harder to catch up.
The request is a free audit — treat it that way
It is worth flipping the dread on its head. A records request is an outside party telling you exactly where your record-keeping will be tested, with enough notice to respond. That is closer to a gift than a threat. The pain you feel answering it is a precise measurement of the disorganization that was already there, quietly, in everything else you have not been asked about yet.
So do the cheap thing this quarter. Pick the topic most likely to be requested — a contentious contract, a high-profile project, anything with public attention — and assemble its file now, before anyone asks. If it comes together in an hour, you are ready. If it takes a week, you have just found, in calm conditions, the exact work that a real request would have forced you to do in a panic.
We walk through one of these everyday records failures every week in our records and accountability series. The lesson is consistent: a painful request is never really about the request. It is about every ordinary filing decision that came before it.
