Draft RFP Response Answers from a Knowledge Base

Workflow area: Sales · Tier: Advanced · Hands-on time: ~45 minutes

RFP responses fail two ways: too slow, or too confident. The slow failure loses the deal to a faster bidder; the confident failure wins a deal your product cannot fulfil — an invented capability in an RFP answer can become a contractual commitment. Grounded drafting with citations attacks both problems at once, because NotebookLM answers only from the sources you give it and tells you when they don't cover the question.

When to use — and when not to

• Use it when you have real source materialpast RFP responses, product documentation, security and compliance docs, SLA sheets. The workflow's value is reuse; with no history, you are writing fresh answers and only need a chat tool for polish.
• Use it for the long tail of factual questionsdeployment options, data residency, support hours, integration lists. These are 70% of most RFPs and almost pure lookup.
• Skip it for the strategic questions"Why should we choose you?", pricing, executive summary. Those need the deal team's judgment; AI can polish the prose after humans decide the argument.
• Skip it if the RFP is under NDA terms that bar third-party toolscheck before uploading anything; some procurement processes explicitly prohibit sharing RFP content with external services.

The recipe

1. 1.

   Build the notebook. In NotebookLM, create a notebook named for the deal and upload: your two or three best past RFP responses, current product documentation, the security/compliance pack, and the SLA or support policy. Ten focused sources beat forty stale ones — an outdated capability doc will generate confidently outdated answers. Delete superseded versions before you start.

2. 2.

   Triage the RFP questions first. Paste the question list into Claude or ChatGPT with:

   Copy

   Classify each RFP question into exactly one bucket:
   A = factual/lookup (answerable from documentation)
   B = strategic (needs deal-team judgment: pricing, differentiation,
       executive summary)
   C = commitment (asks us to promise something: SLAs, roadmap dates,
       certifications)
   
   Return a table: question number | first 10 words | bucket.
   Do not answer any question yet.
   

   Bucket A goes through NotebookLM. Bucket B goes to humans. Bucket C goes through NotebookLM and gets named-owner sign-off, because those answers become obligations.

3. 3.

   Draft bucket-A answers in NotebookLM, one question at a time. Use this frame:

   Copy

   Answer this RFP question using only the sources in this notebook.
   
   Question: [PASTE EXACT QUESTION TEXT]
   
   Format: 2-5 sentences, direct answer first, then supporting detail.
   Cite the source for each factual claim. If the sources do not fully
   answer the question, answer the part they cover and state plainly:
   "GAP: sources do not cover [X]." Do not infer capabilities that are
   not explicitly documented.
   

   A good answer looks like this — direct, cited, honest about edges:

   Copy

   Yes. The platform supports SSO via SAML 2.0 and OIDC, including
   Azure AD and Okta [Security Pack, p.4]. SCIM provisioning is
   supported on Enterprise plans [Product Docs — Identity].
   GAP: sources do not cover LDAP — confirm with product team.
   

4. 4.

   Log every GAP into a tracker. Keep a sheet with Question # | Gap | Owner | Resolution. Gaps are the workflow's real output: each one is either a true product limitation (answer honestly, offer a workaround) or missing documentation (get the fact from the product team, then add it to the knowledge base for next time). Never let a gap get papered over with plausible prose.

5. 5.

   Transfer to the response document and verify citations. Paste answers into the RFP template in Google Docs. Then do the check that matters: for every cited claim in bucket-C answers and a 20% sample of bucket A, open the cited source and confirm it says what the answer claims. NotebookLM's citations make this a two-minute-per-answer job — do not skip it on the answers that create obligations.

6. 6.

   Run a consistency pass. Feed the assembled draft to Claude: "List any answers that contradict each other on numbers, timelines, or capability claims." RFPs assembled from multiple sources routinely say "99.9% uptime" in one answer and "99.95%" in another — procurement teams hunt for exactly these.

Make it yours

• Standing RFP notebook. Instead of per-deal notebooks, maintain one master notebook of approved answers, refreshed quarterly. Each completed RFP feeds its verified new answers back in — the compounding asset that makes RFP five twice as fast as RFP one.
• Security questionnaires. The same workflow handles SIG, CAIQ and vendor-risk questionnaires; the compliance pack becomes the dominant source and every answer is bucket C — full verification, no sampling.
• Claude for reformatting. Procurement portals often demand answers under word caps or in fixed formats. Paste the verified NotebookLM answer into Claude with "compress to under 50 words without dropping any factual claim" — verify nothing was cut that changes meaning.

Quality check

• Every factual claim carries a citation you spot-checked100% of commitment answers, sampled elsewhere.
• All GAP flags are resolved by a named humannone deleted, none smoothed into confident prose.
• No invented capabilitiesanything not in your documentation was confirmed with the product team before entering an answer.
• Numbers are consistent across all answersone uptime figure, one support window, one data-residency list.
• Bucket-C answers have owner sign-offthe person accountable for delivering the promise approved its wording.