Ben Willett Get in touch

Deployed · Internal application

RFP Response Platform

Answering one RFP meant days of reading, drafting and chasing sign-off — 35–40 hours in my own workflow before this. The system does the reading and the drafting; people keep all five decisions.

Business impact

  1. 5–10 hours

    Per RFP today

    Down from 35–40 hours, my estimate of my own prior workflow.

  2. 58%

    RFP win rate

    14 of 24 in 2026, up from 3% (1 of 33) in 2025.

  3. $1.8M

    Net new revenue

    Across all 14 wins, April to 1 November 2026.

  4. $20K/year

    Software saving

    Annual legacy software expense eliminated.

Sales outcomes the workflow supported, across both the plugin and the deployed app. Hours per RFP are my own estimate, not an audited time study.

Watch the walkthrough Project details Explore the architecture Engineering decisions

One clause, start to finish

A buyer’s template arrives with a liability cap in it. That is the kind of question the system is built not to answer by itself, and following one through is the shortest way to see what the five checkpoints are for.

  1. It flags the clause rather than drafting it. Answers are assembled only from approved answer-library rows. Indemnity and liability wording has no row a writer may reuse, so the pipeline marks it as needing an owner instead of producing text a model composed.
  2. It drafts the question and assigns it to Legal. One message, with the clause and the context around it. The system never sends the email — the writer sends it from their own client, and Legal’s reply is recorded against the question with their name on it.
  3. The proposal waits. Nothing downstream can mark that answer ready, and the chat assistant will not do it either: asked to approve the batch, it declines and says the approval is a person’s click. When Legal does sign off, the system stores a fingerprint of the exact wording reviewed — so if the text is edited afterwards, the approval is marked out of date rather than quietly carried over to words Legal never read.

The walkthrough below is a recording of the real workflow, at the stage it ran as a Claude Code plugin.

Watch it run

Play the walkthrough2:24 · no sound
2:24 · no sound · captions on screen

Project details

My role

I wrote the module: the Python pipeline on AWS Lambda and DynamoDB, retrieval and drafting against Claude on Amazon Bedrock, the Vue and TypeScript interface, the five human checkpoints, and the Claude Code plugin it started as. I handed that code to our Director of Innovation, who owns the internal application's shared framework; he reviewed it and ran the deployment.

The module is mine and the framework it runs inside is not: the Director of Innovation built and maintains that, and reviewing and deploying my code was his. The answer library the pipeline retrieves from is one I had already assembled. The employer is a Human Capital Management B2B SaaS company; it and my colleagues are not named here.

Project status

Built as a Claude Code plugin May–June 2026 and used on live proposals from June; the pipeline was deployed into the internal application in October 2026. Of the 24 proposals in the April to 1 November 2026 window, 20 ran on the plugin and 4 on the deployed app.

Validation and scope

  • It never sends email. It drafts one message per expert; the writer sends it from their own client.
  • It never submits to a buyer, and it does not assemble the final proposal document.
  • The spreadsheet answer library is still the master copy. The app reads it and suggests updates back.
  • No job and no assistant can make a checkpoint decision. All five are a person's click.
  • Processing time in the video is compressed and marked "Sped up". A real analysis takes minutes.

Built with

  • Vue
  • TypeScript
  • Python
  • AWS Lambda
  • DynamoDB
  • Claude on Amazon Bedrock
  • Claude Code plugin
How the results were measured

Our team now spends 5–10 hours on an RFP. Before this, my own workflow took 35–40 — that figure is my estimate, from comparing how I worked before and after, not an audited time study. As an outside point of reference and nothing more, Loopio reports an industry average of 33 hours per RFP, and 36 for dedicated proposal teams; it is not evidence about this team.

The company's RFP win rate was 58% in 2026 — fourteen wins in twenty-four proposals — against 3% in 2025, one win in thirty-three. These are different reporting periods rather than a controlled comparison, the 2026 sample is the smaller of the two, and the go/no-go workflow changed which opportunities were pursued. The comparison does not isolate the effect of the software.

Those proposals produced $1.8M in net new revenue between April and 1 November 2026, across all fourteen wins. Twenty of the twenty-four proposals were produced with the Claude Code plugin and four with the deployed application, so the figures cover both versions rather than either one alone.

Replacing the legacy tool eliminated $20,000 in annual software expense. A full run costs $10–20 all in: storage, hosting, API calls and model tokens.

