How to Write an RFP Response Prompt With a Compliance Matrix

Most RFP advice online stops at "paste the question, get an answer." That works for one row. It falls apart on the document that actually lands in your inbox: 140 requirements, a security questionnaire bolted to the back, and a Friday deadline. The thing that breaks teams isn't drafting prose. It's tracking which of the 140 are done, which are stuck, and who owns the three that nobody can answer.

An rfp response prompt that earns its keep does two jobs at once. It drafts each answer from a requirements doc and a library of past approved responses, and it forces the output into a compliance matrix so nothing falls through. Requirement, answer, owner, status. Every row accounted for.

This post shows how to build that prompt, why the output contract is the part that matters, and how to keep the model from confidently inventing a compliance claim that gets your bid disqualified.

Why generic "use AI for RFPs" advice doesn't survive a real bid

Search "rfp response prompt" and you get the same shape of post. Loopio's guide on using AI in proposal management gives three drafting prompts but, by its own structure, no compliance matrix, no requirement-to-status mapping, and no worked artifact. Vera's ChatGPT for RFP walkthrough offers extraction and drafting snippets like "extract all questions and return a numbered list," then pivots to why you need their software instead.

Useful as far as they go. But a numbered list of questions isn't a response. The hard part starts after extraction: 140 answers, each tied to an owner, each with a status you can sort and chase. None of those posts hand you a prompt that outputs that.

That's the gap. Not "can AI draft an RFP answer" (yes, obviously). It's "can one prompt draft every answer and return a sortable matrix you can run a bid off." That needs an output contract.

What you can do with an RFP response prompt

• Draft a first-pass answer for every requirement in a questionnaire, pulled from your approved answer library
• Copy exact-match answers verbatim and flag near-matches for light editing
• Mark requirements with no supporting source as NEEDS_SME instead of fabricating a claim
• Assign a default owner per requirement category (security, legal, pricing, technical)
• Output a compliance matrix you can paste into a tracker and sort
• Re-run the same prompt on a new RFP without rebuilding anything

Anatomy of the prompt: variables, instruction, contract

The structure that holds up keeps three things separate: what you paste in, what the model does, and what shape comes back out.

VARIABLES
  {{requirements_list}}   the extracted RFP/questionnaire items, one per line
  {{answer_library}}      past approved answers, each with a topic tag
  {{owner_map}}           category -> default owner (security: Priya, legal: Sam)

INSTRUCTION
  For each requirement, find the best supporting answer in
  {{answer_library}}. Copy exact matches verbatim. Adapt near
  matches and mark them EDITED. If no source supports the
  requirement, leave the answer blank and set status NEEDS_SME.

OUTPUT CONTRACT  (one row per requirement, pipe-delimited)
  requirement | answer | owner | status
  status in {DRAFTED, EDITED, NEEDS_SME, NEEDS_LEGAL}

Put the output contract last. Models weight the most recent tokens, so when you paste a long {{answer_library}}, a contract sitting at the top gets buried under context. Restate the column order on the final line and the format locks far more reliably. This is the same pattern that makes a PRD prompt produce consistent section order across runs.

The refusal rule is the whole point

Here's the opinionated take: the most valuable line in an RFP prompt is the one that tells the model when to give up. Everyone writes the "draft a great answer" instruction. Almost nobody writes the "if you can't support it, say so" instruction. And that's exactly where bids die.

When a Q&A library has no answer for "what year was the company founded," the model doesn't pause. It picks a plausible year. On a security questionnaire, that confident guess becomes a compliance attestation you didn't mean to make. Give the model an explicit empty path (status: NEEDS_SME, answer blank) and it stops inventing.

REFUSAL BOUNDARY
  Never write an answer not supported by {{answer_library}}.
  No source -> answer = "" and status = NEEDS_SME.
  Compliance/legal claim with partial support -> status = NEEDS_LEGAL.
  Do not soften, hedge, or fabricate to fill the cell.

Step-by-step usage

1. Extract the requirements

Pull every numbered requirement, question, and yes/no item into {{requirements_list}}, one per line. If the RFP is a PDF, a separate extraction pass ("return each requirement as a numbered line, no commentary") keeps this clean. Don't merge extraction and drafting into one prompt. They fail differently and you want to debug them separately.

2. Load the answer library

Paste your approved past answers into {{answer_library}}, each tagged with a topic. The richer this library, the fewer NEEDS_SME rows you get. This is the asset that compounds: every bid you win adds answers worth reusing.

3. Fill the owner map

Map each category to a default owner in {{owner_map}}. Security questions route to your security lead, pricing to sales ops. The model assigns the owner per row so the matrix arrives pre-routed.

4. Run and sort

Run the prompt. You get a matrix. Sort by status: chase NEEDS_SME first, route NEEDS_LEGAL to counsel, and let reviewers polish DRAFTED and EDITED. The bid manager works a sorted list, not a wall of prose.

5. Validate before submission

Read every DRAFTED row a human hasn't touched. The model is fast and confidently wrong on edge cases. A wrong compliance claim isn't a typo. Pin the model version for anything you depend on, since an answer that held on one model can drift after an update.

Variables you'll set

Model behavior worth knowing

Claude honors a labeled ## Output format block with the column order more reliably than an inline "respond as a table" instruction, and it respects the NEEDS_SME refusal path well when it's stated as a hard rule. GPT-4o needs the matrix columns restated on the final line of the prompt, otherwise long {{answer_library}} inputs cause it to drift back into prose. Both models hold the format better with two or three example rows than with a paragraph describing the format. Keep those examples in the exact target shape, or the format won't lock.

For the questionnaire variant, add an evidence column and require a source pointer per row. A security reviewer needs to know which past answer or policy backs each claim, the same way a security code review prompt maps each finding back to a CWE rather than asserting a vulnerability with no anchor.

Getting started

1. Extract this RFP's requirements into {{requirements_list}}
2. Gather your last few winning bids into {{answer_library}}
3. Map categories to owners in {{owner_map}}
4. Run the prompt, then sort the matrix by status
5. Chase NEEDS_SME rows, route NEEDS_LEGAL to counsel
6. Read every DRAFTED row before it goes out
7. Save the new approved answers back into the library for next time

If you also handle deal qualification on the sales side, the same structured-output discipline shows up in the MEDDPICC Deal Qualification Rubric, which scores a deal against fixed criteria instead of vibes. And for the post-win motion, browse the full catalog for the QBR and renewal packs.

Two related reads worth your time: the user story acceptance criteria prompt uses the same "fill every field or flag it" discipline, and the PRD prompt shows how an output contract keeps long documents consistent run to run.