How to Write a Sales Proposal: Structure, Pricing, and Knowing Who Read It

Knowing how to write a sales proposal means doing two jobs well. The first is the document: a short argument that starts from the buyer's problem and ends on a dated decision. The second is the send: one current version in front of the whole buying group, and a way to see who read the part that costs money. Below you'll find the seven sections in order, how long each runs, a fill-in template, a prompt for drafting with AI, and how to send the proposal so your next call starts from facts.

What to include in a sales proposal, and in what order

A proposal is the written version of a decision the buyer is already partway through making. Each section should move that decision one step, and this sales proposal structure follows the order a buyer's questions tend to come up in:

1. Their situation, in their own words. Evidence you listened.
2. The outcome. What changes for them.
3. The approach. How you get them there.
4. Scope, and what's excluded. What the price buys, and what it doesn't.
5. Pricing, with two or three options. What it costs, and which choice fits.
6. Proof. Why they should believe you can deliver.
7. A dated next step. Who does what, by when.

Two things are left out on purpose: the company history and the product tour. A fact about you belongs in the proof section if it helps the buyer decide, and nowhere if it doesn't. Pricing follows scope because a number means nothing until the reader knows what it buys. Proof follows pricing because that is where doubt peaks.

How to write a sales proposal, section by section

Their situation, in their own words

Open with two or three sentences that restate the problem the way the buyer described it in discovery, using their words rather than yours. If the operations director said "we lose a day every month reconciling three spreadsheets," write that, not "data fragmentation creates operational inefficiency." Then list the two or three pains or constraints you heard, and the cost of doing nothing if they named one. Besides proving you listened, this gives the champion a summary to repeat to colleagues who weren't on the call. Aim for 100 to 150 words.

The outcome

Say what changes when the work is done, in terms the buyer could check later: month-end close takes one day instead of three, or new reps run their first call in week two. One to three outcomes, each concrete enough that someone could later say whether it happened. If you can't write one the buyer would check, you aren't ready to propose yet, so go back to discovery. Keep it to 50 to 100 words.

The approach

Explain how you get from their situation to that outcome in three or four phases, with a rough timeline: what happens in each, what the buyer provides, and what they get at the end. Your method doesn't change much from deal to deal, so this is where reusable material pays off. Still, name their systems, teams and dates so it doesn't read as boilerplate. At 150 to 300 words it is the longest section, and it should still come out shorter than your first draft.

Scope, and what's excluded

Two short lists: what's included and what isn't. The exclusions stop the scope creep that turns a good deal into a bad project, and a procurement reviewer reads them first. Write them plainly ("Migrating data from the legacy system is not included; we can quote it separately") rather than burying them in the terms and conditions. Allow 100 to 200 words.

How to present pricing, proof and the next step

Pricing: two or three options

A single price leaves the buyer two possible replies: yes or no. Two or three options change the question to "which one?" Build them from the scope you just wrote:

• Core: delivers the stated outcome and nothing more.
• Recommended: adds what you believe they actually need. Label it as your recommendation and give one sentence on why.
• Expanded (optional): the version of the project they mentioned wanting "eventually."

Give each option a total price with its billing schedule beside it, a line or two on what it includes, and anything else that changes, such as timeline or terms. Don't make the reader multiply a per-unit rate, and say how long the quote is valid. Stop at three, because past that point comparing options turns into homework. The table plus a sentence per option runs 100 to 200 words.

Proof

Proof answers the doubt the price just raised. Pick the one or two pieces that match this buyer: a comparable customer result you have permission to share, an offer to talk to a reference, or a pilot result. One relevant case beats a wall of logos. Every claim here has to be one you could back up on the spot if asked. If you can't, cut it. Allow 75 to 150 words.

A dated next step

End with one action, one owner and one date: "If Option B works, we'll send the order form by Friday the 14th so kickoff can start the Monday after." Not "let us know if you have any questions." A date gives the champion something to take into their internal meeting, and gives you a better reason to follow up than "just checking in." It takes 25 to 50 words.

How long should a sales proposal be?

Long enough to cover the seven sections, and no longer. Add up the ranges above and the body of a proposal runs about 600 to 1,150 words, or two to four screens, including the pricing table. Large or regulated deals add appendices like security answers, detailed terms or a statement of work. Those go after the next step, not in the middle of the argument.

Length goes wrong in both directions. A long proposal pads the approach and repeats itself, so the buyer skips straight to pricing. A very short one tends to drop the situation and the exclusions. Those are the two sections that carry the champion's internal meeting and head off the scope argument later.