What I'd do next
  • Run the retrieval and drafting evaluations against the deployed model rather than the local mock, so quality is measured where it actually runs.
  • Move the answer library off the spreadsheet that is still its master copy — the last manual step in the loop.
  • Widen the permissions model. RFP pages are admin-only in the code I wrote; which roles hold them in the deployed app is the Director of Innovation's call, not mine.
  • Instrument the go/no-go decision, so the selection effect in the win-rate numbers can be measured rather than estimated.

How the workflow runs

A writer drops in the package and analysis runs in the background. It stops at a go/no-go a person makes under their own name; drafting starts only after that, from approved library rows and cited to them. The four remaining checkpoints are the same shape — the writer approves answers, experts answer by email and are credited, Legal signs off on the exact wording it reviewed — and only then is the proposal ready to assemble. The chat assistant can do any of the work and none of the deciding.

Architecture

Background jobs over a document store, retrieval against the approved library, a permissions layer on each checkpoint. Below, one proposal goes through all thirteen steps — five of them stop and wait for a person. Select any component for what it does and why.

  1. 01 Start

    An RFP package arrives

    Someone drops the RFP package (PDFs, Word files, Excel questionnaires) onto the RFP home page. The app creates the RFP record, and the browser uploads each file straight to storage through a short-lived signed link, so large files never pass through the API.

    • Also. Past RFPs can be backfilled from my earlier plugin's history, so dashboards and results start complete.

  2. 02 Automatic

    The analysis starts in the background

    An analysis takes minutes, but the API must answer within 30 seconds, so the run is handed to a background worker and the page follows its progress. Only one job runs per RFP: a lock taken with a conditional write stops a double start, and expires on its own if a job dies.

  3. 03 Automatic

    Every document is read

    The document reader pulls text from PDF, Word, Excel and CSV files. Excel questionnaires are read by their header row, so each question keeps its place in the issuer's sheet. Extracted text is cached beside the file, so a re-run skips what's already been read.

    • If a file can't be read. Scanned PDFs without a text layer are flagged on the RFP instead of being silently skipped.

  4. 04 Automatic · AI

    Claude builds the go/no-go picture

    Claude reads the package and returns a pursuit scorecard with a recommendation, a compliance matrix of every requirement, and the list of questions to answer. Rules written by admins on the AI Instructions page are added to the prompt. The results are saved to the RFP.

  5. 05 Human checkpoint 1

    Checkpoint 1: a person decides

    The run stops. A person reads the scorecard and compliance matrix and records Pursue, Pursue with conditions, or Decline. The AI's recommendation is advice only: no job and no assistant action can record this decision.

    • Decline. The RFP is closed with its reason, and nothing is drafted.
    • Submission portal. If the questions sit behind a portal, a person uploads them before drafting can start.
    • Pursue. Resume carries the pipeline on to drafting.

  6. 06 Automatic · AI

    Answers are drafted from the library

    For each question, library search offers Claude the 20 best-matching approved answers. Claude drafts from only those rows, cites them, and marks each answer Verified, Adapted, or Needs an expert. Code then enforces the rules whatever the model said: citations must be rows that were offered, a row with an open conflict blocks the answer, and legal wording stays word for word.

    • Library changes mid-run. A run keeps the library version it started with, even if someone uploads a new one meanwhile.

  7. 07 Human checkpoint 2

    Checkpoint 2: review drafts, reach out to experts

    Reviewers read, edit and approve each draft. Questions the library couldn't answer are grouped by expert into ready-to-send outreach emails. The app drafts them; people send them from their own email.

  8. 08 Human checkpoint 3

    Checkpoint 3: expert answers come back

    An expert's answer is recorded on its question and appears for everyone on the RFP within seconds. The writer approves it, or leaves the question open on purpose with a reason. Every approved answer is offered to the library as a suggestion.

    • Loop. Review and expert answers repeat until every question is approved or deliberately left open.
    • Not built yet. A workspace where experts answer directly in the app.

  9. 09 Human checkpoint 4

    Checkpoint 4: Legal signs off

    Answers with legal or AI wording, contract terms we don't fully comply with, and go/no-go red flags are gathered on one page and sent to Legal. Legal signs off or asks for changes. The sign-off records exactly what Legal saw, so changing any of it afterwards makes it out of date.

    • Changes requested. The writer edits and sends it again, and Legal reviews the new version.
    • Permission. Only people with the Legal sign-off permission can sign off.

  10. 10 Human checkpoint 5

    Checkpoint 5: ready to assemble

    A person marks the RFP ready. The app allows it only when every question is resolved and Legal's sign-off is still current, and the same rule applies whether the stage is changed in the workspace, on the board or through the assistant.

  11. 11 Output

    Export and assemble

    The team downloads styled Excel workbooks: the compliance matrix with the pursuit scorecard, and every answer with its status and sources. In this version the final response document is assembled outside the app and submitted by a person. The app never submits anything.

  12. 12 Loop

    The library learns

    Approved answers, expert answers, open gaps and stale rows become suggested library changes. The library owner approves them (Legal too, for legal wording), and search and drafting use approved changes at once. They're exported as a change file that my earlier plugin's script applies to the Excel master, which comes back as the next library version.

  13. 13 Alongside

    Anytime: ask the assistant

    On any RFP page, people can ask Claude about the pipeline, an RFP, its documents or the library, and answers come from the app's own data. The assistant can also propose an action, like starting a run or assigning questions, as a card that does nothing until the person clicks Confirm. It has no way to make checkpoint decisions, send, submit or delete.

