A proposal link is a proposal published at an address rather than attached as a deck or PDF, so it opens on a phone, forwards as a single version, and can be revised without resending anything.
Proposals are read in a way documents are not built for. They get forwarded, skimmed under time pressure, and opened again a week later by someone who was not on the original thread.
This guide covers the order things should appear in, writing for the colleague who was not on the call, and how revisions work once the proposal is circulating inside the client.
Put the answer at the top
Proposals commonly open with background: who you are, how you work, what you understand about the client's situation. All of it true, none of it what the reader wants in the first screen.
They want to know what you are proposing, what it costs, and when it happens. Give them that, then justify it.
<header class="rec">
<p class="what">A two-phase rebuild of the booking flow</p>
<p class="price">62,000 <span>over 14 weeks</span></p>
<p class="who">Prepared for Meridian Retail · 17 September 2026</p>
</header>
This is not impatience. It is how a reader decides whether to keep reading, and a proposal that hides its own answer gets skimmed rather than read.
Write for the person who was not there
Your contact understood everything on the call. They are not the only reader.
The proposal gets forwarded to a finance lead who wants the number in context, a technical lead who wants to know what you will touch, and sometimes a sceptic whose job is to ask why not do nothing. None of them heard the conversation.
So state the problem in your own words before proposing the solution. Two sentences is usually enough, and it gives your contact something to point at when they are defending the spend internally.
| Reader | What they open it for | Where to put it |
|---|---|---|
| Your contact | Confirmation it matches the call | First screen |
| Finance | The number, the terms, the risk | Near the top, then detail |
| Technical | Scope, dependencies, what changes | Middle, with headings |
| The sceptic | What happens if we do nothing | Say it explicitly |
Sections a skimmer can navigate
Nobody reads a proposal top to bottom on first contact. They skim for the part they were asked about.
Short sections with plain headings do most of the work. "What we will build" beats "Approach". "What we need from you" beats "Dependencies". The heading should answer the question the reader has, not name the category it belongs to.
Keep each section to a screen where you can. If a section needs more, it usually contains two ideas that want separating.
The forward is the point
An attachment forwarded three times inside a client becomes three files. If you then revise, there are four, and the one being discussed in the meeting is whichever landed in that person's inbox.
A link forwarded three times is still one address. When you revise, everyone holding it moves together. That is not a small convenience: it removes an entire category of confusion from the end of a sales process, where confusion is most expensive.
The discipline that makes it safe is a revision note. Somewhere near the top, dated, plain: "Revised 2 October: phase two moved after the seasonal freeze at the client's request." Readers accept changes they can see. They do not accept discovering a number moved.
Pricing without ambiguity
Most follow-up questions on proposals are about the number, and most of those are avoidable.
- Say whether tax is included. Every time.
- Break the total into phases if the work has phases. A single large number invites a single large objection.
- Name what is excluded. Naming exclusions makes the price credible; leaving them out makes it look optimistic.
- State payment terms as stages and periods, not as a promise to agree them later.
- Put a validity date on the page, and leave the page working after it.
When the format is dictated
Public tenders, procurement portals and some large clients specify submission formats and reject anything else. That is not a battle worth having.
Submit what is required. Then send the link to the people you actually talk to, because the formal submission is read by a process and the link is read by a person. Both matter, and they are not the same document doing the same job.
If you need the file to come from the same source as the page, print rules control the export. Details in export HTML to PDF.
Put it at an address
Write the proposal as a page, paste it into a document, create a share link, and put that link in the body of your email rather than attaching anything.
It opens on the phone your contact is holding. It forwards intact. And when the scope moves during the conversation, as it usually does, the proposal moves with it instead of splitting into versions.