An enquiry lands on Monday morning. The client is warm, the requirement is clear enough, and everyone agrees this one matters. The proposal goes out on Friday afternoon. Nobody was idle. Nobody was careless. And yet four working days went by, and for three of them the document sat still.
That is the shape of the problem. Proposal turnaround time is rarely lost to writing. It is lost to waiting, to hunting for last quarter’s version, and to a review chain where three people all feel responsible for the same paragraph.
Where the four days actually go
Before you fix anything, time it. Not from memory. Take the last five proposals your team sent and reconstruct the timeline from email timestamps, WhatsApp messages and file modification dates. You are looking for four numbers per proposal.
- Enquiry received to first draft started.
- First draft started to first draft complete.
- First draft complete to approval received.
- Approval received to sent to client.
In most SMB teams, step two is the smallest number of the four. The person actually writing the document usually gets it done in two to four hours of real work. The other three steps are where the days accumulate.
Step one is a queue. The enquiry sits until somebody decides it is their turn to write. Step three is a review chain with no deadline attached to it. Step four is the bit nobody counts: the PDF needs the right logo, the terms page is from an old template, the pricing table lost its formatting when it moved between machines.
The three waits that cost the most
Waiting for scope. The salesperson knows roughly what the client wants but not exactly what the delivery team is willing to commit to. So a message goes out asking for a scope description, and it comes back the next day, in prose, in a WhatsApp reply, needing to be rewritten anyway.
Waiting for a number. Pricing is either invented from the last similar job or escalated to whoever holds the rate card in their head. If that person is travelling, the proposal waits.
Waiting for approval. Three people are on the review thread. Two assume the third has it. The document goes quiet for a day and a half, then gets approved with one comment about a typo.
None of these is a discipline problem. They are all structural. The information the writer needs does not exist in reusable form, so every proposal re-derives it from scratch.
Why the two-hour target is realistic
Two hours is not a stretch goal achieved by typing faster. It is what happens when you remove the three waits.
If scope for your ten most common engagements is already written and approved, the writer does not ask anyone. If rates are itemised and current, the writer does not escalate. If exactly one person can approve and they have a stated window, the document does not go quiet.
What remains is genuine work: understanding this client, choosing the right scope blocks, adjusting quantities, writing the two or three paragraphs that are specific to this deal, and checking the numbers. That is an afternoon at worst. Usually less.
The order matters. Teams tend to attack proposal turnaround time by buying a document tool first. The tool helps with step two, which was never the bottleneck. Build the scope library and the approval rule first, then let the tooling compress what is left.
Build a reusable scope library
A scope library is a set of pre-written, pre-approved blocks describing what you deliver, at what level of detail, with what exclusions. Not a proposal template. Blocks.
Start with your revenue, not your imagination. List the work you actually sold in the last twelve months and group it. Most SMBs find that six to twelve blocks cover the large majority of what they quote. A construction firm might have site survey, structural drawings, MEP coordination, execution supervision. An IT agency might have discovery, design, build, integration, support retainer. A CA firm might have annual filing, GST monthly compliance, internal audit, transaction advisory.
Each block needs five things and no more:
- A plain-language description of what the client receives.
- Deliverables, listed as nouns. Documents, drawings, reports, deployed environments.
- What is explicitly out of scope. This is the block that saves you money later.
- Assumptions the price depends on. Client provides data by a fixed date, site access on working days, one round of revisions.
- The unit you price it in. Per site, per month, per user, per filing, per square foot.
Write each block once, with the delivery lead in the room, and get it signed off. That sign-off is the whole point. When a salesperson assembles a proposal from approved blocks, the delivery team has already agreed to it. The review is not a negotiation any more, it is a check.
Keep the blocks boring and reusable. If a block only ever applies to one client, it does not belong in the library. And pair the library with a real rate card, because scope without price still leaves you waiting. Building an itemised rate card your team can quote from in minutes covers how to structure that side of it.
For the structure of the document that wraps around your blocks, the covering context, the commercials, the terms, see what a good proposal actually contains, section by section. The library fills the middle. The rest of the document should be stable enough that nobody rewrites it.
Exactly one approval gate
Most slow proposals have between two and four informal approvers and zero formal ones. Invert that. One named approver, one clear rule about what needs approval at all, and a stated response window.
Define the gate by exception, not by default:
- Assembled entirely from approved blocks, at rate card prices, standard terms: no approval needed. Send it.
- Discount beyond a set threshold, non-standard payment terms, or a scope block that does not exist yet: one approver, one pass.
- Anything above a value threshold you set for your business: same single approver, but they see it before the client does, not after.
The approver reviews commercials and risk. They do not edit prose. If the language is wrong, that is a library problem to fix once, not a per-proposal correction. Give the approval a window, four working hours is a reasonable starting point, and treat a missed window as approval by default for the first two tiers.
This feels uncomfortable to write down. It is also the single change that moves proposal turnaround time the most, because it converts an open-ended wait into a bounded one.
A worked example
Take a services firm quoting a three-month engagement. Under the old process: enquiry Monday, draft started Wednesday after two reminders, scope confirmed by the delivery head Wednesday evening, pricing checked Thursday, review thread Thursday and Friday, PDF cleaned up and sent Friday at five. Four days elapsed, roughly five hours of actual work.
Under the new process: enquiry Monday at ten. The salesperson opens a proposal at eleven, selects three approved blocks, adjusts quantities, writes a page of client-specific context, and pulls prices from the rate card. Total discount is within threshold, terms are standard, so no gate applies. Branded PDF out by one o’clock.
The difference is not effort. It is that four questions had already been answered before the enquiry arrived.
This is also where the AI Proposals module in BizvoraOne earns its place. It drafts from your library and produces the branded PDF, so the last hour, the formatting and assembly hour, stops being a manual chore. The library and the gate still have to be your decisions.
Measure it without flattering yourself
One metric, defined tightly: hours from enquiry received to proposal delivered to the client, counted in working hours, measured on every proposal including the ones that went badly.
A few honest rules:
- The clock starts when the enquiry arrives, not when the salesperson starts writing.
- It stops when the client has the document, not when the draft is internally ready.
- Report the median and the worst case. The average will hide the four-day outliers, and the outliers are the deals you lose.
- Count how many proposals used only approved blocks. If that number is low, your library does not match your real business yet.
Review the numbers monthly. When a proposal takes three days, ask which of the three waits caused it, and fix that one thing.
When four days is genuinely correct
Some proposals should take four days, or longer. A tender response with technical annexures. A first proposal for a client in an industry you have never served. A bid where the site visit has not happened yet and the estimate would be a guess.
The point is not that everything becomes two hours. It is that you stop paying four days for work that only needed two hours. If eight in ten of your proposals are variations of things you have sold before, those eight should go out the same day. Save the long timeline for the two that deserve it.
What to do first
Pull your last twenty proposals. Group them. Find the five scope blocks that appear most often, and write those five properly with your delivery lead. That is a two-hour meeting, not a project.
Then name one approver and write down the three tiers. Tell the team the rule out loud, so nobody adds a fourth reviewer out of habit.
Measure the next ten proposals against the definition above. You will not hit two hours immediately. You will find out which wait is costing you the most, and that is enough to work with.
