# A searchable RFP answer library your bid team drafts from

> Every proposal you have ever submitted in one searchable archive, with the closest past answers lined up against each question in a new RFP.

- Workflow type: app
- Services: General Input Storage, General Input Database, Mistral AI, Google Docs, HubSpot
- Categories: Sales, Operations
- Published: 2026-08-31

## What it does

- Keeps every past proposal and security questionnaire you have submitted in one searchable archive, with the client, the date, the sector and whether you won or lost on every row.
- Upload a new RFP and the app breaks it into individual questions, showing the two or three closest answers your team has used before next to each one, with the proposal they came from and how that bid ended.
- Flags any answer sourced from a proposal more than twelve months old as stale, so it gets reviewed rather than pasted straight in.
- A Draft this response button hands the whole RFP to an assistant that reads it, matches every question to your answer bank, writes a tailored response and files the assembled draft as a Google Doc linked back on the row.

## What you'll need

- Your past proposals and completed questionnaires as PDF or Word files, ready to upload
- A HubSpot login, so the app can pull the sector and deal size behind each RFP
- A Google account for filing the finished drafts as Google Docs
- A Mistral AI account, used to read the text out of uploaded documents including scanned ones
- Nothing to set up for the archive itself: the file store and the answer bank are provided by General Input

## Prompt

Build me a proposal answer library that my bid team works out of every time an RFP lands, so nobody rewrites an answer we already have. It is an internal app for bid managers, proposal writers and the sales leads who sign off on their work. The whole point is that every answer we put in front of a client is traceable back to a real proposal we submitted, with the outcome of that bid visible next to it.

The main screen is a searchable archive of every past proposal and questionnaire we have submitted. The documents themselves live as files in General Input Storage, and the archive pages through them with the List Objects operation under a proposals prefix. Each row shows the client name, the submission date, the sector and whether we won or lost, with a coloured outcome tag. Give me full text search across client and sector, filters for outcome and date range, and sorting by date. Every row has a preview or download action that mints a fresh link with the Presign Download operation at the moment of the click, because those links are short lived and must never be stored or reused. Keep an archive detail view where I can open one proposal, see its metadata, read the questions and answers extracted from it, and correct the client, sector or outcome if it was filed wrong.

Uploading a new RFP happens straight from the browser. The app asks for a link with the Presign Upload operation and the browser PUTs the file directly to that link, so a large PDF or DOCX never passes through a handler. The same upload path is used to seed the archive with past proposals, and there is a delete action on the archive detail view that uses the Delete Object operation and removes the matching rows. On upload the person tells me the client, the sector and, for a past proposal, the outcome and the submission date.

Once an RFP is uploaded, the app shows it broken into its individual questions. Each question sits next to the two or three closest answers we have used before, and each suggested answer shows the answer text, the source proposal it came from, whether that proposal was won or lost, and how old the answer is in months. Matching is on the wording of the question against the question bank, and I want the match to be visibly ranked rather than presented as a single right answer, because the writer is meant to choose. A writer can copy a suggestion into the working answer for that question, edit it, or write from scratch, and their working answers save as they go.

General Input Database holds everything that is not a file. Keep a proposals table with the client, sector, submission date, win or loss outcome and the storage key of the document in the store. Keep a questions table and an answers table so the question bank holds the question text, the answer text, the outcome tag inherited from its source proposal, and the storage key of the proposal that answer came from. Keep an rfps table for uploaded RFPs with the client, sector, storage key, upload date, status and the link to the drafted Google Doc, and an rfp_questions table holding each extracted question, the ids of the answers matched to it, and the working or drafted response. Files go in the store and only the object key goes in a row, never the document bytes.

Each RFP row has a Draft this response button that fires a background agent. The agent pulls the RFP document down using the Presign Download operation, reads it with the Mistral AI OCR operation so scanned and image based documents work as well as clean PDFs, splits the extracted text into individual questions and writes them to the rfp_questions table, matches each question against the answer bank in the database, and drafts a tailored answer per question rather than pasting the closest match verbatim. It then files the assembled draft with the Google Docs Create Document operation and fills the body with the Batch Update Document operation, laying it out as one heading per question followed by the drafted answer and a short provenance note naming the source proposal and its outcome. Finally it writes the document link back onto the RFP row so the archive shows it. While the agent runs, show progress on the row and let the person keep browsing the rest of the app.

The drafting agent needs to know who it is writing for, so it pulls deal context from HubSpot before it writes. Use the HubSpot Search Deals operation to find the open deal matching the client name on the RFP, and the Search Companies operation to pull that company's industry, size and any account notes. The sector and the deal size feed the drafting: a large enterprise bid in a regulated sector gets a different register from a small commercial one. Show the matched deal and company on the RFP detail view so a human can confirm the app latched onto the right record, and let them repoint it if the name match was wrong.

Two rules matter more than anything else and must be baked in everywhere. First, any answer sourced from a proposal older than twelve months is flagged stale wherever it appears, in the suggestion list and in the drafted document, so it is reviewed rather than pasted. The drafting agent treats a stale match as raw material to rewrite and leaves a visible review note against that question instead of quietly reusing old claims about headcount, certifications or product capability. Second, nothing is ever submitted from this app. There is no send action, no portal integration and no email step anywhere in it. The app only ever produces a draft in Google Docs that a named human owns, edits and submits themselves, and the interface should say so plainly at the point where the draft is handed over.

This solves a real and well documented problem: bid teams reuse old answers without verifying accuracy, which causes misalignment across proposals, reviewers spend hours sorting through outdated or duplicate content, and sales teams dig through endless files looking for answers they know exist somewhere. The visible win or loss on every source proposal and the stale flag on every old answer are the direct answers to those complaints, so keep both prominent rather than tucking them into a detail panel.

## How to customize

- Change the twelve month staleness cut off to match how quickly your product claims, certifications or headcount numbers go out of date
- Add your own columns to the archive such as region, contract value or bid owner, and filter and search the list by them
- Adjust how many suggested answers appear beside each question, and the tone and length the drafting assistant writes in

## FAQ

### Does the app ever submit a proposal for us?

No. It never sends anything to a client or a procurement portal. The furthest it goes is producing a draft document in Google Docs that a person on your team owns, edits and submits themselves.

### What kinds of files can we upload?

The PDFs and Word documents that proposals and questionnaires normally arrive as. Scanned documents are fine too, because the app reads the text out of the page rather than relying on a copy and paste layer.

### How does it pick which past answers to show for a question?

It matches the wording of the new question against your answer bank and surfaces the two or three closest matches. Each one is shown with the proposal it came from, whether that bid was won or lost, and how old the answer is, so you can judge it rather than trust it blindly.

### Do you still show answers from proposals we lost?

Yes, clearly labelled as lost. A losing bid often still contains a perfectly good company description or compliance answer, and hiding them would throw away half your library. The outcome sits on the row so the writer decides.

### Do we need to load our whole back catalogue before it is useful?

No. The archive works from whatever you have uploaded so far and gets better as you add more. Most teams start with the last year or two of bids and backfill the older ones over time.

### Why are the proposal files kept separately from the answer text?

Proposal documents are large, so the files themselves live in file storage while the archive holds the client, the date, the sector, the outcome, the questions and the answer text. That keeps search fast while every row still opens the original document.

Use this prompt in General Input: https://www.generalinput.com/prompts/a-searchable-rfp-answer-library-your-bid-team-drafts-from