Why We Built Opportunities: Read Every RFP Attachment Before You Bid

The notice arrives as a link, not a document. You click through to SAM.gov and find eleven attachments: a provisions and clauses file, a statement of work, a second statement of work for the first task order, an experience form, a past performance questionnaire, a pricing spreadsheet, a labor category dictionary, a security checklist, an accessibility standard, and a Q&A record. One hundred and twelve pages. Not one of them is titled "here is what you have to submit."

Somewhere in that pile is the answer to the question you need before you commit a single hour of writing: is this worth bidding on, and if it is, what exactly are we on the hook for?

Our earlier guide, How to Respond to an RFP in Half the Time with AI, showed how to cut the writing in half. It assumed you already knew what the solicitation asked for. For federal work, that assumption breaks before you start. Closing that gap is exactly why we built Opportunities.

The RFP Is Not One File

Commercial RFPs usually arrive as a single document. Federal solicitations do not. They arrive as a package, and the package is deliberately modular: the clauses live in one file, the scope in another, the submission mechanics in a third, and the amendments rewrite pieces of all three without restating them.

That structure is fine for a contracting officer. It is punishing for a small team deciding whether to pursue. The only way to answer "what does this actually require" has been to open every attachment, read it end to end, and keep notes — three to five hours before anyone writes a word, repeated for every opportunity you consider and then discard.

Most teams solve this by skimming. They read the statement of work, scan the evaluation criteria, and decide. That works until the requirement they skipped is the one that disqualifies them.

What Hides Between the Attachments

The expensive problems in a federal package are rarely inside one document. They are in the spaces between documents, and skimming cannot find them.

Requirements with no submission path. In one package we analyzed, the accessibility attachment required an Accessibility Conformance Report plus three narrative descriptions. The submission instructions listed every file the offeror had to send, named and numbered. The accessibility report appeared in neither list. It was mandatory and homeless. A team that followed the submission table alone would have submitted a non-compliant proposal and never known why.

Contradictions across documents. The same package listed the subsections of one evaluation factor three different ways in three different files, and cited two different revisions of the same federal security standard. These are not trick questions. They are what happens when a package is amended twice by different people. But you cannot resolve a conflict you have not noticed, and the conflict is invisible unless you are holding both documents at once.

Page limits that are not where you look for them. Page limits do not live in one place. In that package they appeared in three separate attachments, and one 37-page clauses file alone imposed eight different limits on eight different pieces of the submission. The limit that matters to the person writing your technical volume is buried on page 23 of a file nobody opens twice.

One Upload, Two Documents

Opportunities takes the whole package at once. You upload every attachment, and about five minutes later you get two things.

The first is an analysis document. It answers what the solicitation asks for, how it will be evaluated, and how much it is worth, with the source attachment named for every claim. It lists the requirements that have no submission path. It lists the contradictions between documents, shows both versions side by side, and marks which ones the package itself has not resolved. It sequences the work, flags which decisions are irreversible once made, and names the external dependencies you do not control.

The second is a set of detail notes — one per attachment, in the order they were uploaded. Each note carries the quoted language that matters, what that document could not confirm on its own, and the metadata a proposal manager needs: whether it requires a submission, what page limits it sets, what format rules it imposes.

The analysis is what you read to decide. The notes are what you open when someone asks "where does it say that?"

What We Could Not Read, and Why We Say So

This is the part we argued about most, and the part we are most confident about.

Extraction is not perfect. Some PDF pages are scanned images with no text behind them. Some have font encoding damage that turns a date into garbage. A spreadsheet can be a template with every cell blank. If a tool quietly skips those pages, you get an analysis that reads as complete and is not — and you will never find out until the thing it missed costs you the bid.

So every note ends with an extraction section that says what went wrong, even when the answer is "nothing." In the package above, one attachment's first page was an image and produced no text at all. Another had control-character damage across five footers. Both are stated plainly in the output, with the damaged text shown rather than guessed at.

We would rather hand you an analysis with a known hole in it than a clean-looking one with an unknown hole. A requirement we flagged as unconfirmed costs you ten minutes on SAM.gov. A requirement we silently dropped costs you the proposal.

Where It Fits in Your Week

Opportunities runs before the work our other tools do. It is the triage step.

The practical change is in how many opportunities you can seriously consider. Reading a package properly used to cost most of a day, which meant you only did it for the ones you had already half-decided to pursue. At five minutes a package and a flat price regardless of how many attachments it holds, you can run every notice that looks remotely plausible and decide on evidence instead of on the first two pages.

Then, for the ones you pursue, you start writing with a requirements list, a conflict list, and a page-limit map already in hand — which is where our earlier guide picks up.