Proposal

A proposal should make a buying decision easier, not make a service sound bigger.

A useful proposal connects the client's problem, the proposed outcome, the work required, and the commercial terms. It should make clear what is being agreed, what is not being agreed, how the work will progress, and what happens next.

Current proposal guidance consistently emphasizes a clear problem statement, a tailored solution, defined deliverables, timeline, pricing, assumptions, client responsibilities, and next steps. The value of a template is the repeatable structure, not copying another company's document.

Do not start with your company description.

First answer:

• What problem did the prospect actually ask you to solve?
• What evidence do you have that the problem exists?
• What outcome would make the project useful?
• Who is deciding?
• What is the expected scope?
• What timing matters?
• What assumptions could change the scope or price?
• What is explicitly outside the engagement?

If those answers are unclear, the proposal is premature. A proposal cannot repair an unclear discovery conversation.

Prepared for: [Client / organisation] Prepared by: [Your name / company] Date: [Date] Valid until: [Date] Decision maker: [Name / role] Project: [Specific project name]

Client problem: [Describe the business problem in the client's language.]

Proposed outcome: [Describe what will be different when the agreed work is complete.]

Engagement: [Project / retainer / advisory / other]

Estimated timeline: [Start date] to [end date]

Investment: [Amount / pricing structure]

Immediate next step: [Signature / kickoff / deposit / discovery workshop / other]

Write this section as evidence of listening.

[Client] is currently [situation]. The immediate challenge is [problem]. This matters because [business consequence]. The work therefore needs to [required change].

Keep this factual. Do not introduce assumptions that were never discussed.

Objective: [One sentence describing the job to be done.]

Approach: [Explain the method at a useful level.]

Purpose: [Why this work exists]

Activities:

• [Activity]
• [Activity]
• [Activity]

Deliverables:

• [Deliverable]
• [Deliverable]

Timing: [Dates / phase]

Purpose: [Why this work exists]

Activities:

• [Activity]
• [Activity]

Deliverables:

• [Deliverable]
• [Deliverable]

Timing: [Dates / phase]

Repeat only for genuinely separate workstreams. A proposal should not become a catalogue of every service the company can sell.

For every major deliverable, define what completion means.

A vague deliverable creates room for both sides to hold different definitions of done.

Connect phases to actual outputs rather than promising only a broad completion date.

Client will provide:

• [Access / information]
• [Approvals]
• [Assets]
• [Stakeholder availability]
• [Other dependency]

Approval expectation: [Example: feedback consolidated through one nominated stakeholder within X business days.]

If a dependency is not supplied on time, state how the timeline changes.

Out of scope:

• [Item]
• [Item]
• [Item]

Change requests: Work outside the agreed scope will be assessed separately and may require a written change order, revised timeline, and additional fee.

A clear boundary is a shared definition of the engagement.

Option A: [Name] [Amount] [What is included]

Option B: [Name] [Amount] [What is included]

Option C: [Name] [Amount] [What is included]

Use multiple options only when they represent genuinely different scopes or levels of commitment. Do not manufacture packages merely to create a pricing ladder.

• [X]% on acceptance
• [X]% at [milestone]
• [X]% on completion

The price assumes:

• [Assumption]
• [Assumption]
• [Assumption]

If an assumption changes materially, the scope, price, or timeline may need to be revised.

Do not promise outcomes you cannot control.

Project outputs: [What you will produce.]

Client-side indicators: [What the client may monitor.]

Success definition: [The measurable or observable condition that indicates the agreed work has been completed successfully.]

Distinguish delivered work from hoped-for commercial results.

Use this section when the project depends on approvals, third-party systems, customer data, regulatory review, or other external conditions.

Relevant capability: [Specific capability relevant to this problem.]

Relevant evidence: [Verified project example, credential, result, methodology, or other evidence you are entitled to present.]

Working principle: [One or two sentences about how you approach the work.]

Do not manufacture case studies, credentials, client outcomes, testimonials, or expertise. If evidence is unavailable, leave it out.

Start: [Date / trigger]

Duration: [Duration]

Payment terms: [Terms]

Revision / approval terms: [Terms]

Cancellation / termination: [Terms]

Intellectual property: [Terms]

Confidentiality: [Terms]

Third-party costs: [Included / excluded / pass-through]

Legal agreement: [Master service agreement / statement of work / proposal acceptance / other]

This template is a commercial planning aid, not legal advice. The applicable contract should govern the legal relationship.

1. Confirm the scope.
2. Confirm the commercial terms.
3. Sign the applicable agreement or proposal acceptance.
4. Complete the initial payment, if required.
5. Confirm the kickoff date.

Client: [Name / organisation]

Authorised by: __________________ **Role:** ________________ **Date:** __________________

Supplier: [Name / organisation]

Authorised by: __________________ **Role:** ________________ **Date:** __________________

Before sending, ask:

• Is the client's actual problem clear immediately?
• Can someone identify exactly what will be delivered?
• Is every major deliverable tied to a completion condition?
• Is the timeline realistic?
• Are client responsibilities visible?
• Is out-of-scope work explicit?
• Can the price be reconciled to the scope?
• Are pricing assumptions stated?
• Are promised outcomes within the supplier's control?
• Are decision makers and next steps clear?
• Have unsupported claims, fake testimonials, invented credentials, and vague superlatives been removed?
• Can the recipient understand the proposal without a live explanation?

If the recipient still needs you to explain what they are buying, the proposal is not finished.

Use this template alongside relevant SOE Knowledge Objects for discovery, follow-up planning, role design, delivery planning, and client decision-making. A proposal should represent the conclusion of a real discovery process, not substitute for one.

This SOE template is an original editorial synthesis based primarily on current HubSpot proposal guidance covering problem definition, tailored solutions, deliverables, timelines, pricing, assumptions, client responsibilities and next steps. It also cross-checks common proposal components against HubSpot business and marketing proposal templates.

The template deliberately avoids reproducing another publisher's structure or distinctive wording. It is designed as a practical decision document that can be adapted to a real engagement.

This is a commercial planning template, not legal, tax or financial advice.

Related reading: \2 · \2

1. Fill it with one real situation rather than hypothetical inputs.
2. Record the evidence behind each important field.
3. Make the smallest decision the tool is designed to support.
4. Set a review date and update the tool when the evidence changes.

Good output: another person should be able to understand what was decided, why, what remains uncertain, and what happens next without needing a separate founder explanation.