RFP Response Assistant

Inside this Project, Claude carries the library that makes each response faster:

• The approved answer library — answers that have cleared review, with the question they answer and the date they were approved.
• Which answers have cleared review and which have not, so an unvetted draft is never silently reused as though it were approved.
• Escalation history — which questions have needed a named expert before, and who that expert was.
• The reasons behind past escalations, so recurring gaps in the source material become visible.

Run one Project per organisation, not per RFP. The library is the asset; a per-deal Project throws it away each time.

Reach for this Project when:

• You have received an RFP, RFI, or security questionnaire and need a first pass fast.
• You want to know which questions you can answer from approved material and which need an expert.
• You are building a reusable answer library rather than rewriting each time.
• You need an auditable record of which answers were reviewed and by whom.

Use something else when:

• You are building competitive positioning rather than answering formal questions — that is Competitive Battlecard Builder.
• You are running the technical evaluation itself — that is Active POV Deal Room.

Per response, you provide:

• The RFP questions, pasted or attached, ideally with their original numbering.
• Deal context — who the buyer is, what they are trying to achieve, and the submission deadline.
• Any question-specific material the buyer supplied, such as a scoring rubric or mandatory requirements.

Where the RFP includes a weighting or scoring scheme, provide it. Effort should follow points.

Upload these when you create the Project. This is the Project where source quality matters most, because an unsupported answer can become a contractual commitment.

If the security documentation is not current, say so before you start. Stale security answers are the highest-consequence error this Project can make.

Claude accepts files up to 30MB each, and there is no fixed limit on how many you add, but everything in a Project's knowledge has to fit the context window. Fewer, sharper files beat a full archive.

Prepare files this way:

• Strip cover pages, legal boilerplate, and navigation chrome — they consume context and carry no signal.
• Prefer text formats. A clean export beats a scanned PDF.
• Name each file for what it contains, not when you exported it. Claude reads filenames.
• One subject per file. A merged reference document is harder to cite precisely.
• Date anything that goes stale, inside the file itself, so Claude can tell you when it is working from old material.

1. Create one Project for your organisation. Name it RFP Responses and keep it across deals — the answer library is the point.
2. Paste the Project Instructions.
3. Replace the three bracketed fields. The security review contact matters most: escalation needs a name, not a department.
4. Upload the knowledge files. Approved capability descriptions and security documentation first; those two govern what can be answered at all.
5. Run your first RFP through classification only before drafting. The classification pass tells you how much of the response you can actually cover, which is what you need before you commit to a deadline.
6. After submission, add the approved answers to the library and note who signed off on the escalated ones.

The bracketed fields below are placeholders you replace with your own details before you save the instructions. Leaving them unfilled produces generic output — that is the single most common reason a Project underperforms in its first week.

This Project has three, all new — the original had none:

• [FILL IN: Company Name] — your employer.
• [FILL IN: Your Approved Capability Source] — which document is authoritative for what your product does. When two documents disagree, this is the one that wins.
• [FILL IN: Your Security Review Contact] — the named person or role who signs off security, compliance, and certification answers. Escalation without a named owner does not happen.

Role

You are an RFP response specialist for [FILL IN: Company Name]. You classify incoming questions, draft the ones that approved material supports, and escalate the rest. You are trusted because you refuse to fill gaps.

Most important rule

Never assert a capability, certification, or compliance status that is not present in the approved knowledge files. Where it is absent, flag [NEEDS VERIFICATION] and escalate. An RFP answer can become a contractual commitment.

Escalation labels

• Answered from approved material — fully supported, with the source cited.
• [NEEDS VERIFICATION] — partially supported, or the source may be stale.
• Escalated — expert required — not supported at all, or touching security, compliance, legal, or pricing.

The full instructions continue with the classification rubric, the answer library structure with per-answer review status, the five commands, output formats, and the escalation workflow.

This Project produces four deliverables:

• Classification — every question sorted by whether it can be answered from approved material, needs verification, or must be escalated.
• Drafted answers — for answerable questions, in the required format and length, each citing its source.
• Escalation list — questions requiring a named expert, with the reason and the specific thing that person needs to confirm.
• Assembled response — the full document once escalations return, with review status per answer.

Three answered questions from a fictional public-sector RFP.

Q14. Describe your platform's role-based access control.

Status: answered from approved material. [Source: security documentation v4.2, dated June 2026.]

The platform provides role-based access control with organisation-defined roles. Administrators can create custom roles and assign granular permissions across data access, configuration, and user management. Permissions are enforced at the API layer as well as in the interface. Role assignments and permission changes are recorded in the audit log with actor, timestamp, and previous value.

Q15. Confirm your platform holds FedRAMP Moderate authorisation.

Status: [NEEDS VERIFICATION] — escalated.

Our security documentation lists SOC 2 Type II and ISO 27001. It does not mention FedRAMP at any level. This may mean we do not hold it, or that the documentation is incomplete. I have not answered this question, because a wrong certification claim in a public-sector RFP is a compliance exposure rather than a drafting error.

Escalated to: [security review contact]. Needed: current FedRAMP status, and if in progress, the stage and expected date. Deadline: 48 hours before submission.

Q16. Describe your disaster recovery RTO and RPO commitments.

Status: partial — drafted with a flagged gap. [Source: security documentation v4.2, section 9.]

Documented recovery point objective is four hours, with daily backups retained for 35 days and cross-region replication. [NEEDS VERIFICATION: the documentation does not state a recovery time objective. RTO is explicitly asked for here and the answer is incomplete without it.]

Escalated to: [security review contact]. Needed: the current contractual RTO, and whether it varies by tier.

Classification summary for this section: 1 answerable from approved material, 1 partial, 1 escalated. Two of three require security sign-off before submission.