Skip to content
Writing Style Library

Proposal

A document that pitches a specific piece of work or a deal to a client and asks them to say yes.

Proposal

Section titled “Proposal”

A proposal is a document that pitches a specific piece of work or a deal to a prospective client, partner, or funder and asks them to say yes. It lays out the problem, the proposed approach, the scope, the timeline, and the terms - everything the decision-maker needs to approve and sign. A proposal is written to be read by someone who is not in the room: it stands entirely on its own prose, and the reader can treat it as the basis of a potential agreement.

Because it is a standalone document, a proposal must do the work that a presenter does in a live meeting. It earns the reader’s confidence by demonstrating that the writer understands the client’s problem as well as the client does, then presents an approach specific enough to be acted on. A proposal that gestures at solutions without committing to scope, timeline, or price has not actually proposed anything - it is a brochure with a subject line.

The canonical proposal moves through a predictable sequence: executive summary, problem statement, proposed approach, scope and deliverables, timeline, team or credentials, and pricing or terms. Not every proposal uses all sections, but the decision-maker must always be able to answer three questions: What are you going to do? When will it be done? What will it cost? Any proposal that leaves those unanswered is incomplete.

Canonical template

Section titled “Canonical template”
# [Project or Engagement Title]
## Prepared for: [Client Name]
## Prepared by: [Your Name / Organization]
## Date: [Date]


## Executive Summary
[2-4 sentences: the problem, the proposed solution, and the ask. The reader should be able
to approve based on this section alone if they trust you enough.]


