A worked example: one RFP, from first read to recorded outcome

An illustrative pursuit walked through Paavya's seven steps, showing what each step asks, what Paavya does and what the team gets. Demo data, labeled as such.

5 min read

This is an illustrative example, not a customer story. The pursuit, the company, the people and every figure below come from Paavya's demo workspace, which is the same sample shown on the homepage. We publish worked examples to show how the product handles a real kind of bid. Customer case studies will be labeled as such, with the customer's permission and outcomes they have confirmed.

Case studies in this industry tend to arrive as a percentage and a logo. This is the opposite: one pursuit, every step, with the decisions and the evidence visible, so you can judge the method instead of a claim.

The pursuit is a federal RFP from the Cybersecurity and Infrastructure Security Agency (CISA) for continuous authority-to-operate (ATO) modernization. The bidder is a mid-sized services firm. The response is due in two days, which is exactly when a team is most tempted to skip the decision and start writing.

Step 1: Understand

What the step asks: what does this solicitation actually require, and what would stop us submitting?

Paavya reads the three source documents: the 84-page solicitation, Amendment 0001 (which moved the due date by three days) and the first round of the buyer's answers to questions. It extracts 42 requirements and shows how the response will be scored: technical approach 40 percent, past performance 30, key personnel 15 and price 15.

One requirement is flagged as blocking. Clause L.1.4 requires a bid bond at 10 percent of the total bid amount, and it is pass/fail: miss it and the bid is non-responsive, however good the rest is. Two others are open and weighted: a transition plan with cutover milestones (L.3.1) and a named project manager with ten or more years on comparable systems (M.2).

What the team gets: a brief with the buyer, the deadline and the pass/fail clauses, confirmed by a person before anyone moves on. Only the buyer and the response deadline are required to continue; everything else is advice.

Step 2: Decide

What the step asks: should we bid, and why?

Paavya reads the opportunity across four pillars:

PillarReadThe evidence
Buyer historyStrongTwo prior CISA task orders delivered on time
Past performanceStrongContinuous monitoring delivered for a like agency
CapacityWatchDue in two days with four requirements still open
Competitive signalsRiskThe incumbent holds the current ATO contract

The overall fit is 78 out of 100, shown with low confidence. Scribble, the assistant, recommends bid, naming past performance as the strongest reason and the bid-bond clause as the condition to close before the response is approved.

The decision is not Scribble's. The capture manager, Andre Reyes in the demo, records Bid, and his name and the time are kept with it. Had he chosen No bid, Paavya would have required a reason, and the record would count it as a decision.

Step 3: Plan

What the step asks: who owns each part, and by when?

The manager chooses Assign a team rather than Just me, and Paavya proposes an owner for every section, quoting the words it matched on:

SectionOwnerWhy
Technical approachMarcus IdeMatched on "systems engineer"
Key personnelAndre ReyesProposal manager
Management planPriya ShahMatched on "program management"
Transition and cutoverMarcus IdeMatched on "transition"

Where nobody matches, Paavya says so and gives the section to whoever is carrying least, instead of dressing a guess up as expertise. Due dates are counted back from the deadline with time held for review, the bid-bond condition from Understand is assigned to Andre, and a final approver is named.

What the team gets: every section owned, every owner told, and the approver known before a word is written.

Step 4: Draft

What the step asks: answer each requirement, in the company's own approved words where they exist.

Each writer opens Draft on their own sections, with the buyer's requirement shown above the answer box. Where the Library holds an approved answer from an earlier bid, Paavya offers it; the writer inserts it, tailors it to this agency, and marks the section ready for review. Paavya records which version of the Library answer was inserted, which matters at the last step.

Step 5: Validate

What the step asks: is everything we are about to send current, approved, supported and compliant?

The Library Card Scan checks each of the four Library answers in the response five ways: approved, current, evidence on file, agrees with the Library, and unchanged since approval. Validate also lists what must be fixed before approval:

  • Transition and cutover is empty. It goes to Marcus Ide, its owner, who finishes it.
  • The L.1.4 bid bond is not evidenced. It goes to Andre Reyes, who owns the bid condition, and he attaches the evidence.
  • An advisory: the Library holds two figures for headcount, 1,100 and 850. It does not block this bid, but the Library needs one answer.

With both required fixes cleared, the approver approves. The approval covers this version of the text; an edit afterwards would need approving again.

Step 6: Submit

What the step asks: is it really ready to go?

Four conditions must hold before the send button lights: the bid is recorded, every section is owned, the response is approved, and the delivery address is on the record. The response goes to the contracting officer, and everyone named on the pursuit is told it has gone. Another pursuit in the same list, a GSA schedule refresh, shows why the gate exists: it is still blocked on approval and a delivery address, and says so in those words.

Step 7: Outcome

What the step asks: what happened, how do we know, and what should we learn?

The team records the result as won, and how they know: the award notice posted on SAM.gov. Paavya does not turn this into a win rate. With two decided bids on record, it says a rate needs four and declines to print one it cannot stand behind.

It also notices that the transition approach was rewritten before it went out, and offers to propose the submitted wording as the new approved Library answer. The proposal goes to an approver, who decides. If approved, the next bid starts from the version that won.

What the example shows

  • The decision came first. On a two-day deadline, the team spent its first hour deciding, with the evidence in front of it.
  • Every recommendation could be checked. Each pillar named its evidence; the confidence level said how much to trust it.
  • Accountability stayed with people. Paavya proposed and drafted; people decided, approved and sent.
  • The outcome improved the next bid. The Library learned from what actually won.

To see the same pursuit play out step by step, open the walkthrough on the homepage, or bring one of your own RFPs to a demo.

See the decision this article is about.

Bring an RFP you’re weighing. We’ll run it through Paavya with you and show the evidence behind the recommendation.

30 minutes, on a solicitation you choose.