Sales Proposals skill for Codex

A winning proposal reads like it was written for one buyer: it restates their problem and success criteria in their words, shows exactly how the offer meets each one, and makes the decision easy with clear pricing and next steps. A good SOW then makes the promise deliverable: every deliverable has acceptance criteria, every assumption is written down, and any change has a priced path.

Inputs (from discovery)

Do not draft without these; ask for call notes, emails, CRM fields or RFP text:

• Buyer’s problem and its cost (time, money, risk) in their words
• Success criteria: how they will judge the project in 6-12 months
• Decision process: who decides, who signs, who influences, procurement steps, date
• Budget range or pricing signals; competing options including “do nothing”
• Constraints: deadlines, security or compliance reviews, integration requirements
• Your delivery capacity and the standard terms (MSA, rate card, payment terms)

Missing items become explicit questions, not invented assumptions.

Proposal structure

Section	Content	Length
Executive summary	Their situation, the outcome they want, your recommendation, price, timeline	Half a page; the only part some approvers read
Understanding	Problem, impact, success criteria (numbered, to reference later)	Half a page
Approach	How you will reach each success criterion; phases	1-2 pages
Scope and deliverables	What they receive; what is out of scope	Table
Timeline	Milestones with dates or durations from start	Table or simple chart
Team	Named roles and relevant experience	Short
Investment	Pricing options, payment terms, what is included	Table
Value / ROI	Quantified benefit with assumptions they can check	Short
Why us	Proof tied to their criteria: case studies, references	Short
Assumptions and terms	Dependencies, validity period, reference to MSA	List
Next steps	Exactly what happens to start, with dates	3-5 bullets

Map every success criterion to an approach section and a deliverable; a criterion with no matching deliverable is a gap the buyer will notice.

Executive summary pattern

<Company> wants to <outcome> by <date> because <business driver>. Today <problem and
its cost, quantified>. We recommend <solution in one sentence>, delivered in <N> weeks
for <price or range>. Based on <assumption you can check>, this <benefit, quantified>.
To start on <date>, we need <decision/signature> by <date>.

Pricing options

Offer two or three options when the buyer’s priorities are uncertain; one when the scope is clear and agreed.

Model	Use when	Protect yourself with
Fixed fee	Scope is well defined; buyer wants budget certainty	Tight scope, acceptance criteria, change control
Time and materials	Scope uncertain or discovery-heavy	Estimate range, not-to-exceed cap if requested, weekly burn reports
Phased (fixed discovery, then fixed or T&M build)	Large or ambiguous projects	Discovery deliverable that defines phase 2
Retainer / subscription	Ongoing work	Defined hours or capacity, rollover rules, notice period
Value-based	Benefit is large and measurable	Clear baseline and measurement method

Options table:

| | Essential | Recommended | Extended |
|---|---|---|---|
| Scope | Criteria 1-2 | Criteria 1-4 | 1-4 + training and 3 months support |
| Timeline | 6 weeks | 10 weeks | 10 weeks + support |
| Investment | $48,000 | $76,000 | $92,000 |

State currency, taxes (excluded or included), expenses policy and the proposal’s validity period (for example 30 days).

ROI section

Show the arithmetic with the buyer’s numbers and conservative assumptions:

Support agents spend ~6 hours/week on manual invoice lookups (your estimate, call on 10-14).
12 agents x 6 h x 46 weeks x $38/h loaded cost = $125,856/year.
If the integration removes 70% of that work: ~$88,000/year saved.
Payback on the Recommended option: ~10 months.

Label every input as theirs, yours, or an industry estimate. Do not inflate; the buyer’s finance team will check it.

Statement of work

# Statement of Work <number> under MSA dated <date>
1. Objectives - <linked to proposal success criteria>
2. Scope - in scope: <list>; out of scope: <list>
3. Deliverables and acceptance criteria
| # | Deliverable | Acceptance criteria | Due |
|---|---|---|---|
| D1 | Invoice lookup API integration | Returns invoice for 99% of test set of 200 order IDs in < 2 s; passes customer UAT script v1 | Week 6 |
4. Acceptance process - customer reviews within 5 business days; deemed accepted if no
   written rejection listing non-conformities; one rework cycle included
5. Customer responsibilities - <access, data, SMEs, environments, decisions by dates>
6. Assumptions - <volumes, environments, third-party availability>
7. Timeline and milestones
8. Fees and payment schedule - <milestone or monthly; invoice terms>
9. Change control - changes requested in writing; provider returns impact on scope, cost
   and schedule within 3 business days; no work on changes until signed change order
10. Project governance - contacts, status cadence, escalation path
11. Term and termination - per MSA unless stated

Acceptance criteria must be objective and testable. “Customer satisfied” is not acceptance; “passes UAT script v1 with no severity-1 defects” is.

Reviewing a draft

• Executive summary works alone and names price, timeline and next step
• Every success criterion maps to a deliverable
• Pricing arithmetic adds up; options differ in clearly described ways
• Out-of-scope list addresses the obvious “I assumed that was included” items
• Customer responsibilities and dependencies are explicit
• No promise the delivery team has not confirmed (dates, SLAs, integrations)
• Consistent with the MSA; any deviations flagged for legal or finance review
• Buyer’s name, logo and terminology correct everywhere (copy-paste from the last proposal is a classic error)

Gotchas

• Feature-dumping: pages about your company before the buyer’s problem appears.
• Unlimited revisions or “ongoing support” with no definition becomes free work.
• Fixed fee with vague scope transfers all risk to you; T&M with no estimate transfers it all to the buyer and stalls approval.
• Pricing in a proposal can form part of a binding offer depending on wording and law; include validity and “subject to MSA” language, and have legal approve new terms.
• Sending the proposal is outward-facing: prepare the document and email draft, but send only after the user confirms.

Output

Proposal (markdown or .docx via docx-documents), SOW draft, a criteria-to-deliverable traceability table, open questions for the buyer, and items requiring internal approval (non-standard terms, discounts, delivery commitments).