Most of every proposal your team sends is the same as the last one. The company description, the approach, the terms, the team page, the security appendix: these do not change from prospect to prospect, and yet each one gets rebuilt, slightly differently, under deadline pressure, by whoever is writing that week. The result is a shelf of near-identical documents with small inconsistencies (an old price on page eight, a team member who left in March) and a lot of hours spent reassembling things that were finished months ago.
The fix is a modular proposal: a set of standard pages that are maintained once and dropped in unchanged, a small set of pages that are rewritten for every prospect, and a versioning habit that tells you which standard pages were current when a given proposal went out. Standardise the parts nobody reads twice; spend the saved hours on the pages that decide the deal.
This article works through what to standardise, what to keep bespoke, how to version it without a document management system, and how to let reading data edit the template over time. It assumes you send proposals as PDFs via a personal link, as described in the golden rules of sending offers and proposals.
The modular proposal
Think of the proposal as three layers.
Fixed modules. Pages that are identical across every proposal in a given period: who you are, how you work, terms and conditions, data handling, the team, the standard timeline for onboarding. Written once, reviewed on a schedule, never edited inside a live proposal.
Configured modules. Pages built from standard blocks, where the blocks are selected and ordered per prospect but not rewritten: a pricing page assembled from a price list, a scope page assembled from a menu of services, example descriptions chosen for relevance. The blocks are standard; the selection is bespoke.
Bespoke pages. Pages written from scratch for this prospect: the summary on page one, the statement of their situation, the specific recommendation. These are where the deal is won, and they should be the only pages you write under deadline.
The proportion matters less than the discipline. A twelve-page proposal might have seven fixed pages, three configured, two bespoke. The two bespoke pages get the writer’s full attention because the other ten took twenty minutes.
The pages that never change
Fixed modules earn their place by being finished. Here is what typically belongs there and how to keep each one honest.
About us. One page. Readers spend almost no time here, and the reading data will confirm it. Keep it short and factual, and stop redesigning it.
How we work. The method, the phases, what the client does and what you do. This is the page prospects skip until they are serious, then read carefully. Worth getting right once.
Terms. Payment terms, cancellation, liability, intellectual property. Owned by whoever handles contracts; nobody else edits it. If a prospect negotiates a change, the change goes in a bespoke addendum page.
Security and data. Where data lives, who can see it, what you sign. Increasingly the page that decides whether procurement says yes. Keep it current with the actual arrangements.
Team. Names, roles, one line each. The page that goes stale fastest. Review it monthly.
Each fixed module has one owner and a review date. The owner’s job is not to write it every time but to keep it true.
The pages that always change
The bespoke layer is small, and it is the whole point.
Page one: the summary. Their situation in two sentences, your recommendation in two, the price and the timeline in one each. A reader who only reads this page should be able to make a decision. This is the page that takes the longest to write and it should never be templated beyond its structure.
Their situation. What you heard on the call, in their words where possible. Prospects read this page to check whether you listened. A templated version (“Companies like yours face increasing pressure to…”) announces that you did not.
The recommendation. What you propose and why this shape rather than another. It references their constraints by name.
Pricing assumptions. The price itself might be configured from a list, but the assumptions under it (how many users, which sites, what is excluded) are bespoke and must match the conversation exactly. This is where most disputes later begin.
Everything on these pages should be traceable to something the prospect said. If a sentence would work in another prospect’s proposal, it belongs in a module. The same test applies to the email that carries the link; the cover letter email for a proposal covers what that email should promise.
Versioning without chaos
The problem with modules is knowing which version went to whom. A prospect who signs in November against terms you changed in October is a problem, and so is a team page that lists someone who left.
A simple scheme that works without any document management software:
Give each fixed module a version tag in a small footer: the module name and the date it was last reviewed. “Terms, reviewed 2026-08”. A change to the module means a new date. Nothing else changes.
Keep a one-line changelog per module, in whatever shared document your team already uses: date, what changed, who approved it. Ten lines a year is typical.
Name proposal files with the prospect, the date and a version letter: prospect name, 2026-09-01, v2. When a prospect asks for a change, the new file is v3; the old one is kept.
Assemble from current modules only. Never copy the last prospect’s PDF and edit it; assemble fresh from the module set, then write the bespoke pages. This is the habit that stops old prices surviving into new proposals.
If you send proposals as personal links, the link itself becomes part of the versioning. In Seegnals each offer is one uploaded PDF with its own link, so the document a prospect saw is exactly the one on record, and the offers list shows which recipient has which document and whether it has been read.
One row per recipient, one document per row. When a prospect asks which version they saw, the answer is here rather than in a folder of similarly named files.
What to keep bespoke, even when it hurts
There will be pressure to template more. Resist it in four places.
The first sentence. Not “Thank you for the opportunity to submit this proposal.” A first sentence about them.
The example. If you include a worked example or a mock-up, build it on their data, their product names, their sites. A generic example is a page the reader skips; a specific one is a page they show colleagues.
The objection you heard. Every call surfaces a worry. Put it on the page and answer it. A template cannot know what they said.
The next step. What happens after they say yes, with their dates. “We would start the week of 6 October, before your Q4 freeze” is bespoke; “Implementation typically takes four to six weeks” is a module sentence pretending to be personal.
Two bespoke pages written well beat ten pages of light customisation. The reader can tell which sentences were written for them.
Let the reading data edit the template
If the proposals go out as tracked links, every send is a test of the template, and the results come back as reading time per page. Over a dozen proposals, patterns appear that no internal review would have found.
Pages nobody reads. If the about-us page collects a few seconds across every proposal, shorten it or move it to the back. If the security page gets skipped by small companies and studied by large ones, make it a configured module that appears only when procurement is involved.
Pages that stall. If readers consistently stop on the same fixed page, the page is doing damage: too long, unclear, or placed where it interrupts. Fix the module once and every future proposal benefits.
Pages that pull returns. If the pricing page is where readers come back, it is doing its job; make sure it stands alone, with the assumptions on the same page rather than three pages earlier.
Order. If readers jump from page one straight to pricing, put pricing on page two and stop fighting it.
Reading time per page covers how to read these patterns without over-reading them. The important thing for template design is the loop: a module change is a hypothesis, the next few proposals are the test, and the review date on the module is when you look.
Read across proposals rather than within one: a module that collects nothing on every send is a module to cut, whatever the internal review thought of it.
Configured and bespoke pages should be judged too, but differently: their reading time tells you about this prospect, while a fixed module’s reading time tells you about the template. When to follow up based on reads covers the per-prospect side.
What to do this week
- Take your last five proposals and mark every page as fixed, configured or bespoke. Count how many pages were rewritten that did not need to be.
- Build the fixed module set from the best current version of each page, add a review date footer to each, and assign one owner per module.
- Write the one-line changelog and put it where the team already looks; log the module set as version one.
- For the next proposal, assemble from modules first, then write page one, the situation page and the pricing assumptions from scratch.
- After the next few sends, open the reading time per page for each and note which fixed modules collected nothing; shorten or move them at the next review.