Most bid teams know the feeling. A security questionnaire lands, and halfway down page four is a question you are certain someone answered beautifully about eighteen months ago — for a client whose name you half remember, in a document saved somewhere that made sense at the time.
You could go and look for it. Or you could just write it again. Neither option is pleasant, and that is worth saying plainly: writing a good answer is real work, and rewriting one you have already written is dispiriting work. The sentence has to be accurate, specific to this buyer, and consistent with what your company said last time. That takes thought whether it is the first draft or the fifth.
So the honest version of the problem is not “writing is easy, searching is hard.” It is that a large RFP asks a team to do three demanding things at once, and all three get harder as the company grows.
Finding what you already said
Search is the part people underestimate. A keyword search across a shared drive gives you
forty files named RFP_response_final_v3, and the only way to know which one holds the
good answer is to open them. Each lookup is small; thirty of them in an afternoon is a
day gone, and it is tedious in a way that makes people reach for the blank page instead.
It gets worse with scale, which feels backwards. The more proposals your company has written, the more places the right answer could be — and the more likely that two of them contradict each other.
What helps:
- Search by meaning, not by filename. The useful question is “what have we said about data residency?”, not “which document has the words data residency in it”.
- Keep the source attached to the answer. Knowing an answer came from the Acme bid in March tells you immediately how much to trust it.
- Treat the content library as a by-product, not a project. Libraries that someone has to maintain on top of their day job tend to drift. Libraries that fill up automatically as submissions go out tend to survive.
The same question wearing different clothes
Questions rarely repeat word for word. One buyer asks whether you hold ISO 27001. The next asks you to describe your information security management system and list relevant certifications. A third asks how customer data is protected in transit and at rest.
Those draw on the same underlying facts, shaped three different ways. A human who knows your business spots that instantly. Keyword search does not, which is why past-proposal search so often comes back empty and the question gets written from scratch anyway.
What helps here is separating the facts from the phrasing. The fact — the certification, the retention period, the uptime figure — should live in one place and be reusable. The phrasing is what you adapt per buyer, and that is the part worth your team’s judgement.
Getting it through review
The third demanding thing is approval, and it is the one most often left out of estimates. A single answer can need the SME who knows the system, security for anything touching data, legal for anything touching liability, and a bid manager making sure the whole document reads as one voice.
Done by hand, that becomes a spreadsheet of statuses, a thread of emails, and someone chasing. The common failure is not that reviewers refuse — it is that nobody can see, at a glance, which of the 300 answers are still waiting on whom.
What helps:
- Make state visible per answer, not per document. “Answer 147 is waiting on legal” is actionable; “the RFP is in review” is not.
- Route by topic automatically. Security questions should land with security without a person deciding each time.
- Let reviewers leave an instruction rather than a rewrite. “Lean on SOC 2 instead, the ISO audit is still in progress” is faster to give than a redrafted paragraph — and it can be reapplied the next time the question comes round.
What a good day looks like
None of this makes RFP work disappear. The goal is narrower and more achievable: when the question on screen is one your company has answered before, you should be reading and adjusting rather than starting over, you should know where the previous answer came from, and you should be able to see who still needs to sign it off.
That is the difference between a submission that eats two weeks and one that takes an afternoon — and between a bid team that dreads the next questionnaire and one that handles it.