Web proposals
Web proposals instead of PDFs
A web proposal is a proposal at a link instead of an attachment: you can fix it after sending, and you can see which sections the client read.
In short
- A PDF closes the moment you send it — after that you know nothing about it.
- A proposal page lives at one link, so an edit does not create a second version of the truth.
- Reading data tells you when to follow up and what to say in it.
- On a phone the page wins outright, and a large share of first opens happen on a phone.
- PDFs stay right where a frozen attachment or a procurement format is required.
How is a web proposal different from a PDF proposal?
The difference is functional, not cosmetic: a file is a copy, a page is a place. You can forward a copy, but you cannot update it or learn what happened to it.
| PDF proposal | Web proposal | |
|---|---|---|
| Fix after sending | New file, new email | Same link, current content |
| Know if it was opened | No | Yes, with date and time |
| Know what they cared about | No | Yes — which sections, and for how long |
| On a phone | Pinch, zoom, scroll sideways | A normal page |
| Video, calculators, clickable pricing | No | Yes |
| Works offline | Yes | No |
| Contract attachment / procurement | Native format | Needs an export |
Why does it matter what the client read?
Not to apply pressure. To stop guessing. The classic follow-up says 'just checking in' and carries no information, because the rep has nothing to go on except elapsed time.
When you can see the client came back to pricing and spent three minutes there, you know two things: they are still in the deal, and price is the topic. The follow-up can then be about scope and options instead of empty politeness.
A moment, not an interval
You write when the client returns to the proposal, not 'after three days' because that is the convention.
A subject, not a reminder
You know which section held their attention, so you have something to say.
A signal it travelled internally
A return visit from a new context usually means someone else on their side is reading it.
Is tracking a proposal fair to the client?
It depends on how it is built, and it is worth having a clear answer before somebody asks. In Proposals a published proposal neither writes nor reads anything on the recipient's device — no cookies, no localStorage, no browser fingerprinting.
Engagement is computed server-side from data the request already carries, and the reader identifier is bound to a single proposal, so it cannot be used to link the same person across different proposals. What the client sees is a well-prepared proposal at one link.
When is a PDF still the better choice?
Honestly: in three situations. When the proposal is an annex to a contract and has to be a frozen version. When a tender or procurement process demands a specific file format. And when the recipient works in an environment cut off from the internet.
So a web proposal does not have to exclude the PDF — a sensible process uses the page as the decision material and exports a file when formality requires one.
See it live
Open a sample proposal and see what the client sees
A real proposal generated by Proposals — argument, pricing and next step. Open it on your phone; that is where the gap with a PDF is widest.
Web proposal FAQ
Related
Updated: August 12, 2026