Architecture diagram of the RFP response platform: intake feeding a background analysis worker, a drafting engine reading from an approved answer library, five human checkpoint gates, an export step, a chat assistant connected through a confirmation layer, and the test and deployment tooling around it.

Engineering decisions

Pick one to read it. The constraint, the implementation and the cost are behind each.

Choose an engineering decision to read

A background worker, not a synchronous request

Reading a package takes minutes and the gateway gives up at thirty seconds, so analysis runs as a durable background job the page polls. A closed laptop does not kill a run.

The constraint, what I built, and what it cost
The constraint
Reading a full RFP package takes minutes, and the API gateway gives up after thirty seconds.
What I implemented
Analysis runs as a background job the page polls. Every piece of state is durable and resumable rather than living inside a single request, so a closed laptop does not kill a run.
What it cost
More moving parts to keep consistent. Worth it, because the alternative caps the product at whatever fits in thirty seconds.

Instead ofcalling the model inside the web request and showing a spinner.

Drafting can only use rows the retrieval step actually returned

Every answer is assembled from approved library rows, and my code checks the citations after the model replies rather than asking for them in the prompt. A question the library does not cover goes to an expert instead of being answered.

The constraint, what I built, and what it cost
The constraint
Text going to a customer under contract cannot contain an answer nobody approved.
What I implemented
Every answer is assembled from approved answer-library rows, and the rules are enforced in code after the model replies rather than requested in the prompt: a citation that is not a row that was offered is rejected, a row flagged as conflicting blocks the answer outright, and legal wording is copied verbatim rather than paraphrased.
What it cost
The system refuses more often — a question with no library coverage goes to an expert instead of being answered. Server-side checks enforce the citation and approval rules after generation, so the refusal is not something the prompt can be talked out of.

Instead ofletting the model answer from its own knowledge and asking it to cite sources.

A run pins the answer-library version it started with

A run holds the library version it began with, so what a reviewer approves is what they saw. A mid-run update is picked up by the next one.

The constraint, what I built, and what it cost
The constraint
Someone uploading a library update mid-run would change answers underneath a reviewer who had already read them.
What I implemented
A run holds the version it began with, so what a reviewer approves is what they saw. New content is picked up by the next run.
What it cost
A long run can be working from yesterday's library. That is the price of an approval that means something.

Instead ofalways reading the current library.

Legal sign-off records a fingerprint of exactly what Legal saw

Sign-off is stored as a hash of the reviewed content, so an edit afterwards marks the approval out of date rather than silently carrying it over to text Legal never read.

The constraint, what I built, and what it cost
The constraint
An approval has to cover a specific document, not a document's name.
What I implemented
Sign-off is stored as a hash of the reviewed content. If anything changes afterwards, the system can tell that the approval no longer covers what is on the page, and marks it out of date.
What it cost
An edit after sign-off sends the question back to Legal. A boolean flag cannot tell the difference between "approved" and "approved something else".

Instead ofa boolean "approved" flag with a timestamp.

The assistant proposes; a person confirms

The assistant drafts, assigns, searches and explains, and every action arrives as a card a person clicks. It has no path to any of the five checkpoint decisions — this was the first constraint I set.

The constraint, what I built, and what it cost
The constraint
Five decisions in this workflow carry someone's name, and none of them can be delegated to a model.
What I implemented
The chat assistant can draft, assign, search and explain, and every action it takes arrives as a confirm card that a person clicks. It has no path at all to a checkpoint decision, an email, a submission or a deletion — asked to approve a batch of answers, it declines and explains that the approval is a person's click.
What it cost
More clicks than an agent that simply acts. This was the first constraint I set and the one I would defend hardest: the value is in removing the reading and the drafting, not the accountability.

Instead ofan agent that completes checkpoint tasks on request.