Picture a proposal kickoff two days after solicitation release. The capture lead walks through the win themes, someone shares a spreadsheet titled `Assignments_v3_FINAL`, and everyone agrees the schedule is aggressive but doable. The call ends with no decisions recorded and several action items with no dates.
At red team, several volumes are still bullet outlines. Nobody prepared the Section K representations and certifications response because it was never assigned. The past performance references came from a proposal for a different agency because the evidence owner was never named. The pricing team is waiting on a labor mix that the technical lead assumed pricing would build.
That failure did not happen at red team. It happened at kickoff, when the team started drafting before it had recorded requirements, owners, and a bid decision in one place. Proposal intake is the workflow between solicitation release and first draft that converts an RFP into five working artifacts: a numbered requirement register, an owner assignment map, an open question and risk log, a documented bid decision, and a compliance outline. If your intake does not end with all five, drafting starts on assumptions.
What Intake Actually Has to Produce
Intake and capture answer different questions, and conflating them is why kickoff meetings feel productive while producing nothing. Capture asks whether you can win: customer relationships, incumbent weaknesses, price-to-win, teaming gaps. That work should already be underway before the RFP drops, which is why capture management runs on its own pre-RFP cadence rather than inside the proposal schedule.
Intake asks two narrower questions. Can we respond compliantly with the people and evidence we have? And who specifically does what, by when?
The output is not a meeting summary. It is five artifacts with a definition of done, each of which someone downstream consumes.
| Artifact | Source documents | Owner | Definition of done | Consumed by |
|---|---|---|---|---|
| Requirement register | Sections L, M, C/PWS, H, I, K, attachments, CDRLs | Proposal manager | Every shall/must/will statement numbered, cited to page and paragraph, tagged instruction vs. evaluation vs. technical | Writers, compliance reviewer, red team |
| Owner assignment map | Requirement register | Proposal manager | One content owner per row, with an evidence owner and approver named where applicable. No unowned rows | Volume leads, teammates, subcontractor data calls |
| Open question and risk log | Register gaps, ambiguous language | Proposal manager plus contracts | Every question has an owner, a submission deadline, and a written fallback assumption | Contracts (CO questions), writers (fallbacks) |
| Bid decision record | Capture inputs plus intake findings | Capture lead and approving executive | Signed decision with rationale, price-to-win position, named gaps accepted, and the conditions that would trigger a no-bid | Executive review, debrief preparation, decision archive |
| Compliance outline shell | Section L crosswalk | Proposal manager | Outline headings mirror Section L order, each heading mapped to register IDs and Section M factors | Writers, desktop publishing, final compliance check |
Intake ends with a gate, not a handoff email. The gate is a short standing review where the proposal manager walks the register and states the number of unowned requirements, the questions past their decision deadline, and the recommendation to proceed or stop. If the answer to "how many rows have no owner" is anything other than zero, drafting does not start.
That distinction matters because handoff emails create the illusion of transfer. A gate creates a record.
Shredding the Solicitation Without Losing Requirements
Shred in a fixed order, because reading order changes what you notice. Under the uniform contract format described in FAR 15.204, the pieces you need are scattered across parts of the document that were written by different people at different times [1].
The order that works:
- Section L first (Instructions, Conditions, and Notices to Offerors). This defines the response architecture: volumes, page limits, font and margin rules, file naming, submission portal, due date and time zone. Build your outline shell from Section L before you read anything else, because Section L determines where every other requirement gets answered. Note that FAR 52.215-1 governs late submissions, so submission mechanics are a compliance requirement, not an administrative detail [2].
- Section M second (Evaluation Factors for Award). Section M tells you what gets scored and in what relative order. Map each Section M factor and subfactor to the Section L instruction that produces the response. Any Section M factor with no corresponding Section L instruction is an immediate question for the contracting officer.
- Section C or the PWS/SOW third. This is the work itself. Shred each task and subtask as its own row. Resist the urge to summarize.
- Sections H, I, and K fourth. Read Special Contract Requirements, Contract Clauses, and Representations and Certifications with one question in front of you: does anything here create content someone has to write or evidence someone has to produce? Turn each candidate into a question for contracts rather than an assumption. Does this solicitation call for key personnel commitment letters? An organizational conflict of interest mitigation plan? Insurance documentation? Personnel or facility access paperwork? A small business subcontracting plan? Log each answer against a register row with a named owner.
- Attachments, exhibits, and CDRLs last. When the solicitation includes data items on DD Form 1423, review each one for response, format, and pricing inputs that belong in the register. DFARS 215.470 addresses the form's use when contract data must be delivered [3].
Requirement numbering rules
One obligation per row. If a sentence contains two shall statements, it becomes two rows. Merging them is how requirements disappear, because a writer answers the first half and marks the row complete.
Every row carries a document, page, and paragraph citation. When an evaluator or your own compliance reviewer asks where a requirement came from, the answer should take five seconds, not five minutes of Ctrl+F.
Tag each row by type, because instruction requirements, evaluation criteria, and technical requirements need different owners. A page limit is owned by desktop publishing. An evaluation subfactor is owned by the volume lead who has to score well against it. A PWS task is owned by the technical SME who does that work. Assigning all three to "Technical Lead" is how the format compliance failures happen.
This extraction is the part where compliance matrix automation earns its keep. Pulling every shall, must, will, and shall-provide statement out of a two-hundred-page solicitation and building the Section L to outline crosswalk is mechanical, high-volume, and error-prone when done by hand at 11pm. What automation does not do is judge scope. A human still has to confirm that the attachments were included in the source set, that amendments were re-run, and that a requirement written as "the Offeror is encouraged to" got flagged rather than dropped.
Requirements hide outside Section L
Requirements also hide in attachments, amendments, and Q&A responses. Under FAR 15.206, the government amends the solicitation when it changes requirements before award, and those amendments can add or delete response content after your outline is locked [4]. Assign one named person to re-shred every amendment and every published Q&A answer against the register as a scheduled task with a due date, and to log which register rows changed. Treating this as a named task keeps the working outline aligned with the current solicitation.
One Owner Per Requirement, No Exceptions
Shared ownership is no ownership. When a requirement row lists "Technical Lead / Solutions Architect," each of them assumes the other has it, and neither raises it at pink team. The rule is one name per role per row, and "TBD" is a tracked exception with a due date, not a placeholder you leave in the file.
There are four distinct roles, and conflating them creates avoidable gaps during intake:
- Content owner writes the response text. This is the person whose calendar has to have hours blocked.
- Evidence owner supplies the proof the response depends on. Make the row name the artifact: which past performance record, which resume, which process document, which reference contact, which registration or attestation record. If nobody can name the specific artifact, the row is not ready to draft, and that is an intake finding rather than a writing problem.
- Approver confirms the claim. Before drafting starts, decide who has authority to confirm each factual statement the response will make about your organization, and put that name in the row. Where the answer is unclear, log it as a question with a due date instead of letting a writer decide.
- Compliance owner verifies that the drafted response actually satisfies the requirement as written, not as the writer remembered it. This is a separate read, done against the register, not a proofread.
Matching roles to requirement types
Format and submission requirements go to proposal operations or desktop publishing as content owner, with the proposal manager as compliance owner. Nobody needs an approver for a margin setting.
Technical and PWS requirements go to the SME as content owner, with a solution architect or capture lead as approver when the response commits to an approach, a tool, or a staffing level that affects price.
Past performance requirements are the clearest case for splitting roles: a writer produces the narrative, a contracts or program person owns the evidence (contract number, period of performance, evaluation record, POC contact currency), and the program manager approves that the described work matches what was actually delivered.
Corporate and terms requirements (Section H and I obligations, Section K representations and certifications, and subcontracting plans) go to contracts as content owner with an executive approver. These rows are easy to overlook until the compliance check, so assign them during intake.
The small-team reality
On a five-person shop, one person holds three roles on most rows. That is fine. What is not fine is deleting the role columns because they are redundant. Keep the record honest by writing the same name in all three fields, because the roles have different deadlines even when the person is the same. The evidence owner deadline is earlier than the content owner deadline, which is earlier than the approver deadline, and collapsing them into one date is how the approval becomes a rubber stamp at 4am.
Teammate and subcontractor rows
Requirements owned outside your company need three extra fields: the partner organization, the internal escalation owner who chases them, and a hard data call deadline set well before your internal draft deadline. Plan time to review and clarify the first response rather than discovering a gap during the compliance review, and keep partner-supplied content in the same reusable content library so the next pursuit does not start the data call from scratch.
The Open Question Log That Prevents Guesswork
There are two kinds of open questions during intake, and teams only track one of them. The tracked kind goes to the contracting officer. The untracked kind is a decision the team owes itself, and it does more damage because nobody has a deadline for it.
Follow the Q&A instructions and deadline in the solicitation. After release, FAR 15.201 makes the contracting officer the focal point for exchanges with potential offerors [5]. Build the log for the possibility that the agency may not answer every question before your internal drafting deadline.
Every question row should carry: the question text as you will submit it, the register requirement ID it affects, the internal owner, the submission deadline, the government response when it arrives, and the fallback assumption you will draft against if no answer comes. The fallback field is the one that matters. It is written before the Q&A window closes, and it converts a blocked section into a section that can be drafted with a known risk.
Internal questions use the same structure with a different owner. Do we bid the incumbent's staffing level or our own? Do we propose the tool the program office already runs or the one our team knows best? Does the pricing team assume CONUS travel? Each one gets an owner, a due date, and a decision recorded in the log. A decision that exists only in a Slack thread does not exist.
Writing assumptions without creating an exception
Here is where teams create unnecessary risk. A writer resolves an ambiguity by adding "Assuming the Government provides workspace at the primary site" to the technical volume. An evaluator may read that as a condition on the offer rather than an implementation detail.
Route the ambiguity through contracts review, and align the technical and pricing teams on one documented treatment. When the approach can support either configuration, say so clearly: "Our staffing model supports both government-furnished and contractor-provided workspace, with the transition plan in Section 3.4 addressing either configuration." The register row records the open issue internally so pricing and the approver see it, while the proposal gives the evaluator a clear approach.
Why the log survives past submission
After award, the log remains useful. During a debriefing under FAR 15.506, it helps the team reconstruct which requirements it interpreted differently and prepare questions that are more specific than "why did we lose" [6]. If a protest question arises, preserve the log with the solicitation record and work with counsel; GAO maintains the governing rules and reference materials for its bid protest process [7].
During performance, the same log explains why your approach looks the way it does. When a program office asks why the transition plan assumed an overlap period, the answer is a dated question, a dated government response, and a named owner.
Frequently Asked Questions
How long should proposal intake take?
Work backward from your first draft deadline and treat intake as the first scheduled task, not a warm-up. The constraint is rarely the shred, which automation handles quickly. It is getting owners named and the bid decision signed before writers burn calendar time on the wrong sections.
Is a compliance matrix the same thing as a requirement register?
Nearly. A compliance matrix is the register in its review-facing form: requirement, response location, owner, status. The register is the working artifact during intake, and it carries fields the final matrix does not need, such as source citations and fallback assumptions. Teams that build the register in compliance matrix software rather than a spreadsheet keep the source citation attached as the register becomes the review-facing matrix.
What if the bid decision is not final when drafting has to start?
Then record the conditional decision with named trip wires: the price-to-win threshold, the teaming commitment, or the Q&A answer that would flip you to no-bid. A conditional bid with written trip wires is defensible. An unrecorded assumption that leadership will approve is not.
Who should own intake, the capture manager or the proposal manager?
The proposal manager owns the artifacts. The capture manager owns the bid decision inputs. Splitting it this way keeps the person with schedule authority accountable for owner assignment.
What should we watch for when using AI-assisted shredding?
Start with source coverage. Automated extraction can surface shall statements from the documents you provide, but it cannot know that Attachment J-7 was posted separately or that Amendment 0002 changed the page limit. Keep a human accountable for confirming the source set, reviewing the extracted rows, and re-running the process after every amendment.
Start Here Before Your Next Solicitation Drops
Do one thing this week: open your last submitted proposal's compliance matrix and count the rows that had no named owner at kickoff. Then count how many of those rows produced a red team finding. That correlation is the argument for changing your intake process, and it is more persuasive to leadership than any process diagram.
Then set up the five artifacts as templates before the next RFP hits, not after. Requirement register with source citation and type fields. Owner map with four role columns. Question log with a mandatory fallback field. Bid decision record with a trip wire section. Compliance outline with each heading mapped to register IDs and evaluation factors.
The metric to track from now on: unowned requirement count at the intake gate. Report it at every kickoff before drafting starts. Zero means go. Anything else means the kickoff is not finished and review gaps are already forming.
References
- [1]General Services Administration, "FAR 15.204 Contract format," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/far/15.204
- [2]General Services Administration, "FAR 52.215-1 Instructions to Offerors: Competitive Acquisition," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/far/52.215-1
- [3]Department of Defense, "DFARS 215.470 Estimated data prices," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/dfars/215.470-estimated-data-prices
- [4]General Services Administration, "FAR 15.206 Amending the solicitation," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/far/15.206
- [5]General Services Administration, "FAR 15.201 Exchanges with industry before receipt of proposals," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/far/15.201
- [6]General Services Administration, "FAR 15.506 Postaward debriefing of offerors," Acquisition.gov, accessed September 7, 2026. https://www.acquisition.gov/far/15.506
- [7]U.S. Government Accountability Office, "Bid Protests at GAO: A Descriptive Guide," GAO-18-510SP, May 2018. https://www.gao.gov/products/gao-18-510sp