Sales proposal template: a fill-in skeleton

Use this sales proposal template as the starting point for every deal. Fill in everything in square brackets and keep the rest.

PROPOSAL FOR [Company]: [Project name]
Prepared for [Champion, title] | Valid until [date]

1. WHERE YOU ARE
On [date], you told us [the problem, in their words].
- [Pain 1, with their number if they gave one]
- [Pain 2]
- [Constraint: deadline, budget cycle, system that stays]

2. WHAT CHANGES
When this is done, [outcome 1, checkable]. [Outcome 2.]

3. HOW WE GET THERE
Phase 1, [weeks]: [what happens]. You provide [input].
  You get [deliverable].
Phases 2 and 3: same pattern.

4. SCOPE
Included: [item]; [item]; [item]
Not included: [item, and whether you can quote it separately]

5. OPTIONS
A. Core: [total], [billing]. [What it includes.]
B. Recommended: [total], [billing]. [What it adds; why.]
C. Expanded, optional: [total], [billing]. [What it adds.]

6. WHY US
[One comparable result you may share, or a reference offer]

7. NEXT STEP
If [option] works, [owner] will [action] by [date]
so [milestone] can start [date].

How to personalize without starting from scratch

Personalizing a proposal doesn't mean rewriting it. Sort the sections into three tiers and spend your time where it counts:

• Always new: situation, outcome, pricing and next step. These come from this buyer's discovery and nowhere else.
• Adapted: approach and scope. Keep a small library of phase plans and scope lists by deal type, then swap in the buyer's systems, teams and dates.
• Selected: proof. Keep a short list of shareable results tagged by industry and use case, and pick the closest one or two.

If you could swap the situation sections of two proposals to different companies and nobody would notice, discovery didn't really happen, whatever the CRM says.

How to draft a sales proposal with AI from discovery notes

An AI assistant is good at turning discovery material (a call transcript, a CRM summary, bullets typed during the meeting) into a first draft in this structure. It can't know your margins, what you're allowed to promise, or which customer results you may share. So the rule is firm: the AI drafts; the rep owns pricing and every claim. Every number, outcome, proof point and date in the version that goes out has been checked by the rep, who would defend it on a call.

This prompt works in Claude, ChatGPT, Gemini or any capable assistant:

You are drafting a sales proposal from my discovery notes, below.

Rules:
1. Use only facts in the notes. Never invent numbers, results,
   customers, dates or features.
2. Write the situation section in the buyer's own words. Quote
   them where the notes have quotes.
3. Use these sections in this order: situation, outcome,
   approach, scope and exclusions, options, proof, next step.
4. Lengths in words: situation 100-150, outcome 50-100,
   approach 150-300, scope 100-200, options 100-200,
   proof 75-150, next step 25-50.
5. Write no prices. In each option, put [PRICE - REP TO FILL]
   in its own table cell with data-price="a", "b" or "c".
6. For proof, use only the items under "Approved proof". If
   there are none, write [PROOF - REP TO FILL].
7. Where the notes don't answer something, write
   [CONFIRM: your question] instead of guessing.
8. End with one next step that has an owner and a date. If the
   notes give no date, write [CONFIRM: date].

Output one complete HTML document: CSS in a <style> block,
an id on each section (situation, outcome, approach, scope,
pricing, proof, next-step), and every tag closed explicitly,
including </p>, </li>, </td> and </tr>.

Discovery notes:
[paste notes]

Approved proof:
[paste approved results, or "none"]

Then check the draft against your notes before it goes anywhere:

