agentleFS
SkillMedevSkillMedev/freelancer-consultant-os/skills/sales-proposal-writer/SKILL.md

sales-proposal-writer

Skill0 starsChanged 4 months agoMITView on GitHub

Writes a B2B sales proposal or SOW that restates the buyer's problem in their own words, quantifies the cost of inaction, presents price as anchored options, and drives one dated next step. Use when someone asks "write a proposal for this client", "turn my discovery notes into a proposal", "how should I present pricing in this proposal", or when a deal needs a document to move from discovery to close. Do NOT use for a one-page internal decision brief - use one-pager-designer instead; for investor decks use pitch-deck-builder; for setting the underlying price model use pricing-strategy.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Make the cost of inaction concrete: Use the buyer's numbers. "Your team currently spends ~40 hours/month reconciling exports, roughly …

    line 28
  2. Distinctive:

    Add a validity window: Every proposal expires - 30 days is standard.

    line 32
  3. Distinctive:

    Do NOT list features the buyer never asked about: - every unrequested feature dilutes the ones they did.

    line 83
  4. Distinctive:

    Do NOT include a generic ROI calculator: not built from the buyer's actual data - it undermines credibility more than it helps.

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Sales Proposal Writer

A proposal should make the buyer feel understood before it sells anything. If the first page is about the vendor, the buyer stops reading; if the price appears as one take-it-or-leave-it number, the negotiation becomes about discounting instead of scope. This skill produces a proposal that mirrors the buyer's own words back to them, anchors the price with options, and expires - so the deal has a reason to move.

Inputs to collect

Gather these before drafting. Where an input is missing, use the default and label the guess as a guess.

  1. Discovery notes or call transcript - the buyer's own phrasing of the problem is the raw material for the opening. Without at least one direct quote or near-quote, the proposal will read as a template.
  2. The quantified pain - numbers the buyer gave (hours lost, revenue at risk, headcount cost). If none surfaced, compute a reasonable range and flag it: "estimated, based on your stated team size of 12."
  3. Named stakeholders - who signs, who uses, who blocks.
  4. Deal size and complexity - determines document length and whether itemization is warranted.
  5. Proposed scope options - what a lean, standard, and expanded engagement would each contain.
  6. Desired start date - anchors the validity window and the next step.

Operating procedure

Order matters: the buyer's problem must be established before any solution appears, and price must never appear before value.

  1. Restate their problem in their words, first. Open with a two-to-three-sentence situation summary that mirrors discovery. Quote the buyer directly where possible. This section mentions the vendor zero times.
  2. Make the cost of inaction concrete. Use the buyer's numbers. "Your team currently spends ~40 hours/month reconciling exports, roughly $48K/year at your stated loaded cost" beats any adjective. Label estimates as estimates.
  3. Present the approach as outcomes, not activities. "Your team will be able to close the books in 3 days instead of 9" beats "We will deliver a data pipeline." One paragraph per outcome.
  4. Define scope and deliverables per phase or workstream. Specific enough to be credible, loose enough to avoid scope arguments before the contract is signed. Push technical detail to an appendix.
  5. Present the investment as options with an anchor. Offer two or three tiers, listed highest first - the anchor. The middle option is the one most buyers should choose; design it that way. Do not itemize line-by-line unless the buyer asked or the deal is complex enough to require it: itemized pricing invites nickel-and-diming. A single number is acceptable only for transactional deals under roughly $10K.
  6. Add a validity window. Every proposal expires - 30 days is standard; 14 days for a deal with a stated urgent start date. An open-ended proposal gives the buyer permission to stall indefinitely.
  7. Close with one dated next step. One action, one suggested date within 5 business days: "If this looks right, the simplest path forward is a 30-minute call Tuesday to align on the start date."
  8. Run the customization check. Confirm at least three details that could only apply to this buyer: their team size, a specific pain they named, a named stakeholder. Fewer than three and the proposal reads as a mail merge - and will be treated like one.

Thresholds

  • Body length: under 3 pages for a typical mid-market deal; readable in under 5 minutes. Appendices carry technical specs and legal terms.
  • Situation summary: 2-3 sentences, at least one buyer quote or near-quote.
  • Pricing: 2-3 options, anchor listed first; middle option designed as the intended choice.
  • Validity: 30 days standard, 14 days when urgency is real.
  • Next step: dated within 5 business days of sending.
  • Customization: minimum 3 buyer-specific details.

Proposal skeleton (copy and fill)

[BUYER COMPANY] - Proposal: [OUTCOME, NOT PRODUCT NAME]
Prepared for [STAKEHOLDER NAME], [DATE] · Valid through [DATE + 30 DAYS]

1. YOUR SITUATION
[2-3 sentences mirroring discovery. Include: "[DIRECT BUYER QUOTE]"]

2. WHAT THIS IS COSTING YOU
[FILL: buyer's numbers → annualized cost. Label estimates: "estimated, based on [STATED FACT]"]

3. PROPOSED APPROACH
[FILL: 2-3 outcome statements - "Your team will be able to X"]

4. SCOPE & DELIVERABLES
Phase 1 - [NAME]: [deliverables, duration]
Phase 2 - [NAME]: [deliverables, duration]

5. INVESTMENT
Option A - [EXPANDED SCOPE]: $[ANCHOR PRICE]
Option B - [STANDARD SCOPE]: $[INTENDED PRICE]   ← most clients choose this
Option C - [LEAN SCOPE]: $[FLOOR PRICE]
Pricing valid through [DATE].

6. NEXT STEP
[ONE action, ONE date]: "If this looks right, a 30-minute call on [DAY] to align on start date."

Appendix: [technical specs / legal terms / assumptions]

Deliverable

Produce a proposal document containing: the buyer-worded situation summary, the quantified cost of inaction, outcome-framed approach, phased scope, a 2-3 option anchored investment section with a validity date, one dated next step, and an appendix for anything technical or legal.

Do NOT

  • Do NOT lead with a company bio or awards page - it signals a template and the buyer stops reading.
  • Do NOT list features the buyer never asked about - every unrequested feature dilutes the ones they did.
  • Do NOT include a generic ROI calculator not built from the buyer's actual data - it undermines credibility more than it helps.
  • Do NOT present price before value - investment is section 5, never section 1.
  • Do NOT skip the expiry date - an undated proposal has no forcing function.
  • Do NOT write a formal document for a small transactional deal. Use the same structure - situation, value, scope, price, next step - as three short paragraphs in an email instead.

Quality bar

Before sending, verify: the first section contains zero vendor mentions and at least one buyer quote; the cost of inaction has a number; pricing shows options with the anchor first and a validity date; the next step names a date; at least three buyer-specific details appear; the body reads in under five minutes with no jargon, buzzwords, or passive voice. Any sentence that does not add information the buyer needs to decide gets cut.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.