The RFP answer library structure
The fields every library entry carries, the verification windows by answer type, and the status flow that keeps the agent reading only checked answers. Set it up as a Notion database or a spreadsheet, point the brief at it, and every RFP starts from answers a named person has confirmed.
- canonical question: phrased the way buyers ask it; one entry per real question
- approved answer: the facts in plain words; the agent adapts vocabulary per buyer and keeps the facts fixed
- source: the document and section the answer is true because of
- owner: a named person, never a team
- verified: the date the owner last confirmed it; blank on proposed entries
- status: proposed / approved / archived; the agent reads approved only
- tags: security, compliance, product, legal, company; used to route exceptions
- infrastructure, subprocessors, certifications, data residency, retention: 90 days
- product capability and roadmap: every release, or 90 days
- legal terms (DPA, SLA, breach notification): on every contract-template change, or 180 days
- company facts (headcount, funding, insurance, offices): 365 days
- proposed: drafted by the agent from a source passage during an RFP, no verified date
- approved: an owner confirmed it and set the verified date; now a source for the agent
- stale: approved but past its window; the agent drafts from it and flags STALE
- archived: superseded or wrong; kept for history, never read by the agent
- no source, no answer: NEEDS A HUMAN with the reason and the closest passage
- never infer certifications, regions, retention periods, or subprocessors
- preserve the buyer's numbering, sections, form, and limits
- exceptions grouped by owner and sent on day one; proposed entries approved within a week of shipping
The verified date is the field I would defend hardest. Every other field describes the answer; that one is the only thing standing between your library and the eighteen-month SSO problem.
The stack
- Per RFP
- one run over 200 questions and a dozen source docs, a few dollars on a mid-tier model; cache the library
- Notion / Drive
- free over MCP; a Project works with an exported library for small teams
- Setup
- a day: the library from your last three RFPs and the security docs, the brief, one RFP run alongside the old way
- The saving
- the 190 answers an AE used to write by search and paste, and the deal you keep by never shipping a stale one
The problem
The RFP that taught most teams this lesson arrived on a Friday with 214 questions and a deadline the following week. The AE did what everyone does: opened the last two RFPs, searched for keywords, and pasted. Answer 61, about single sign-on, came from a response written eighteen months earlier, before the SAML work shipped, and said the feature was on the roadmap. The buyer's security team read it, checked the product docs, found the contradiction, and asked in the next meeting whether the rest of the answers could be trusted. The rest of the answers were mostly fine. It did not matter.
This is how RFP responses fail: quietly, on provenance. An approved-answers document exists, in three versions, in two drives, and nobody knows which one is current. Answers written for a bank get reused for a hospital. A 'yes' about data residency written when the product ran in one region survives two infrastructure migrations. And the person answering is an AE with a quota, under a deadline, doing the work by search and paste because there is no other way to do 214 questions in a week.
The generic fix, paste the RFP into a chatbot and let it answer, is worse. A model with no sources answers confidently from what it read on the internet about companies like yours, and a confident wrong answer in a security questionnaire is a deal-ending event. The security questionnaire template on this site handles the single-questionnaire case with a structured prompt and a human in the loop. This play is the system underneath it, for the team that answers one of these a week.
A Claude agent over your own sources does what a great proposal manager would do with unlimited time: for every question, find the approved answer in the library or the paragraph in the source doc that answers it, draft the response in the buyer's requested form, and write down where it came from and when that source was last checked. When there is no source, it says so and puts the question on the human list instead of guessing. The output is a draft with a provenance column, an exception list of twenty questions for the AE and the security lead, and an answer library that is one deal richer than it was last week.
How it works
- 01 Drop the RFP The buyer's fileXLSX, DOCX, PDF, portal export
- 02 Parse the questions Claudenumbering, sections, required form
- 03 Read the library Notion / Drive (MCP)approved answers, verified dates
- 04 Read the sources Notion / Drive (MCP)security, DPA, architecture, product
- 05 Draft with provenance Claudesource, section, date per answer
- 06 Flag the exceptions Claudeno source, conflict, stale, by owner
- 07 Export + propose Claudebuyer's format; new library pages to approve
- The AE drops the buyer's RFP or questionnaire file into the run folder, in whatever format it arrived (XLSX, DOCX, PDF, a portal CSV)
- Claude parses the questions with their numbering and sections, and reads the answer library plus the source docs (security, compliance, product, architecture, past responses) over MCP from Notion or Drive
- For each question it finds the matching approved answer or the source passage, drafts the response in the requested form (yes/no plus explanation, a paragraph, a word limit), and records the source, the section, and the source's last-verified date
- Questions with no source, a conflicting source, or a source older than your verification window are marked 'needs a human' with the reason, and routed to a named owner (security lead, product, legal)
- It exports the draft in the buyer's format with the provenance in a hidden or adjacent column, plus an exceptions list the AE works through with the owners
- After the response ships, new or corrected answers are written back to the library as pages with source, owner, and verified date, so the next RFP starts from more checked answers
See it run
The playbook
Build the answer library the agent is allowed to read from
The library is the whole play, and it has one rule: every answer in it has a source and a last-verified date. Start from your last three RFPs and your security documentation (SOC 2 report summary, the security overview, the data processing terms, the architecture doc). For each approved answer, create one page: the canonical question, the approved answer, the source document and section it comes from, the owner (security, product, legal, or the AE team), and the date someone last confirmed it is still true. The structure below is the one I use.
Put the library and the source docs where Claude can read them over MCP: a Notion database is the easiest, a Drive folder works. Keep the source docs themselves in the same place, because the agent should be able to fall back from 'no approved answer' to 'here is the paragraph in the architecture doc that answers this', and cite it.
Decide the verification window with the security lead. Anything about infrastructure, subprocessors, certifications, or data residency should be re-verified every 90 days; product capability answers every release; company facts (headcount, funding, insurance) annually. An answer past its window is still shown to the agent, but it is flagged, never pasted.
TipGive every answer an owner who is a person, not a team. 'Security' never re-verifies an answer. 'Priya, by Dec 1' does.
Connect the sources and pick the path: Project or Code
For a small team that answers a questionnaire a month, a Claude Project is enough: add the library export and the source docs to the Project's knowledge, put the brief below in the Project instructions, and the AE drops the questionnaire into a chat. The provenance rule and the 'needs a human' rule live in the instructions, so every chat follows them.
For a team answering one a week, or with a library that changes often, run it in Claude Code with Notion or Drive connected over MCP, so the agent reads the live library rather than an export, and the export to the buyer's format is a command instead of a copy-paste. The MCP directory covers what the Notion and Drive servers expose.
Either way, the agent reads sources and writes drafts. It does not send anything to the buyer, and it does not edit the library on its own. New answers go into a 'proposed' state that the owner approves, because an unreviewed answer that gets reused is exactly the eighteen-month-old SSO problem with a faster copy machine.
- Reads: the answer library (question, answer, source, owner, verified date, status)
- Reads: source docs: security overview, compliance reports and summaries, DPA, architecture, product docs, subprocessor list
- Reads: the buyer's questionnaire file and any instructions (word limits, yes/no format, portal fields)
- Writes: the draft in the buyer's format with a provenance column, the exceptions list, and proposed library pages awaiting an owner's approval. Never a message to the buyer
Write the brief so no answer ships without a source
The brief is a set of rules the agent follows for every question, and the first one carries the whole play: draft an answer only from an approved library entry or a passage in a source document, cite it, and if neither exists, write 'needs a human' and the reason. A model will answer anything you ask it. The brief's job is to make it refuse well.
Make it match the buyer's form exactly. RFPs specify yes/no with explanation, character limits, 'describe' paragraphs, or a portal's dropdowns, and a response that ignores the form gets marked down before anyone reads it. Tell the agent to preserve the buyer's numbering and section headings, respect every limit, and answer in the buyer's vocabulary while keeping your facts, so 'tenant isolation' becomes whatever the buyer called it in question 47.
Ask for the exceptions list as a first-class output, sorted by owner. Twenty questions that need a human, grouped as 'security lead: 9, product: 7, legal: 4', each with the question, why the agent could not answer it (no source, conflicting sources, source past its window), and the closest thing it found. That list is the AE's week. The other 194 answers are a review, not a writing job.
You are drafting responses to the attached RFP or questionnaire for {{COMPANY}}.
Sources you may use, and nothing else:
1. The answer library at {{LIBRARY}} (fields: question, approved answer, source, owner, verified date, status). Use only entries with status = approved.
2. The source documents at {{SOURCES}}: security overview, compliance summaries, DPA, architecture, product docs, subprocessor list.
For every question in the buyer's file, in the buyer's numbering and order:
- Find the approved library entry that answers it. If none, find the passage in a source document that does.
- Draft the answer in the exact form the buyer asked for (yes/no plus explanation, paragraph, character limit, portal option). Use the buyer's vocabulary; keep our facts.
- Record provenance: source name, section or page, verified date. If the verified date is older than {{WINDOW_DAYS}} days, keep the draft but mark it STALE.
- If no approved entry and no source passage answers the question, or two sources conflict, write NEEDS A HUMAN with the reason and the closest passage you found. Do not answer from general knowledge. Never infer a certification, a region, a retention period, or a subprocessor.
Outputs:
1. responses/{{BUYER}}/draft.xlsx: the buyer's columns, plus provenance and status columns (SOURCED / STALE / NEEDS A HUMAN).
2. responses/{{BUYER}}/exceptions.md: every STALE and NEEDS A HUMAN item grouped by owner, with question, reason, closest passage.
3. responses/{{BUYER}}/proposed-library.md: any answer you drafted from a source passage that has no library entry yet, written as a proposed entry with source and a blank verified date, for an owner to approve.
Do not contact the buyer. Do not edit the library. Do not mark any answer approved.TipBan inference explicitly for the four things buyers check first: certifications, regions, retention periods, and subprocessors. Those are the answers that end deals when they are wrong.
Run it on the day the RFP lands, then work the exceptions
Drop the file in and run it the same afternoon. In under an hour the AE has a draft with every sourced answer in the buyer's form, an exceptions list grouped by owner, and a set of proposed library pages. Send each owner their section of the exceptions on day one, with the deadline, because the security lead's nine questions are the critical path and they always were.
Review the sourced answers as a reviewer, not a writer. Read them in the buyer's file with the provenance column open, spot-check a dozen against the source, and read every STALE answer in full. Where the agent chose an approved answer that fits badly, the fix is usually a library page that is too broad, and splitting it improves the next RFP as well as this one.
Run the first two RFPs alongside the old way with your best proposal person and compare. The agent's draft should match theirs on the sourced answers and beat them on provenance, since they never wrote down where anything came from. Where the human's answer is better, look at whether the source document is thin; the agent can only be as good as the passage it cited.
Write the new answers back, with an owner
Every RFP teaches the library something: a question nobody had asked before, a better phrasing of an old answer, a stale answer that got corrected under deadline. The proposed-library output captures all of it, and the discipline is to approve it within a week of shipping the response, while the owner still remembers the context. A proposed page an owner approves gets a verified date and becomes a source for the next run. One that sits for a month gets archived.
Set a quarterly re-verification run: the agent lists every library entry past its window, grouped by owner, and each owner spends thirty minutes confirming or correcting. That half hour a quarter is what stops the eighteen-month SSO answer from ever existing again, and it is the part every team skips until the buyer's security team does it for them.
Watch the library's coverage rate: the share of questions in each new RFP that were answered from an approved entry without a human. It should climb from something like 60% on the first RFP toward 85-90% by the fifth. If it stalls, the questions your buyers ask have moved and the library has not, which is a signal for product and security as much as for sales.
TipApprove proposed answers within a week of the response shipping, while the owner remembers why it was worded that way. After a month, nobody does, and the page gets archived instead.
Extend it to the security portal and the renewal questionnaire
Once the library covers most of a standard RFP, point the same brief at the other places the same questions arrive: the security portals buyers now use instead of spreadsheets, the annual vendor-review questionnaire from existing customers, the due-diligence list from a procurement team. They are the same questions with different numbering, and a library with provenance answers them all at the same coverage rate.
Add the buyer's follow-up questions to the run. The second round of an RFP is usually twenty clarifications on the first round's answers, and the agent handles those best when it can read its own first-round draft with the provenance intact, so the clarification cites the same source as the original.
Keep the boundary where it started. The agent drafts from sources and flags the rest. A person approves every new library entry, a person sends the response, and the security lead owns the answers about security. A team that lets the agent approve its own answers has built a very fast way to be confidently wrong at scale, which is where this play began.
Inside the prompt
The scoring prompt is short, but every line is there for a reason. Here is what each one is doing and why.
- Sources, and nothing else"Sources you may use, and nothing else"
- The line that makes the play safe. A model will answer anything; this brief makes it refuse when it should.
- Approved only"Use only entries with status = approved"
- Proposed pages from the last deal are not sources yet. An owner's signature is what makes them one.
- The buyer's form"in the exact form the buyer asked for"
- Yes/no in 250 characters means yes/no in 250 characters. Form errors get marked down before content is read.
- STALE, not silent"If the verified date is older than {{WINDOW_DAYS}} days, keep the draft but mark it STALE"
- The answer is probably still true. The flag makes someone check, which is the eighteen-month SSO fix.
- Never infer the big four"Never infer a certification, a region, a retention period, or a subprocessor"
- The four answers buyers check first and the four that end deals when wrong. Named explicitly so the model does not guess.
- Exceptions by owner"grouped by owner, with question, reason, closest passage"
- Twenty questions sorted into three people's inboxes on day one is the critical path made visible.
What you get
Three rows from the exported draft, as the AE sees them with the provenance columns open, and one entry from the exceptions list. The sourced answers cite the page; the unsourced one says who needs to answer it.
Q 4.7 Does the solution support SAML 2.0 single sign-on?
ANSWER Yes. SAML 2.0 SSO is supported with Okta, Azure AD, and any SAML 2.0 identity provider. SCIM provisioning is included on the Enterprise plan.
SOURCE Library: 'SSO and provisioning' · security overview §3.2 · verified 2026-08-14 (Priya) · SOURCED
Q 4.12 Where is customer data stored, and can we select a region?
ANSWER Customer data is stored in AWS us-east-1 by default. EU customers can select eu-west-1 at contract time; data does not leave the selected region.
SOURCE Library: 'Data residency' · architecture doc §2 · verified 2026-05-02 (Sam) · STALE (128 days; re-verify before sending)
Q 6.3 Describe your process for notifying customers of a subprocessor change.
ANSWER NEEDS A HUMAN
REASON No library entry. The DPA (§9) commits to 30 days' notice but does not describe the process. Closest passage attached. Owner: legal.
---
EXCEPTIONS · Meridian Health · 20 items
SECURITY LEAD (9): 5.2 pen-test cadence (source says 'annual', buyer asks for the last report date) · 5.8 encryption key rotation period (no source) · ...
PRODUCT (7): 7.1 HL7/FHIR support (no source; roadmap doc mentions FHIR, not approved) · ...
LEGAL (4): 6.3 subprocessor notice process · 6.9 breach notification window (DPA says 72h; buyer asks for 24h; conflict, needs a position) · ...- canonical questionWhere is customer data stored, and can the customer choose a region?
- One entry per real question, phrased the way buyers ask it. The agent maps the buyer's wording onto this.
- approved answerAWS us-east-1 by default; EU customers select eu-west-1 at contract time; data stays in region
- The facts, in plain words. The agent adapts vocabulary per buyer and keeps every fact fixed.
- sourcearchitecture doc §2 (Regions and residency)
- The document and section the answer is true because of. A buyer who asks 'prove it' gets the page, not a shrug.
- ownerSam (infrastructure)
- A person, with a name. 'Engineering' never re-verifies an answer; Sam does, when the quarterly list arrives.
- verified2026-05-02 · window 90 days · now 128 days
- Past the window, so the agent drafts from it but marks the answer STALE. The AE re-verifies before sending, which is the whole point.
- statusapproved (proposed entries wait for an owner)
- The agent reads approved entries only. Proposed pages from the last RFP become sources when an owner signs them.
Pitfalls to avoid
Answering from general knowledgeA model with no source answers confidently from what it read about companies like yours. In a security questionnaire that is a deal-ending event. No source, no answer, a 'needs a human' flag.
A library with no verified datesAn approved answer with no date is the eighteen-month SSO problem waiting to recur. Every entry carries a source, an owner, and the day someone last confirmed it.
Ignoring the buyer's formA paragraph where the buyer asked for yes/no in 250 characters gets marked down before anyone reads it. Preserve the numbering, the form, and every limit.
Letting the agent approve its own answersProposed entries need an owner's approval and a verified date before they become sources. Otherwise you have built a faster way to be confidently wrong at scale.
Reusing a bank's answer for a hospitalAnswers written under one buyer's constraints get pasted into another's. Keep the library canonical and let the agent adapt vocabulary per buyer, with the facts fixed.
Skipping the quarterly re-verificationThirty minutes per owner per quarter is what keeps the library true. Every team skips it until a buyer's security team does the verification for them.
Questions people ask
- Can AI write RFP responses?
- It can draft them well when it is confined to your own approved sources and forced to cite them. Claude over an answer library and your security and product docs drafts the sourced answers in the buyer's form, marks anything past its verification window, and flags anything it cannot source for a person. Left to answer from general knowledge, any model produces confident, plausible, occasionally false answers, and in a security questionnaire one of those is enough.
- How is this different from the security questionnaire template?
- The template is the single-questionnaire play: a structured prompt, your docs pasted in, a human reviewing every answer. This is the system for a team that answers one a week: a maintained library with provenance and owners, sources read over MCP, an exceptions list by owner, export in the buyer's format, and the library growing with every response. Start with the template; build this when the third RFP of the quarter lands.
- What is provenance and why does it matter here?
- Provenance is the record of where an answer came from: the source document and section, and the date a named person last confirmed it was true. It matters because RFP answers fail on staleness and misattribution, and both are invisible without it. With provenance, a buyer who asks 'prove it' gets the page, and an AE can see that the data residency answer was last verified 128 days ago before sending it.
- Does it need Notion, or does a Drive folder work?
- Either. Notion gives you a database with the fields the library needs (source, owner, verified date, status) and an MCP server Claude reads directly. A Drive folder with a spreadsheet as the library works over the Drive connector. For a small team, a Claude Project with the library exported into it is enough to start.
- What happens to questions it cannot answer?
- They go on the exceptions list with a reason: no source, two sources that conflict, or a source past its verification window. The list is grouped by owner (security lead, product, legal) with the closest passage the agent found, so each owner gets their questions on day one. Those twenty questions are the AE's real work; the other 190 are a review.
- Will it send the response to the buyer?
- No. It reads sources and writes a draft, an exceptions list, and proposed library entries. A person reviews the draft, resolves the exceptions, and sends. It also never edits the library on its own; new answers wait for an owner's approval and a verified date.
- How long does it take to build?
- A day. A morning building the library from your last three RFPs and the security docs, an afternoon connecting the sources and writing the brief, then the first live RFP run alongside your best proposal person to compare. Coverage climbs with every response; expect around 60% sourced on the first and 85-90% by the fifth.
Related plays
- RFP Response Template Skill: Every Answer Cites Its Source →The drop-in skill version: answer library entries with provenance, one SKILL.md.
- Security Questionnaire Template →The single-questionnaire play this system grows out of.
- Mutual Action Plan Template →The late-stage twin: the plan that runs while the RFP is being answered.
- Claude + Notion integration guide →Reading the library and the source docs over MCP.
- Claude Projects →The app path: library and sources in a Project, the brief in its instructions.
- GTM MCP servers directory →What the Notion and Drive servers expose to Claude.
- Running Claude agents safely →Why the agent drafts from sources and never approves its own answers.