Follow up to our conversation
RFP Request to Proposal Delivery
What we heard, and a possible way to build it
What we heard, and a possible way to build it
Thank you for the time on August 20, 2026. This is what we took away, and one way it could be built.
Nothing in this document is a commitment or a quotation. It is a design put on paper so that you can see the shape of the thing before deciding whether to go any further. If we have misread how your work actually runs, that is worth finding out now, while a correction costs nothing.
One record that carries a request from the day it arrives to the day the outcome is known.
At present a request for proposal moves through email, shared folders, and spreadsheets, and the state of any given bid lives in somebody's head. The approach proposed here replaces that with a single record. Every request would enter through one route, receive its own reference number, and carry its own approvals, documents, deadlines, and result. Nothing would be retyped from one place to another, and nothing would sit waiting on somebody to remember it.
This is one way to do it, not the only way. It is drawn in enough detail to be argued with, which is the point of sending it. Changing a box on this page costs nothing. Changing it after a system is live costs a great deal more.
Who does what, in what order, and where it happens without anyone touching it
Each column is a team, each box is a step, and diamonds are points where the path splits. The blue column on the right is work the system would do on its own, which is where the time saving comes from. The coral tags mark where the design depends on information only you can supply, numbered C1 to C10 and listed in full on the pages that follow.
Also supplied as a full size image file for slides and proposals.
The same design in plain language, phase by phase
Written in the present tense for readability. Read it as a proposal rather than a decision.
A request arrives through one route instead of several. The moment it lands it is given a reference number, the sender receives an acknowledgement, and the clock starts. Your coordinator checks that the request is complete and asks for anything missing before effort is spent on it.
What changes: no request is lost, and no one has to ask where a bid came from or when it arrived.
You decide whether to bid. If the answer is no, a decline notice goes out and the reason is recorded, so that over time you can see what you are turning away and why. If the answer is yes, a proposal lead is named, an internal deadline is set ahead of the client deadline, and the people who need to contribute are notified.
What changes: the decision to chase work becomes deliberate and reportable rather than a habit.
Technical scope and pricing are developed at the same time rather than one waiting on the other. Each is a piece of work in its own right, with its own owner and its own deadline. When both are finished the results return to the main record automatically.
What changes: nobody copies numbers between spreadsheets, and the estimate and the scope cannot drift apart.
Proposals above your approval limit go to management for review of scope, margin, and risk. Proposals below it proceed without waiting. If a reviewer asks for changes, the proposal returns to the person who owns the part that needs changing, and the number of revision cycles is counted.
What changes: management time goes to the bids that warrant it, and the rest stop queueing behind them.
The proposal document is generated from your own template using information already captured, rather than assembled by hand. Someone other than the author runs the final compliance check, and any missing mandatory item blocks submission. The proposal is delivered and the confirmation is filed against the record.
What changes: the last hours before a deadline are spent reviewing, not formatting.
A follow up is scheduled automatically so that submitted proposals are not forgotten. When the outcome is known it is recorded with a reason. A win creates the delivery record and hands the work over. A loss feeds your win rate reporting.
What changes: the reporting builds itself out of ordinary work instead of being a separate exercise at month end.
Ten questions we could not answer from the call
These are the decisions a design cannot make on anyone's behalf. Each row matches a coral tag on the map. Nothing here needs answering today. If you decide to take this further we would send a short workbook with a ready made table for each of the rows that needs one, and a few sentences by email covers the rest.
| Ref | What we would need | Why it matters | Where it lands | How it would be provided |
|---|---|---|---|---|
| People | ||||
| C2 | Names, roles, and email addresses for each team on the map, and who covers each role during absence. | Every step has to reach a real person. Without a named backup, one holiday stalls a bid. | Every column of the map | Role directory sheet |
| Rules | ||||
| C1 | How requests reach you today, and what a requester must provide before you will look at one. | Sets the intake form and stops incomplete requests entering the process at all. | Step S1 | Written answer |
| C4 | Your turnaround targets for each stage, and how much time you want held back before a client deadline. | Sets every reminder and escalation. This is what stops a proposal being finished the hour it is due. | Steps S4 and A2 | Written answer |
| C5 | Approval limits by value or margin, who holds them, and what requires more than one approver. | Decides which proposals wait for management and which proceed under delegated authority. | Steps D2 and S7 | Approval limits sheet |
| C9 | What triggers handover to delivery once you win, and what your delivery team needs on day one. | Connects a won proposal to the work that follows, without a second round of data entry. | Step A5 | Written answer |
| Documents | ||||
| C6 | Your current proposal template, cover letter, and decline letter. | Documents are generated in your format and your voice, not a generic one. | Steps S3 and S8 | Word or PDF files |
| Lists | ||||
| C3 | Your bid or no bid criteria, and the reasons you decline. | Makes qualification consistent between people, and makes declines countable. | Steps S2, D1 and S3 | Code lists sheet |
| C7 | Everything that must be checked before a proposal leaves the building. | Insurance, certificates, signatures, formats, addenda. Anything a client has ever rejected you for. | Step S9 | Code lists sheet |
| C8 | The reasons you win and lose, and how you want win rate reported. | Determines whether the reporting answers your questions or somebody else's. | Steps D4 and A6 | Code lists sheet |
| Systems | ||||
| C10 | What this would need to connect to, and who owns access to each one. | Email, document storage, finance, and any board you already run. Access usually takes longer to arrange than the build. | Steps A1, A4 and A5 | Written answer |
From this document to a working process, if you decide to go on
Mark up anything that does not match how the work actually runs, including anything we recorded wrongly from the call. We would rather hear it now than build it twice.
Revised with your corrections, so that what we are discussing is a process you recognise as yours.
We send a short workbook that collects them. Partial answers are fine to start, so long as the approval limits and system access are moving.
The design is confirmed in writing, and only then does the build start, in a test environment where nothing touches live work.
Your own people run their own work through it. Adjustments happen here, while they are still cheap.
A short training session, then a review after thirty days against the reporting the process now produces.
Signed when you are ready to proceed, not before
There is nothing to sign at this stage. This page is included so you can review in advance what the final confirmation will cover and raise any questions or changes while they are still easy to address.
Signing below would confirm the following:
Changes requested after confirmation are handled as a change to scope. Some are straightforward. Some cannot be made at all once the process is live.