An RFP response is a document written under time pressure, by several people, to a format someone else chose, and scored by a process you cannot see. Most of what determines the outcome happens before anyone writes a word — in the decision to bid, the reading of the document, and the structure of the response. This covers the mechanics of producing one that scores well and does not consume three weeks of a small team's life.
First: decide whether to bid
The most valuable skill in RFP work is declining. A response consumes senior time that could go into work you already have, and the base rate for competitive tenders is low.
Signals to walk away:
- The requirements read as if written around a competitor. Specific certifications, an oddly precise feature list, an implementation timeline only an incumbent could meet. Someone helped write this specification, and it was not you.
- No prior relationship and no discovery conversation. If you cannot get a call before the deadline, you are pricing blind against someone who is not.
- The evaluation is price-dominant and you do not compete on price.
- The timeline is impossible and the scope is not.
- You cannot meet a stated mandatory requirement. Mandatory usually means mandatory; a response that fails one is often discarded unread.
Write the no-bid decision down with its reasons. It stops the same question being reopened at every stage, and it is useful evidence when the next similar tender arrives. This is a decision log entry like any other: writing a decision log.
Read the document properly, twice
The single most common scoring loss is failing to answer what was asked.
First pass: read the whole thing, including the annexes, the scoring methodology, and the terms and conditions. The scoring methodology is the most under-read section and the most useful — it tells you where the marks are, and it is frequently very different from where the page count is.
Second pass: build a compliance matrix. Every requirement, numbered, in a table, with the response section that addresses it, the owner, and the status. This is not optional busywork; it is the artefact that prevents the single worst outcome, which is discovering on submission day that requirement 4.7.2 was never answered.
Things to extract explicitly:
- Mandatory versus desirable requirements, and any pass/fail gates.
- The weighting, and therefore where to spend effort. If technical approach is 40% and price 20%, that is where the words go.
- Format constraints: page limits, font size, file format, naming conventions, whether appendices count towards the limit.
- The submission mechanism and deadline, including the time zone and whether the portal closes hard.
- The question deadline, which is usually much earlier than the submission deadline and which people routinely miss.
Ask questions
Most RFPs have a clarification window. Use it.
- Ask about ambiguities you would otherwise guess at, especially anything affecting price.
- Ask whether a mandatory requirement can be met by an equivalent.
- Ask about anything in the terms you cannot accept.
Two things to know: questions and answers are usually circulated to all bidders, so a question that reveals your approach helps competitors. And a requirement nobody asks about is a requirement the buyer assumes is clear — if you think it is ambiguous, so does someone else.
Structure the response for the scorer
The evaluator is a person with a scoring sheet, several responses to read, and limited time. Every structural decision should make their job easier.
Follow their structure exactly. Use their section numbering, their headings, their order. A beautifully organised response in your own structure forces the evaluator to hunt for each answer, and hunting costs marks. If they number a requirement 3.4.2, your response has a heading 3.4.2.
Answer the question first, then elaborate. Each section should open with a direct answer — "Yes, we provide 24/7 support from three regional centres" — before the supporting detail. An evaluator who reads only the first line of each section should be able to score you.
Make compliance visible. A summary table mapping each requirement to where it is addressed, at the front, does real work: it tells the evaluator you have covered everything and shows them where to look.
Include the evidence. Claims score less than evidenced claims. A named reference client, a measured metric, a certification number, a case study with a number in it. "We have deep expertise" is worth nothing; "we run this for 40 sites including [named client], with 99.95% measured availability over the last 24 months" is worth something.
Write for someone who does not know you. The evaluator may not be the person you have been talking to.
The writing
- Plain, specific, and free of superlatives. "World-class", "best-in-breed" and "industry-leading" appear in every response and score in none. See plain language business documents.
- Consistent voice across contributors. Multi-author documents read as multi-author documents unless someone edits the whole thing at the end. Budget for that pass — it is the highest-value editing anyone will do on the response.
- Answer the actual question. A recurring pattern: a question about implementation approach answered with a description of the product. The evaluator scores against the question.
- State assumptions explicitly, particularly in pricing. An assumptions section is what protects you if you win.
- Do not over-length. Where there is no page limit, restraint still helps. A 200-page response to a 30-requirement RFP suggests you cannot distinguish what matters.
The general editing craft: self-editing techniques for better writing and concise writing: cut your word count.
Producing the document
The practical mechanics, which cause more last-day panic than the writing:
- One owner for the master document. Contributions come in as sections, merged by the owner. Parallel editing of one file by six people on a deadline is how versions get lost. See running a document review cycle.
- Version and name files clearly — naming and versioning shared files.
- Submit as PDF unless told otherwise, so the layout is fixed and fonts are embedded — embedded fonts in PDF explained.
- Strip metadata before submitting. The author field, the original filename, and the document history routinely carry another client's name. How to strip metadata from a PDF and PDF metadata and XMP explained.
- Flatten comments and tracked changes. Internal review comments have reached buyers. How to flatten a PDF.
- Check the file size against the portal's limit, and compress if needed — reduce PDF file size.
- Bookmark the sections for anything long — how to add bookmarks to a PDF.
- Number the pages continuously across the whole submission including appendices, so an evaluator can cite a page.
Submit early
Portals fail, files exceed limits, uploads time out, and deadlines are enforced absolutely. Submit a day early if the portal allows resubmission, which most do. The number of otherwise strong responses lost to a technical failure in the final hour is not small.
Keep a copy of exactly what was submitted, with the submission confirmation, in a folder that will still make sense in a year. If you win, that document is now part of the contract; if you lose, it is what you review before the next one.
After the decision
Ask for a debrief whether you win or lose — public sector buyers are usually obliged to provide one, and private buyers often will. Ask specifically about scoring against the criteria rather than for general feedback, which produces platitudes.
Then keep the response. A well-maintained library of previous answers — capability statements, security questionnaires, company information, case studies — cuts the effort on the next tender substantially, provided it is maintained rather than merely accumulated. Store the reusable pieces separately from the client-specific ones, and review them for accuracy annually rather than pasting a three-year-old certification claim into a live bid.
Related: proposal and quote PDFs best practices and writing a business case.
Summary
Decide whether to bid before you start writing, and write the reason down either way. Build a compliance matrix from the requirements and use their numbering as your structure. Answer each question in the first sentence, evidence every claim with something measurable, and budget for one editor to pass over the whole thing so it reads as one document. Then strip metadata, flatten comments, and submit a day early — the avoidable losses are all in that last paragraph.
