Proposal and Quote

A good proposal is a summary of an agreement already reached in conversation, written so the buyer can forward it to people who were not in the room. You draft it overnight from the call notes: their problem in their language, what will be done, what it costs, what happens next. The standard: no surprises for the buyer, every number adds up, every promise is one the owner has approved, and the economic buyer could decide from the first page alone.

When to use

• "Turn yesterday's call into a proposal for Acme."
• "They want a quote for 3 sites and 40 users."
• "We got an RFP from the council; should we bid, and can you draft it?"
• "Update the proposal; they want the smaller option too."

What you need

• Discovery notes, the qualification scorecard and the email thread: pains, metrics, decision criteria, decision process, stakeholders, timeline. If discovery is thin (no agreed problem, no economic buyer known), tell the owner before writing; a proposal cannot fix missing discovery.
• The owner's commercial rules, from memory, a shared drive (connected Google Drive) or clarify:
  • price list or rate card, discount rules and who can approve what;
  • standard terms (payment terms, contract length, renewal, cancellation);
  • any proposal template or brand style.
• Approved proof: case studies and references the owner allows you to name.
• For RFPs: the full document set, deadlines, submission rules and evaluation criteria.

Method

1. Confirm the buyer actually wants a proposal now, and what they will do with it (forward to finance, compare three vendors, take to a board). This decides length and emphasis. If the economic buyer has not been involved, recommend walking them through it live rather than emailing a PDF.
2. RFP go or no-go first. Answer each question yes or no:
   • Did we know about this opportunity before the RFP arrived?
   • Can we meet every mandatory requirement?
   • Do we have relevant, approved proof?
   • Is the evaluation weighted on things we do well?
   • Is the deal worth the effort of responding?
   • Can we ask questions of someone on the buyer's side? Two or more "no" answers: recommend not bidding and say why. The owner decides.
3. Outline before writing, using references/proposal-template.md:
   • Executive summary (half a page): their situation, the goal, the recommendation, the investment, the decision needed and by when.
   • Their challenge, in their words, with the numbers they gave.
   • Objectives and how success will be measured (baseline, target, date).
   • Proposed solution and scope: what is included, what is explicitly not, what the buyer must provide.
   • Approach and timeline: phases, milestones, who does what.
   • Options and investment.
   • Why us: two or three proof points that match their decision criteria.
   • Assumptions, risks and dependencies.
   • Terms summary and next steps to start.
4. Build options deliberately. Usually two or three, each a complete answer to their problem at a different level of scope (for example: one site; all sites; all sites plus support). Recommend one and say why. Do not add a decoy option nobody would buy.
5. Build the quote as a table:
   • line item, description, quantity, unit price, discount (shown separately, never hidden in the unit price), line total;
   • subtotal, tax, total, currency;
   • billing frequency, payment terms, and the date the quote expires. Use execute_code to calculate and re-check every total. Tax treatment depends on the country and the buyer; do not guess: ask the owner or write "tax to be confirmed".
6. Show the return, conservatively. Use the buyer's own figures from discovery: value = (baseline minus expected result) x frequency x cost per unit. Show the working and the assumptions, and round down. If you lack their figures, leave the return section out rather than inventing one.
7. Write it for the reader.
   • Their vocabulary, not internal jargon.
   • Headings that state the point ("Planning time drops from 15 to 3 hours a week").
   • Tables for comparisons; short sections.
   • Name the people involved on both sides.
   • 4 to 8 pages of body for most deals; detail goes in appendices.
8. Mark everything the owner must confirm. Highlight prices, discounts, non-standard terms, delivery dates, guarantees, service levels and any promise. Legal terms (liability, indemnities, data processing, intellectual property) are for the owner and, where the owner chooses, their legal adviser; do not draft new legal language.
9. Review against the scorecard.
   • Does the proposal answer every decision criterion?
   • Is every pain from discovery addressed?
   • Is anything in it new to the buyer? If so, flag it: surprises in proposals kill deals.
10. Draft the cover email: three short paragraphs covering what is attached, the recommendation in one line, and the next step with a date (such as a 20-minute walkthrough with the economic buyer).
11. Get approval, then send.
    • Put the summary, price table and highlighted items on a show_card.
    • Produce the document in the owner's format: connected Google Docs, or a .docx or PDF built with execute_code.
    • Send only after explicit approval.
    • Log it in the CRM with the amount, options and expiry date, and set a follow-up date (see sales-follow-up).

Output

• The proposal document (4 to 8 pages plus appendices) and the quote table.
• A one-screen summary for the owner: recommended option, total, any discount and its reason, non-standard terms, items needing approval.
• The cover email draft.
• For RFPs: the go or no-go note, a compliance matrix (requirement, our answer, section reference) and the draft response.

Checks before you finish

• All totals recalculated in code, and they match the text.
• Currency, tax handling, payment terms and expiry date are stated.
• Scope says what is excluded and what the buyer must provide.
• Every pain and decision criterion from discovery is addressed.
• No invented proof, return figures or promises; every approval item is highlighted.
• Spellings of the buyer's company and people are right; their logo or brand is not misused.

Pitfalls

• The brochure. Twenty pages about the seller and one about the buyer. Flip it.
• Proposal as discovery. Sending a proposal to find out if they are interested. Qualify first.
• Hidden discounts. Baking discounts into unit prices makes renewals and future price talks harder. Show them.
• Too many options. More than three confuses and delays.
• Vague scope. "Implementation support" without limits becomes unpaid work. Define it.
• Emailing a proposal into silence. Walk the decision-maker through it whenever you can.

See also: discovery-qualification, negotiation-prep, sales-follow-up.