RFP responses — intake, AI draft, SME review

Forty questions, four experts, one deadline

A prospect sends an RFP and it’s the same drill every time. Dozens of questions, grouped by domain — how you handle data, what your contract terms are, how the product does the thing they need. None of it is hard to answer; it’s just that no single person knows all of it, and the deadline rarely leaves room to chase everyone down.

So a coordinator copies the questions into a doc, takes a first pass at the ones they can, and then starts pinging people: the security lead for the compliance section, legal for the terms, product for the capability questions. The answers trickle back in chat threads and half-finished comments, and stitching them into one clean response is its own job on top of the writing.

An RFP page with a form and a running list

The workspace gives you one page for RFPs: a short form to start a new response, and a table of every response you’ve worked on with its current stage. Each row carries the prospect, the stage — drafting, in review, ready — a link to its Google Doc, and a note from the polish pass once it’s done. So “what’s still drafting” and “what’s waiting on the experts” is a glance at the list, not a hunt through your sent messages.

Because the draft, the Doc link, and the review note all hang off the same record, an RFP never gets lost between the person who started it and the experts who finished it. You can open any response and see exactly where it stands.

From a new RFP to a Teams ping in five steps

1. Start a response from the form. Open the RFP page and fill in the prospect details. That creates the record and kicks off the draft in the background — no waiting on a blank page.
2. The draft gets written section by section. A background task works through the response, writing tailored content for each section against what it knows about the prospect and the questions being asked.
3. It lands in a Google Doc. The finished draft is saved as a Google Doc with its headings and sections already in place, so your experts edit in the tool they already use rather than a form they don’t.
4. A polish pass tidies it first. Before anyone sees it, a second pass reads the draft, fills any thin sections, and clears leftover placeholder text — then writes a short note of what it changed onto the record.
5. The right experts get pinged in Teams. When a response is ready for review, a message lands in your review channel with a link back to the workspace and the Doc, so the SME can jump straight to editing.

Intake fields, the polish rubric, and the review channel

• What the form collects — the details each new response starts from. Keep it to the prospect and the RFP, or add the fields your team needs before a draft is worth writing.
• The polish rubric — what the review pass checks for and fixes before an expert sees the draft: tone, section coverage, leftover placeholders. Tune it toward how your answers are supposed to read.
• The review channel — which Teams channel the ready-for-review ping lands in. Point it at the channel your SMEs watch for the domain in question — security, legal, product.
• The stages a response moves through — drafting, in review, ready. Rename or add stages to match how your team actually moves an RFP from intake to sent.

Every RFP starts as a draft, not a blank page

The value here isn’t a faster typist — it’s that the part everyone dreads, the blank first draft, is done before the work starts. The experts open a Doc that already has answers in it, and their job shrinks from “write the security section” to “check the security section.” The note from the polish pass and the Teams ping mean nobody has to remember whose turn it is.

The intake-draft-review loop stays the same RFP after RFP; what you’d shape for your own team is the fields the form collects, the rubric the polish pass applies, and the Teams channel your SMEs watch. The workspace description is what you change when those move — and the same loop runs whether you handle two RFPs a month or fifteen.