## The Problem
[What challenge or need does the client face? State it in the client's own terms, not yours.]


## Proposed Approach
[How will you solve the problem? Name the method and the reasoning. Say why this approach
is right for this specific client, not for this category of problem in general.]


## Scope and Deliverables
[What is included? What is explicitly not included? Ambiguity in scope becomes a dispute
later - be specific.]


## Timeline
[When will each phase or deliverable land? Name milestones, not just a final date.]


## Team and Credentials
[Who will do the work and why are they qualified? Keep this brief unless the client asked
for detail.]


## Investment
[What does it cost? State the fee, the payment structure, and any conditions directly.]


## Next Steps
[What does the client need to do to say yes? Name the action: a signature, a reply by
date, a kickoff call.]

When to use

Section titled “When to use”
  • Responding to a client’s formal or informal request to outline how you would solve a specific problem
  • Initiating new commercial work by defining the scope, timeline, and terms before any work begins
  • Pursuing a grant, contract, or institutional partnership where the funder expects a formal written response
  • Following up a verbal conversation or presentation with a document that supplies the binding detail
  • Establishing a shared baseline that both parties can refer back to when scope questions arise later

When not to use

Section titled “When not to use”
  • When the decision has already been made and the client needs a statement of work or a contract, not a persuasive document
  • When the relationship is informal and both parties prefer to agree by message or conversation rather than a formal document
  • When you are presenting to a live audience and the persuasive arc is better served by a visual slide sequence than by solo prose reading

Pairs well with

Section titled “Pairs well with”

senior-consultant, executive, confident, diplomatic, problem-solution

Often confused with

Section titled “Often confused with”

pitch-deck: A pitch deck is a sequence of presentation slides that tells a persuasive story to win a decision, one idea per slide, built to be presented aloud or skimmed quickly; the speaker carries the thread and the narrative detail. A proposal is a standalone prose document the recipient reads independently and can treat as the basis of an agreement. Where the pitch deck relies on a live presenter to supply the nuance and specifics each slide only gestures at, the proposal carries all of that in its own text - including the scope, timeline, and terms a slide deck deliberately leaves out.

Tells

Section titled “Tells”
  • An executive summary at the top that lets a decision-maker approve without reading the rest
  • A problem section that restates the client’s need in the client’s own terms, not the vendor’s
  • A scope section that explicitly names what is included and what is not
  • A timeline with named milestones or delivery dates, not just a final end date
  • A fee or pricing section that states the number directly and names the payment structure
  • A next-steps or signature section that tells the reader exactly how to say yes
  • Second-person address (“your organization,” “you will receive”) that keeps the reader as the subject

Anti-patterns

Section titled “Anti-patterns”
  • Opening with a capabilities showcase or credential list before addressing the client’s problem - A proposal earns confidence by demonstrating that the writer understood the brief; leading with your own credentials before stating the problem signals you sent a template, not a tailored response.
  • Leaving scope, timeline, or price vague so the proposal appears flexible - A proposal that does not commit to what it will deliver, when, or at what cost has not proposed anything the reader can approve; vagueness forces a follow-up conversation that delays or kills the yes.
  • Submitting a slide deck when the client expects a standalone written document - A pitch deck is a sequence of presentation slides built to be walked through aloud by a speaker, with minimal text per slide, relying on a presenter to carry the detail; a proposal must supply all of that detail in its own prose, including the scope, timeline, and terms a deck deliberately leaves out.
  • Padding the document with boilerplate sections not relevant to this client’s specific request - A proposal is a persuasive document, not a template audit; irrelevant sections signal the writer did not engage with the brief, and every filler page dilutes the reader’s confidence.

Failure modes

Section titled “Failure modes”
  • Over-persuades into pure sales copy - the document reads as a letter of enthusiasm with vivid vision but no binding specificity, so the reader cannot actually approve anything concrete - Anchor every persuasive claim in a concrete deliverable, date, or cost; if the scope and price sections are still vague after a revision pass, the proposal has not proposed anything.
  • Over-specifies into a contract draft - the document fills with exclusions, liability caveats, and legal-dense clauses until the reader routes it to counsel rather than signing it - Keep contractual language proportional to the deal size; reserve exhaustive legal terms for the formal agreement that follows approval, and let the proposal remain a persuasive, readable document.

Instruction

Section titled “Instruction”
Write as a formal business proposal. The document must stand alone: the reader will not have
a presenter to explain it, and they may treat it as the basis of an agreement. Structure
the content in this sequence: Executive Summary (2-4 sentences covering the problem, the
solution, and the ask), The Problem (the client's need in the client's own terms), Proposed
Approach (the method and why it fits this specific client), Scope and Deliverables (what is
included and what is explicitly not included), Timeline (milestones with dates, not just a
completion date), Team and Credentials (brief unless the client asked for depth), Investment
(state the fee and payment structure directly), and Next Steps (what the reader must do to
say yes). Write in second person to keep the reader as the subject. Do not leave scope,
timeline, or price vague - a proposal that cannot be approved is not a proposal. Do not
open with a capabilities showcase; start by demonstrating you understood the problem.

Template

Section titled “Template”

See the Proposal template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Senior Consultant, Executive, Confident, Diplomatic, Problem-Solution

Avoid with

Section titled “Avoid with”

Confessional, Reverent, Playful

Often confused with

Section titled “Often confused with”

Pitch Deck

Examples

Section titled “Examples”

Async-First Standup Adoption

Section titled “Async-First Standup Adoption”

Prepared for: Director of Engineering

Section titled “Prepared for: Director of Engineering”

Prepared by: Engineering Manager

Section titled “Prepared by: Engineering Manager”

Date: Q2 (before trial launch)

Section titled “Date: Q2 (before trial launch)”

Executive Summary

Section titled “Executive Summary”

The engineering team’s daily synchronous standup puts India-based engineers in a 9:30pm meeting, produces roughly 4 minutes of actionable signal in 14 minutes of call time, and leaves no searchable record of anything shared. This proposal recommends replacing it with a daily async update posted to #team-standup by 10am local time, paired with a weekly 60-minute Thursday working session at 8am Pacific (8:30pm IST) for discussions that require real-time exchange. Your approval is the single action needed to begin a 30-day trial with a structured retro at Day 30.

The Problem

Section titled “The Problem”

Your 11-engineer team now spans four timezones: US Pacific, US Eastern, UK, and India. The daily standup runs at 9am Pacific. For India-based engineers, that is 9:30pm local time.

Three costs are accumulating.

Participation gap. Q1 attendance data shows India-based engineers averaged 3.2 standup appearances per week out of 5, compared to 4.6 for US-based engineers. The gap is not disengagement; it is the clock.

Signal loss with no durable record. The standup averages 14 minutes. Roughly 4.2 minutes of that meeting changes someone’s behavior - a blocker raised, a dependency flagged, a context shared. The remaining time is status that required no response from anyone. None of it is searchable afterward. Three incidents in the past quarter involved an engineer spending more than an hour on a problem that had already been solved and discussed in a prior standup. There was no record to check.

Unequal burden. A 14-minute meeting looks equal on paper. A 9:30pm mandatory call is not. The current format asks one group on the team to make a categorically different sacrifice than everyone else.

Proposed Approach

Section titled “Proposed Approach”

Replace the synchronous standup with a daily async update posted to #team-standup. Each engineer posts by 10am their local time using a three-field template:

  • Shipped: what completed in the last 24 hours
  • In progress: current focus
  • Blocked or at risk: anything that needs attention, with an @mention of the person who can resolve it

The on-call engineer - on the existing rotation - reads the channel by 9am Pacific and responds to any @mentions within 30 minutes during business hours. This replaces the meeting-facilitation duty the on-call already carries; no new role is created.

The synchronous slot is not simply removed. It converts into a 60-minute Thursday working session at 8am Pacific (8:30pm IST) for discussion that genuinely requires real-time exchange: architectural questions, live debugging, or issues a Slack thread cannot carry. If there is nothing to discuss by Wednesday at 5pm Pacific, the session is canceled.

This approach fits your team specifically because your four-timezone spread makes any single fixed synchronous slot inequitable, and your existing Slack infrastructure handles the async format without additional tooling. Geekbot and similar tools were evaluated and rejected: they add cost and tooling complexity that a pinned Slack template covers at no cost.

Scope and Deliverables

Section titled “Scope and Deliverables”

Included:

  • Process documentation pinned to #team-standup
  • A three-field Slack message template, accessible via pinned message and a /standup Slack shortcut
  • On-call reading responsibility added to the existing on-call rotation charter
  • A 30-day trial period with weekly participation tracking
  • A structured Day 30 retro document covering quantitative data (post completion rate, blocker resolution time) and qualitative feedback collected in 1:1s with each engineer

Not included:

  • Any paid tooling or new Slack applications
  • Changes to sprint ceremonies, retrospectives, or project tracking in Jira
  • Any standup-adjacent process outside the daily update and the Thursday replacement session

Timeline

Section titled “Timeline”
  • Week 0 (3 business days from your approval): Engineering manager finalizes process documentation, pins the Slack template, updates the on-call charter, and briefs the team at a single 30-minute sync call. Trial start date announced.
  • Day 1: Trial begins. All engineers post their first async update. On-call engineer begins daily channel triage.
  • Week 2: First pulse check on participation rate and median blocker resolution time against the Q1 sync baseline.
  • Day 30: Full retro. Quantitative data reviewed, qualitative interviews complete, and a go/no-go decision made to adopt permanently, modify, or revert to the synchronous format.

Team and Credentials

Section titled “Team and Credentials”

The engineering manager owns trial setup, process documentation, and the Day 30 retro. On-call channel-reading responsibility rotates across all 11 engineers on the existing schedule. No external facilitation or new headcount is required.

Investment

Section titled “Investment”

There is no cash cost. The investment is time.

  • 3 days of engineering manager time to document and set up the process before launch
  • A daily 5-10 minute channel-reading task for the on-call engineer (replacing the meeting-facilitation task already on that rotation)
  • Each engineer’s time posting an async update: estimated 3-5 minutes per day

Net weekly effect: replacing a 14-minute meeting with a 5-minute update recovers roughly 9 minutes per engineer per day, approximately 16 person-hours per week across the team. The Thursday working session spends back 11 of those. Net recovery: 5 person-hours per week, assuming the Thursday session runs in full.

Next Steps

Section titled “Next Steps”

Reply to this proposal to approve the 30-day trial. Once you confirm, the engineering manager will complete setup within three business days and announce the trial start date to the team. If you have conditions or modifications, name them in your reply and this proposal will be revised before launch.