• Fill in every price yourself from your price list or deal desk, never from a figure the model suggests.
• Search the draft for [PRICE, [PROOF and [CONFIRM. Nothing goes out with one left in.
• Check each outcome and proof claim against a source you could show the buyer.
• Read the situation section as the buyer would. If they wouldn't recognize their own words, rewrite it.

The prompt asks for HTML with an id on each section because the draft is about to become a page, and the ids make it easy to update after the call.

How to send a sales proposal and see who read it

Send a page, not a PDF attachment

A PDF attachment is a copy. Every forward makes another one, and none of the copies can be updated or tell you whether anyone opened it. A page behind a link is one document: everyone sees the current version, and every open is recorded.

HTMLvault turns your HTML into a private, tracked link. If the draft is in Claude, ChatGPT, Gemini or Cursor, you can publish it from the chat through the MCP server (the Claude connector guide covers setup). You can also paste or upload it on the web, or publish from a script or a Zapier step through the REST API. Three rules keep the page publishable, whether you wrote it or an AI tool did:

• Bring your own CSS and fonts. The page is served exactly as written, and HTMLvault adds no stylesheet.
• Close every tag explicitly. Malformed HTML is refused, not repaired. Leaving out optional end tags like </p>, </li>, </td> and </tr> can push a long page past the limit of 1,000 nested levels.
• Link images by https URL. A data: URL in an <img src> is removed when you publish. A hosted logo or an inline SVG chart survives, and keeps the page well under the 5 MB limit.

Every publish is also checked for secrets and personal data. The check is a regex scan, so it costs no AI tokens. Under your account's scanning policy, an API key carried over from discovery notes comes back as a finding instead of going out in the page. Links are never indexed. Set the link to expire on the quote's valid-until date (configurable on Pro; Free links expire after 30 days), and add a password if the deal calls for one.

One tracked link per stakeholder

Most B2B deals have a buying group: a champion, a budget owner, someone from IT or procurement, and sometimes an executive sponsor. Give each of them their own link to the same page. The create_recipient_links MCP tool creates one tracked URL per named recipient. It's still one document, so an edit reaches all of them.

Each link reports its own views, repeat visits, scroll depth, time on page, location and device (per-link analytics explains each one). Read them together:

• Scroll depth shows how far down the page a reader got. Pricing is section five of seven, so a reader who stops above it never saw the numbers.
• Repeat visits from the budget owner close to a decision usually mean pricing is being discussed without you.
• No views is a signal too, especially from the stakeholder your champion says is on board.

To act on this without watching a dashboard, add a webhook. The recipient.viewed event fires when a named recipient opens their link, and Zapier, Clay or your own code can turn it into a CRM task or a Slack message (webhook vs API explains how the push works).

These numbers have two limits. Scroll depth measures how far someone read, not where they lingered: it shows a reader got past the pricing table, not that they studied Option B. And a forwarded link keeps reporting under the original recipient's name, so views from a new city or device on one person's link usually mean it was passed on.

Update pricing after the call without sending a new file

The call after a proposal usually changes something: a discount, a phase moved, an exclusion added. With a PDF, that means v9 and another round of forwards. With a page, you edit it and every stakeholder's link stays the same.

You can replace the whole document (update_link, the web editor, or PATCH /api/v1/links/{slug} with new html), or change only what moved with a patch. A patch (patch_link, or the same PATCH call with patches) replaces an exact piece of text in the stored HTML. It's plain text with no regex, up to 200 patches per call, and either all of them apply or none do. Patches are how an AI agent should change a price, and they only work on a page built for them:

• Give every section, table and price a unique anchor: an id on each section and a data- attribute on each price cell.
• Write each value once. Unless you use replace_all, the text a patch looks for must appear exactly once. A total repeated in the summary and the table makes the patch fail.
• Patch the stored HTML, not your source file. Publishing normalizes the markup: tags are lowercased, attribute values double-quoted, comments dropped, and   stored as a plain character. Fetch the stored page with get_link before you write the text to find, and never use a comment as an anchor.

Here is a stored pricing row, and the patch after the buyer agreed to a lower price for Option B:

<section id="pricing">
  <table>
    <tbody>
      <tr data-option="b">
        <td>B. Recommended</td>
        <td data-price="b">$24,000, billed quarterly</td>
      </tr>
    </tbody>
  </table>
</section>

find:    <td data-price="b">$24,000, billed quarterly</td>
replace: <td data-price="b">$21,500, billed quarterly</td>

The text appears once, so the patch applies. After the same scan as the original publish, every stakeholder's link shows the new price. If the valid-until date moves too, send both patches in one call so the page never shows a new price next to an old date. The link.updated webhook event fires on the edit, which you can use to log the change in your CRM. Then tell the buying group the price changed. The link is the same, but they should hear it from you. For more editing patterns, see editing published HTML without breaking links.

What to do before the next call

Writing the follow-up email is a separate skill, and our follow-up email guide covers what to send and when. What this guide sets up is what the rep knows going into the call.

On the morning of the next call, the rep opens the stakeholder links and sees that the budget owner reached pricing on two visits and the IT reviewer stopped at the exclusions. So the call starts with Option B and the scope questions IT hasn't asked yet, not with "did everyone get a chance to look at it?" And the page everyone has open shows the price agreed on the last call, at the same link each of them was sent.