How to Write a Proposal

A business proposal is a document that recommends a specific solution to a prospective client and explains what will be delivered, why it matters, how the engagement will work, what it will cost, and how the client can approve it.

A strong proposal does more than describe services.

It helps the buyer answer:

• Do you understand our situation?
• Is this the right solution?
• What exactly will we receive?
• What will our team need to do?
• What could prevent success?
• Why should we choose you?
• What will it cost?
• How do we approve it?

The proposal should reduce uncertainty rather than add more material for the buyer to interpret.

What is a business proposal?

A business proposal is a written commercial recommendation prepared for a prospective client.

It typically includes:

• The client’s current situation.
• The desired result.
• The recommended solution.
• The work included.
• The delivery process.
• The timeline.
• The price.
• The responsibilities of each party.
• Evidence supporting the provider.
• The approval process.

A proposal may be created for:

• A consulting engagement.
• A creative project.
• A software implementation.
• A marketing campaign.
• A coaching program.
• A research assignment.
• A recurring service.
• A strategic partnership.
• A training program.
• A custom product or solution.

The document is usually written after the solopreneur has learned enough about the client to recommend a suitable engagement.

Proposal, quote, estimate, scope of work, and contract

These documents serve different purposes.

A proposal may contain a quote, estimate, and scope of work.

It may also include acceptance terms and a signature section. Whether an accepted proposal creates a binding agreement depends on its wording, the parties’ actions, and the applicable law.

For higher-value, higher-risk, or more complex work, use a separate contract or have the complete agreement reviewed by an appropriately qualified legal professional.

When should you write a proposal?

Write a proposal when the opportunity is sufficiently qualified to justify a specific recommendation.

Before writing, the solopreneur should normally understand:

• The problem.
• The desired result.
• The decision deadline.
• The client’s current approach.
• The consequences of leaving the problem unresolved.
• The people involved in the decision.
• The client’s ability to implement the solution.
• The likely scope.
• The commercial constraints.
• The next step after acceptance.

The proposal should confirm and organize the buying conversation—not replace it.

When a proposal is unnecessary

A proposal may be unnecessary when:

• The product has a public fixed price.
• The service is highly standardized.
• The buyer only needs a quote.
• The customer can purchase directly.
• A simple order form contains all necessary information.
• The transaction is small and low-risk.
• The work is already covered by an existing agreement.
• The customer is purchasing an unchanged repeat service.

A ten-page proposal for a $200 standardized service increases sales cost without helping the customer decide.

Use the smallest document that makes the transaction clear and safe.

Do not write proposals for unqualified leads

Proposal creation can become a form of unpaid speculative work.

Warning signs include:

• The client refuses to discuss the problem.
• There is no identified decision-maker.
• The buyer is collecting prices without explaining the requirement.
• No budget or commercial range has been discussed.
• The deadline is undefined.
• The client expects substantial strategy before committing.
• Essential technical information is unavailable.
• The buyer cannot explain how a provider will be selected.
• The proposed work is not a current priority.
• The client asks for several unrelated options without context.

Before preparing a detailed proposal, confirm that:

1. A real problem exists.
2. The client intends to act.
3. The solopreneur is a plausible provider.
4. The likely investment is commercially realistic.
5. A decision process exists.
6. The client has agreed to review the proposal.

When significant analysis is required before the engagement can be defined, sell a paid discovery phase rather than providing the analysis free inside a proposal.

A proposal should help a group make a decision

Many business proposals are reviewed by people who did not attend the original sales conversation.

The document may be forwarded to:

• A founder.
• A department leader.
• Finance.
• Procurement.
• Legal.
• Information security.
• Operations.
• An internal implementation team.

Current buyer research found that B2B buying groups can contain five to 16 people across as many as four functions. Gartner also found that 74% of the surveyed buying teams experienced unhealthy conflict and that groups reaching consensus were 2.5 times more likely to report a high-quality deal.

The proposal must therefore make sense to someone who was not present when the opportunity was discussed.

It should explain:

• Why the project exists.
• Which organizational objective it supports.
• Why the recommended approach was selected.
• What each stakeholder needs to know.
• What the customer must commit.
• How risk will be controlled.
• What decision is being requested.

Write for the buying group rather than only for the person who first contacted you.

What to do before writing a proposal

Confirm the problem

Describe the problem in concrete terms.

Weak description:

The client needs help with marketing.

Stronger description:

The company generates sufficient qualified traffic, but its main product pages convert below the historical average. The team lacks a consistent process for identifying, implementing, and measuring conversion improvements.

The problem should explain why the engagement exists.

Do not enlarge the problem to make the proposal more dramatic. Use information the client has confirmed.

Establish the desired outcome

Clarify what should be different after the engagement.

Possible outcomes include:

• A decision has been made.
• A system has been implemented.
• A defined asset has been delivered.
• A process has been documented.
• An operational error has been corrected.
• A team can perform a task independently.
• A measured business indicator has improved.
• A significant risk has been reduced.

Separate the provider’s deliverable from the client’s wider ambition.

For example:

• Provider deliverable: implement the agreed analytics measurement plan.
• Client ambition: make better advertising decisions and increase profitable growth.

The provider can commit to the first. The second may depend on actions and conditions outside the engagement.

Identify the decision criteria

Ask how the client will compare proposals.

Possible criteria include:

• Relevant experience.
• Price.
• Delivery date.
• Technical approach.
• Industry knowledge.
• Level of implementation.
• Security.
• Availability.
• Ongoing support.
• Team involvement.
• Commercial risk.
• Compatibility with existing systems.

Do not assume that price is the primary criterion simply because the buyer requested it.

The proposal should make the most important decision criteria easy to evaluate.

Identify everyone involved

Ask:

• Who recommends the provider?
• Who approves the budget?
• Who signs the agreement?
• Who reviews legal or security terms?
• Who supplies information?
• Who implements the recommendations?
• Who will judge whether the project succeeded?

Different stakeholders may have different concerns.

A proposal should support a shared decision rather than appeal to one stakeholder at the expense of the others.

Gartner found that content tailored to the buying group’s shared situation had a positive effect on consensus, while content focused too narrowly on individual interests could increase internal conflict. Buyer relevance should therefore focus on the organization’s common objective.

Agree on the decision process

Before sending the document, ask:

• Who will review it?
• When will they review it?
• Will it be discussed in a meeting?
• Does procurement need a particular format?
• Are legal terms required at the same time?
• When is the decision expected?
• What happens if the proposal is accepted?
• What happens if changes are requested?

A proposal sent without a planned review often becomes another unread attachment.

The structure of a winning proposal

A practical service proposal can contain the following sections:

1. Cover page.
2. Executive summary.
3. Current situation.
4. Objectives and success criteria.
5. Recommended solution.
6. Scope and deliverables.
7. Delivery process.
8. Client responsibilities and assumptions.
9. Timeline and milestones.
10. Investment.
11. Evidence and relevant experience.
12. Terms, acceptance, and next steps.

Not every proposal requires every section.

The structure should reflect the complexity and risk of the decision.

Proposify’s 2026 analysis covered 742,137 documents sent through its platform. Winning proposals averaged 11 pages, compared with 13 pages for losing proposals, while the average winning document contained seven sections. The platform-specific proposal benchmark does not establish a universal ideal length, but it supports removing unnecessary material rather than treating length as proof of effort.

Cover page

The cover page identifies the document immediately.

Include:

• Proposal title.
• Client name.
• Provider name.
• Date.
• Proposal reference number where useful.
• Validity date.
• Confidentiality notice where appropriate.

Use a title connected to the client’s objective.

Weak title:

Marketing Proposal

Stronger title:

Proposal to Rebuild the Customer Acquisition Reporting System

The cover does not need to contain a long introduction or promotional slogan.

Executive summary

The executive summary is the client’s shortest path to understanding the recommendation.

It should explain:

1. The current situation.
2. The desired change.
3. The proposed engagement.
4. Why the approach is appropriate.
5. The investment and next decision.

Write it for an executive who reads only this section before deciding whether the proposal deserves further review.

Executive summary formula

A useful structure is:

Current situation: [What is happening and why it matters.]
Desired result: [What the client wants to change.]
Recommendation: [What you propose doing.]
Reason: [Why this approach fits the situation.]
Decision: [What the client needs to approve.]

Executive summary example

Acme currently relies on several disconnected reporting systems, causing duplicated work and inconsistent monthly performance figures. The leadership team needs one dependable reporting process before allocating next year’s acquisition budget.

I recommend a six-week engagement to define the measurement requirements, consolidate the agreed data sources, implement the reporting dashboard, test the outputs, and train the internal team.

The engagement is priced at $18,000 and can begin on September 14. Approval by August 28 will reserve the proposed delivery window.

The executive summary should not begin with the provider’s history.

The buyer first needs to recognize their situation.

Current situation

This section demonstrates that the provider understands the client.

Include only information relevant to the recommendation:

• Existing process.
• Current difficulty.
• Available evidence.
• Operational consequences.
• Previous attempts.
• Constraints.
• Urgency.
• Dependencies.

Write the section in neutral, factual language.

Avoid blaming the client or exaggerating failure.

Example:

Product, advertising, and sales data are currently reviewed in separate tools. Monthly reports require manual reconciliation and frequently produce different totals. As a result, budget decisions are delayed and the team spends time resolving data questions instead of interpreting performance.

Send the draft description to the buyer before finalizing the proposal when accuracy is especially important.

Objectives and success criteria

Objectives describe what the engagement is intended to accomplish.

Success criteria explain how completion or progress will be evaluated.

Examples include:

• Deliver a validated measurement specification.
• Migrate the agreed data without critical loss.
• Launch the new website by the contractual deadline.
• Train five named employees.
• Reduce the monthly reporting process from five working days to one.
• Complete the agreed security tests.
• Obtain formal approval of the brand system.

Use metrics only when they can be measured credibly.

Avoid promising commercial outcomes that depend mainly on the client, market, or other providers.

Output, outcome, and impact

These terms can help distinguish levels of responsibility.

The solopreneur may control the output, influence the outcome, and contribute to the impact.

The proposal should not present all three as guaranteed deliverables.

Recommended solution

Explain what you recommend and why.

This section should answer:

• What will be done?
• In what order?
• Why is this approach suitable?
• Which alternative approaches were rejected?
• Which part of the problem will remain outside the engagement?

Keep the explanation client-facing.

Do not fill the proposal with technical detail merely to demonstrate expertise.

Include technical detail when the buyer needs it to evaluate:

• Feasibility.
• Risk.
• Compatibility.
• Security.
• Maintainability.
• Internal workload.
• Regulatory requirements.

Scope of work

The scope defines the work included in the price.

Organize it into phases or workstreams.

Example:

Phase 1: Discovery

• Review the current analytics setup.
• Interview three named stakeholders.
• Confirm reporting requirements.
• Document data sources and ownership.
• Identify implementation risks.

Phase 2: Implementation

• Configure the agreed events.
• Connect the specified data sources.
• Build the approved dashboard.
• Test the measurement outputs.
• Correct implementation errors.

Phase 3: Handoff

• Deliver system documentation.
• Conduct one team training session.
• Provide a recorded walkthrough.
• Complete the final acceptance review.

Use verbs that describe observable work.

Avoid vague scope statements such as:

• Marketing support.
• Strategic help.
• Ongoing optimization.
• Reasonable revisions.
• Necessary research.
• General consulting.

Every vague commitment can produce a different expectation.

Deliverables

Deliverables are the items, systems, decisions, or sessions the client will receive.

Specify:

• Quantity.
• Format.
• Included components.
• Delivery method.
• Review process.
• Applicable limits.
• Ownership or access where relevant.

Example:

The table helps the buyer understand what completion looks like.

Exclusions

State what is not included when a reasonable buyer might assume otherwise.

Possible exclusions include:

• Copywriting.
• Development outside named systems.
• Paid software.
• Media spending.
• Translation.
• Legal review.
• Data cleanup beyond an agreed limit.
• Travel.
• Ongoing maintenance.
• Additional stakeholder workshops.
• Work requested after acceptance.

Exclusions should clarify the boundary, not create an intimidating catalogue of everything the provider refuses to do.

Client responsibilities

A proposal should not describe only what the provider will do.

The client may need to:

• Supply system access.
• Provide accurate source information.
• Appoint a decision-maker.
• Consolidate stakeholder feedback.
• Review work within defined periods.
• Obtain internal legal approval.
• Pay third-party costs.
• Provide technical resources.
• Attend required sessions.
• Implement recommendations outside the provider’s scope.

Example:

Acme will provide access to the named systems before the project begins and will return consolidated feedback within three working days of each review. Delays in access or approval will move subsequent project dates by the corresponding period.

Client responsibilities prevent the proposal from implying that the provider controls every dependency.

Assumptions

Assumptions are conditions used to define the recommendation and price.

Examples include:

• Existing data is reasonably complete.
• The project involves one website.
• No custom integration is required.
• Feedback will come from one authorized decision-maker.
• The client will provide approved copy.
• Work will be completed remotely.
• The current platform will remain in use.
• The project does not involve regulated personal data.

An assumption differs from an exclusion.

• Assumption: the client’s existing platform will remain in use.
• Exclusion: migration to another platform is not included.

State what happens when a material assumption proves incorrect. The engagement may require a revised plan, timeline, or price.

Delivery process

The buyer should understand what working together will feel like.

Explain:

• How the engagement begins.
• How communication happens.
• How often updates are provided.
• When the client reviews work.
• How decisions are recorded.
• How issues are escalated.
• How completion is approved.

Example:

1. The client signs the agreement and pays the initial invoice.
2. The provider sends the onboarding request.
3. The kickoff meeting confirms responsibilities and dates.
4. Work is delivered according to the milestone schedule.
5. The client submits consolidated feedback through the project workspace.
6. The provider completes approved revisions.
7. Both parties complete the acceptance review.
8. Final materials are transferred after the remaining payment.

A clear process reduces perceived implementation risk.

Timeline and milestones

A proposal timeline should show meaningful stages rather than a list of every internal task.

Include:

• Planned start date.
• Main phases.
• Review periods.
• Client approval deadlines.
• Delivery date.
• Dependencies.
• Conditions that can move the schedule.

Example:

Use “target” dates when the schedule depends on information that has not yet been received.

Do not promise an unconditional final date when essential client actions remain outside your control.

Investment

The investment section states what the client will pay and when.

Include:

• Total fee.
• Currency.
• Applicable taxes.
• Payment schedule.
• Deposit or initial payment.
• Optional additions.
• Third-party expenses.
• Proposal validity.
• Conditions that can change the price.

Example:

Project fee: $18,000
Payment schedule: $7,200 on acceptance, $5,400 after approval of the measurement plan, and $5,400 before final handoff.
Third-party costs: Software subscriptions and paid data services are not included and require written client approval.
Proposal validity: This proposal remains valid until August 28.

Use the pricing model already selected for the engagement.

The proposal should communicate the result and commercial choice rather than reproduce every internal pricing calculation.

Should pricing appear near the beginning or end?

For a qualified custom engagement, pricing normally appears after the buyer understands:

• The problem.
• The recommendation.
• The work included.
• The delivery process.

This order provides context without attempting to hide the fee.

Do not force buyers through pages of generic promotional material before revealing a price they specifically requested.

A short proposal may include the investment on the first or second page. A more complex proposal may place it after the solution and scope.

The correct position is the one that lets the buyer interpret the price accurately.

Should a proposal include several options?

Include options when the client has more than one valid way to solve the problem.

For example:

Options should differ through meaningful variables such as:

• Scope.
• Responsibility.
• Speed.
• Support.
• Risk reduction.
• Implementation depth.

Do not include several options because the provider is unwilling to recommend one.

State the recommended option and explain why it fits.

Relevant experience and proof

Evidence should reduce uncertainty about this engagement.

Useful proof includes:

• A similar client result.
• A relevant work sample.
• A concise case study.
• Direct experience with the client’s system.
• Professional credentials.
• A reference.
• A testimonial addressing the same concern.
• A demonstrated methodology.

A short case study can follow this structure:

1. Client situation.
2. Work completed.
3. Result.
4. Relevance to the proposed engagement.

Example:

A software company had inconsistent acquisition reporting across three advertising platforms. I created a shared measurement specification, rebuilt the core tracking, and delivered an executive dashboard. The team reduced its monthly reporting process from four days to one and adopted one agreed set of metric definitions.

Do not include every previous client or unrelated achievement.

The question is not whether the provider has done impressive work. It is whether the evidence makes this recommendation more credible.

About the provider

Keep the biography relevant to the decision.

Include:

• Relevant specialization.
• Applicable experience.
• Delivery role.
• Credentials where important.
• Who will perform the work.
• Any contractors or partners involved.

Avoid a long company history that delays the client’s understanding of their own project.

For a one-person business, say clearly that the solopreneur will lead and deliver the work.

Do not imitate a large agency through vague plural language when the client is hiring one specialist.

Risks and dependencies

A sophisticated proposal acknowledges the conditions that could affect the engagement.

Possible risks include:

• Incomplete data.
• Unavailable stakeholders.
• Third-party platform changes.
• Technical limitations.
• Delayed approvals.
• Regulatory review.
• Contractor dependencies.
• Uncertain integration requirements.

For each significant risk, explain:

• What may happen.
• Who controls it.
• How it will be reduced.
• What happens if it occurs.

Example:

Risk disclosure does not weaken the proposal. It makes responsibility more credible.

Terms and conditions

The proposal may summarize important commercial terms, such as:

• Payment deadlines.
• Revision limits.
• Project delays.
• Cancellation.
• Intellectual-property treatment.
• Confidentiality.
• Expenses.
• Acceptance.
• Liability limitations.
• Post-delivery support.

Do not hide significant obligations in extremely small text or vague references.

An Adobe-commissioned 2025 survey found that 61% of knowledge workers and 63% of technology leaders had signed workplace contracts without fully understanding the details. It also found that 63% of technology leaders had experienced business delays caused by confusing contractual language. The Adobe survey covered U.S. respondents and contracts more broadly, but it reinforces the importance of clear commercial language.

Use plain language where possible. Legal accuracy and readability are not opposing objectives.

Acceptance and next steps

End with one clear action.

Possible actions include:

• Sign the proposal.
• Select an option.
• Approve the scope.
• Pay the initial invoice.
• Schedule the kickoff.
• Request specified revisions.

Example:

To proceed, select the Implementation option, sign the acceptance section, and pay the initial invoice by August 28. The project will then begin on September 14.

Do not end with:

Let me know what you think.

That transfers the responsibility for inventing the next step to the buyer.

Proposal validity

A proposal should normally have an expiration date.

The validity period protects:

• Pricing.
• Capacity.
• Contractor availability.
• Delivery dates.
• Assumptions.
• Third-party costs.

Example:

This proposal remains valid until August 28. Pricing and delivery availability may be revised after that date.

The deadline should reflect a real commercial constraint.

Do not create false urgency by using an arbitrary expiration that will be extended automatically whenever the client asks.

Write the proposal in the client’s language

Use the terminology the client uses to describe:

• The problem.
• The customer.
• The internal teams.
• The desired result.
• The metrics.
• The systems.
• The deadlines.

Avoid replacing clear client language with fashionable jargon.

Client phrase:

We cannot trust the monthly numbers.

Unnecessarily complicated rewrite:

The organization lacks a unified source of truth across its omnichannel performance ecosystem.

The second sentence sounds more formal but communicates less clearly.

Write about the client more than the provider

Provider-centered writing repeatedly uses:

• We offer.
• We believe.
• We have.
• We use.
• We are passionate about.

Client-centered writing explains:

• Your current process.
• Your required result.
• The proposed solution.
• The decisions your team will make.
• The responsibilities each party will assume.

This does not require avoiding “I” or “we” entirely.

The provider must still state what they will do and why they are qualified.

The client should remain the subject of the business case.

Use definite language

Weak language creates uncertainty:

• We may be able to.
• We hope to.
• We would like to.
• We can potentially consider.
• We believe it might be beneficial.

Use direct language where the commitment is known:

• I will review.
• The project includes.
• Acme will provide.
• The first phase begins.
• The fee is.
• The proposal expires.

Use uncertainty words only when uncertainty is real:

• The project is expected to.
• The result depends on.
• The final date may move if.
• The estimate assumes.

Direct writing does not require pretending uncertain outcomes are guaranteed.

Make the proposal easy to scan

Buyers may read sections in a different order from the one intended.

Use:

• Descriptive headings.
• Short paragraphs.
• Tables.
• Numbered phases.
• Bullets for deliverables.
• Visible prices.
• Highlighted assumptions.
• Consistent labels.
• Adequate spacing.

The 2026 proposal benchmark found that buyers viewed 93% of proposals they eventually signed and 80% of proposals they rejected. This platform data suggests that customers often review more than the pricing page, making clarity across the complete document commercially relevant.

Do not use visual polish to conceal weak scope or ambiguous terms.

Use images only when they explain something

Useful proposal visuals include:

• Product examples.
• Relevant portfolio work.
• A system diagram.
• A process map.
• A proposed design.
• A timeline.
• A before-and-after example.
• A simple financial model.

Decorative stock photography may make the document longer without helping the decision.

Proposify reported that 83% of winning proposals in its 2025 dataset included images. This is an association within proposals created on one platform, not proof that adding generic images causes more deals to close. Proposal data should therefore support useful visual communication rather than decoration.

Check accessibility

A proposal may be reviewed on a phone, laptop, printed page, or assistive technology.

Use:

• Legible text.
• Strong contrast.
• Descriptive headings.
• Simple tables.
• Meaningful link text.
• Alternative text for important images.
• Selectable text rather than screenshots of text.
• A layout that works without color alone.
• A reasonable file size.

Accessibility also improves ordinary readability.

Proposal length

A proposal should be as long as required to make the decision clear and no longer.

A short proposal may be appropriate when:

• The buyer already understands the service.
• The scope is simple.
• Few stakeholders are involved.
• The financial commitment is low.
• A master agreement already exists.

A longer proposal may be appropriate when:

• The engagement is expensive.
• The scope is complex.
• Several teams are involved.
• The project carries technical risk.
• Procurement needs detailed information.
• The work will occur in phases.
• Alternatives must be explained.

Do not measure proposal quality by page count.

The strongest test is whether each section helps the buyer:

• Understand.
• Compare.
• Approve.
• Implement.
• Control risk.

Proposal template

A reusable proposal template can contain the following structure:

Cover

• Proposal title.
• Client.
• Provider.
• Date.
• Validity.

Executive summary

• Current situation.
• Desired outcome.
• Recommendation.
• Investment.
• Approval step.

Situation

• Current process.
• Problem.
• Consequences.
• Constraints.

Objectives

• Intended changes.
• Success criteria.

Solution

• Recommended approach.
• Reasoning.
• Relevant alternatives.

Scope

• Phases.
• Activities.
• Deliverables.
• Exclusions.

Working relationship

• Provider responsibilities.
• Client responsibilities.
• Communication.
• Feedback.
• Assumptions.

Schedule

• Start.
• Milestones.
• Review periods.
• Completion.

Investment

• Fee.
• Options.
• Payment schedule.
• Expenses.
• Taxes.
• Validity.

Evidence

• Relevant case study.
• Work sample.
• Credentials.
• References.

Acceptance

• Terms.
• Signature.
• Initial payment.
• Next step.

The template should standardize the process without producing a generic proposal.

What should be customized?

At minimum, customize:

• Proposal title.
• Executive summary.
• Current situation.
• Objectives.
• Recommended approach.
• Scope.
• Assumptions.
• Timeline.
• Price.
• Relevant evidence.
• Next step.

Elements that may remain standardized include:

• Provider biography.
• General methodology.
• Payment instructions.
• Standard legal terms.
• Brand design.
• Common process explanations.

Review every standard section before sending it.

A copied proposal containing another client’s name is an avoidable trust failure.

Proposal software

Proposal software can help with:

• Templates.
• Content libraries.
• Pricing tables.
• Electronic signatures.
• Version history.
• Analytics.
• Automated reminders.
• Customer input forms.
• Payment collection.
• CRM integration.

Software is most useful when it reduces administrative friction without making the proposal feel automated or impersonal.

Proposify reported that proposals containing electronic signatures had a 15% higher close rate and closed 60% faster within its dataset. The figures are observational and specific to documents sent through its platform, but they support removing unnecessary signature friction after the buyer has decided. Platform data provides the underlying benchmark.

A simple PDF, email, and separate electronic agreement may still be sufficient for a low-volume solopreneur.

The tool should fit the sales process rather than dictate it.

Proposal and contract workflow

A practical workflow is:

1. Qualify the opportunity.
2. Conduct discovery.
3. Confirm the recommended engagement verbally.
4. Draft the proposal.
5. Review the proposal with the client.
6. Revise agreed commercial details.
7. Obtain approval.
8. Execute the contract.
9. Collect the required payment.
10. Begin onboarding.

The proposal and contract may be combined when the engagement is simple and the terms are appropriate.

For more complex engagements, separating them can make each document clearer:

• Proposal: business case, recommendation, scope, price, and choice.
• Contract: legal rights, obligations, remedies, and risk allocation.

Do not begin material work because the client said the proposal “looks good.” Complete the agreed acceptance process.

Review the proposal before sending it

Check the document from three perspectives.

Commercial review

• Does the solution match the stated problem?
• Is the price correct?
• Is the recommendation clear?
• Is the proposal still financially viable?
• Are options meaningfully different?
• Is the next step obvious?

Delivery review

• Can the work be completed as described?
• Are the deliverables measurable?
• Are dependencies visible?
• Is the timeline credible?
• Are responsibilities assigned?
• Are exclusions sufficient?
• Are internal resources available?

Buyer review

• Can someone outside the sales call understand the document?
• Does it answer the likely objections?
• Is the complete cost visible?
• Can stakeholders find the sections relevant to them?
• Is the proposal easy to approve?
• Does it avoid unexplained jargon?

Then check names, dates, amounts, links, calculations, and formatting.

How to send a proposal

Do not send only an attachment with:

Please see the proposal attached.

Use a short message that restores context and confirms the review process.

Example:

Hi Alex,

Attached is the proposal for consolidating Acme’s acquisition reporting.

It reflects the scope we discussed: measurement planning, implementation across the agreed systems, dashboard delivery, testing, documentation, and team training.

The recommended engagement is priced at $18,000 and can begin on September 14.

As agreed, let’s review it together on Thursday at 10:00 a.m. I will answer questions and confirm whether any revisions are needed before approval.

The sending email does not need to repeat the entire proposal.

Present the proposal live when possible

For a meaningful custom engagement, schedule a review meeting before sending the document.

During the review:

1. Restate the client’s objective.
2. Confirm the recommendation.
3. Walk through the scope.
4. Explain responsibilities and assumptions.
5. Present the price.
6. Answer questions.
7. Confirm the decision process.
8. Agree on the next step.

Do not read every sentence aloud.

Use the proposal as a shared decision document.

A live review lets the provider identify:

• Misunderstood scope.
• Hidden stakeholders.
• New requirements.
• Approval concerns.
• Price objections.
• Missing evidence.
• Procurement requirements.

Do not surprise the buyer with the price

The proposal should not be the first time the client learns the probable investment.

Before writing, discuss:

• A budget range.
• A minimum engagement.
• A likely fee.
• The relevant pricing structure.
• The commercial scale of the solution.

The final amount may change after detailed scoping, but it should remain within a range the client is prepared to consider.

A proposal containing a completely unexpected price is less likely to receive a useful review.

Follow up according to the agreed process

Follow-up should be planned before the proposal is sent.

Weak process:

1. Send proposal.
2. Wait.
3. Send “Just checking in.”
4. Continue waiting.

Stronger process:

1. Send proposal.
2. Review it on the agreed date.
3. Record requested changes.
4. Return the revised version by a defined time.
5. Confirm approval or rejection by the decision deadline.

Follow up with a reason.

Examples include:

• Clarify a decision.
• Answer a stakeholder question.
• Confirm a requested revision.
• Verify the delivery window.
• Provide missing evidence.
• Confirm whether the proposal should remain open.

Do not create daily pressure when the client’s approval process genuinely requires time.

Proposal revisions

A request for a revision does not automatically mean the proposal is failing.

It may indicate that the buyer is:

• Comparing alternatives.
• Seeking internal consensus.
• Adjusting the scope.
• Resolving budget constraints.
• Preparing the agreement for approval.

Proposify’s 2026 dataset associated buyer-requested revisions with higher close rates. One revision round was associated with an 18% increase, while three rounds were associated with a 45% increase. These are correlations within the platform’s documents, not instructions to manufacture negotiation. Proposal research suggests that genuine revision activity can be a sign of buyer engagement.

Track every revision.

Update:

• Version number.
• Date.
• Price.
• Scope.
• Assumptions.
• Timeline.
• Validity.
• Terms affected.

Do not edit only the section the buyer mentioned when the change also affects other parts of the proposal.

When the client asks for a lower price

Do not automatically reduce the fee.

Determine whether the customer needs:

• A smaller scope.
• A different service level.
• Different payment timing.
• A later start.
• A phased engagement.
• Additional justification.
• A different provider.

When granting a concession, record what the business receives in return, such as:

• Reduced scope.
• Earlier payment.
• Flexible delivery.
• Longer commitment.
• Lower support requirements.
• Greater volume.

The revised proposal should clearly show the new commercial exchange.

What to do when a proposal is rejected

Ask for specific feedback.

Useful questions include:

• Which alternative did you choose?
• Which requirement did the proposal fail to meet?
• Was the concern price, scope, risk, timing, or fit?
• Did the decision process change?
• Was the project postponed or cancelled?
• Which section was unclear?
• What would have made the proposal easier to approve?

Do not pressure the client to defend the decision.

Record the loss reason consistently.

A rejected proposal can reveal:

• Weak qualification.
• Incorrect positioning.
• Inadequate proof.
• Uncompetitive delivery.
• Unclear scope.
• Poor price communication.
• An unsuitable customer.
• A project that was never likely to proceed.

What to do when the client goes silent

Silence can mean:

• The project lost priority.
• An internal sponsor left.
• The proposal is waiting for approval.
• The client chose another provider.
• The buyer is avoiding a difficult response.
• A stakeholder objected.
• The proposal did not create enough urgency.
• No decision process existed.

Use a closing message after the planned follow-ups.

Example:

Hi Alex,

I have not received an update since our proposal review. I will close the proposal on Friday and release the September delivery window unless you tell me that the approval process is still active.

The project can be reconsidered later, but pricing and availability may need to be updated.

This creates a clear commercial boundary without false pressure.

Proposal metrics

Proposal win rate

Proposal win rate = accepted proposals ÷ decided proposals

Exclude proposals that are still active.

Track lost and no-decision outcomes separately.

Overall proposal close rate

Close rate = accepted proposals ÷ all closed proposals

Define how expired and withdrawn proposals are classified.

Proposify reported a 34% average close rate for proposals sent through its platform in 2025. The benchmark covers Proposify users rather than the entire service market, so a solopreneur should compare performance primarily with their own qualified historical opportunities. Proposal data provides the platform figure.

Proposal-to-revenue conversion

Accepted proposal value ÷ total proposal value issued

This shows how much proposed revenue becomes contracted revenue.

Average proposal value

Total proposed value ÷ proposals sent

Track this alongside win rate.

A higher average proposal value may justify a lower win rate when qualification and contribution improve.

Average accepted value

Total contracted value ÷ accepted proposals

This reveals the size of won engagements after revisions and discounts.

Price realization

Final contracted price ÷ initial proposed price

A $20,000 proposal signed at $18,000 has 90% price realization.

Time to proposal

Measure the time between completed discovery and sending the proposal.

A long delay can allow:

• Urgency to decline.
• Competitors to respond.
• Internal priorities to change.
• Details to be forgotten.

Speed should come from a strong process and templates, not from skipping discovery.

Time to first view

For tracked proposals:

Time to first view = first client view − proposal sent

Use the result as a signal rather than a conclusion.

A delayed view may reflect scheduling, travel, or an incorrect recipient—not necessarily disinterest.

Time to decision

Time to decision = acceptance or rejection date − proposal sent date

Segment by:

• Deal size.
• Customer type.
• Service.
• Number of stakeholders.
• New or existing client.
• Procurement involvement.

Revision rate

Proposals revised ÷ proposals sent

Track the reason:

• Scope.
• Price.
• Timeline.
• Legal terms.
• Stakeholders.
• Customer responsibilities.

Frequent scope revisions may mean proposals are being written before discovery is complete.

Discount rate

Total concession value ÷ initial proposed value

Include:

• Price reductions.
• Waived fees.
• Free additions.
• Extended support.
• Unpaid implementation.

No-decision rate

No-decision proposals ÷ closed proposals

A high no-decision rate may indicate:

• Weak qualification.
• No urgency.
• Missing authority.
• Undefined approval.
• Proposals sent too early.
• Poor follow-up.

Proposal creation cost

Estimate:

• Owner time.
• Research.
• Design.
• Technical scoping.
• Contractor input.
• Software.
• Revisions.

A low-value service cannot support an expensive proposal process.

Win rate by source and segment

Compare proposal performance by:

• Referral.
• Organic lead.
• Outbound prospect.
• Existing customer.
• Industry.
• Business size.
• Service.
• Price range.
• Decision process.

Overall win rate can hide highly profitable or consistently weak segments.

Use AI to assist proposal writing

AI can help with:

• Organizing discovery notes.
• Identifying missing information.
• Creating a first outline.
• Simplifying language.
• Comparing document versions.
• Checking consistency.
• Summarizing long technical sections.
• Adapting standard content.
• Detecting undefined terms.
• Proofreading.

AI should not be trusted to invent:

• Client facts.
• Financial claims.
• Scope.
• Legal terms.
• Credentials.
• Case-study results.
• Deadlines.
• Technical feasibility.
• References.
• Prices.

Every proposal requires human verification.

Review:

• Names.
• Confidential information.
• Calculations.
• Commitments.
• Dates.
• Deliverables.
• Assumptions.
• Legal language.
• Proof.
• Source accuracy.

Do not enter confidential client information into an AI system unless the use is compatible with the agreement, privacy obligations, security requirements, and tool settings.

Common proposal mistakes

Sending the proposal before qualification

The solopreneur invests time in an opportunity that may have no budget, authority, urgency, or intention to proceed.

Using the proposal to perform free discovery

The document contains enough strategy for the client to implement without hiring the provider.

Beginning with the provider biography

The buyer must read several paragraphs before seeing their own problem.

Copying the sales-call transcript

A proposal should organize the decision, not reproduce every conversation.

Describing services instead of recommending a solution

The document explains everything the provider can do but never says what this client should buy.

Writing vague scope

Terms such as “support,” “optimization,” and “strategy” have no shared operational meaning.

Omitting client responsibilities

The proposal implies that the provider controls access, feedback, implementation, and approval.

Hiding exclusions

The client discovers after acceptance that an assumed component is not included.

Guaranteeing an uncontrollable outcome

The proposal promises revenue, growth, or performance that depends on external conditions.

Adding unnecessary options

The buyer must choose among several variations that solve the same problem.

Refusing to recommend one option

The provider transfers expert judgment back to the client.

Surprising the client with the price

The proposal introduces an investment far outside the commercial range previously discussed.

Making the price difficult to find

The buyer becomes suspicious that the seller is hiding it.

Using unrelated proof

A long client list does not establish the provider’s ability to solve the current problem.

Overdesigning the document

Visual complexity makes the scope, price, and action harder to understand.

Sending an editable document without version control

The parties cannot determine which terms were approved.

Using another client’s name or data

Template errors immediately damage trust and may expose confidential information.

Sending without a review meeting

The proposal is left to explain a complex engagement without the provider present.

Ending without a specific next step

The buyer does not know whether to sign, reply, choose, pay, or schedule a meeting.

Following up with no purpose

Repeated “checking in” messages add pressure without helping the decision.

Leaving the proposal open indefinitely

Pricing, assumptions, and delivery availability become outdated.

Treating proposal acceptance as project authorization

Work begins before the required contract, payment, access, or approval is complete.

Measuring only the number of proposals sent

More proposals can indicate weaker qualification rather than stronger sales performance.

Proposal checklist

Before writing:

• Confirm that the problem is real and current.
• Identify the desired result.
• Confirm commercial fit.
• Identify the decision-makers.
• Understand the selection criteria.
• Agree on the review and decision process.
• Determine whether paid discovery is required.
• Discuss the probable investment.

While writing:

• Use a client-specific title.
• Write the executive summary first.
• Describe the current situation accurately.
• Define objectives and success criteria.
• Recommend one clear solution.
• Break the work into phases.
• List measurable deliverables.
• State exclusions.
• Assign client responsibilities.
• Record material assumptions.
• Show a credible timeline.
• Present the complete investment.
• Include relevant proof.
• State risks and dependencies.
• Define the next step.
• Add a real validity date.

Before sending:

• Review commercial viability.
• Confirm delivery capacity.
• Check calculations.
• Check names and dates.
• Check links.
• Check headings and formatting.
• Remove copied client information.
• Confirm the review meeting.
• Save a controlled final version.
• Record the proposal in the sales system.

After sending:

• Review the proposal with the buyer.
• Record stakeholder questions.
• Track revisions.
• Update connected sections consistently.
• Confirm the decision deadline.
• Close expired proposals.
• Record won, lost, and no-decision outcomes.
• Review proposal performance regularly.

Frequently asked questions

What is a business proposal?

A business proposal is a document recommending a specific solution to a prospective client. It normally explains the client’s situation, intended outcome, scope, deliverables, process, timeline, price, responsibilities, proof, and approval process.

How do you write a proposal?

Begin by confirming the client’s problem, desired result, stakeholders, decision criteria, and commercial fit. Then write an executive summary, recommended solution, scope, deliverables, responsibilities, timeline, investment, proof, terms, and clear next step.

What is the purpose of a proposal?

The purpose is to help a qualified buyer make and approve a commercial decision. It should reduce uncertainty about the solution, provider, work, price, risk, and next step.

What should a proposal include?

A service proposal commonly includes:

• Executive summary.
• Current situation.
• Objectives.
• Recommended solution.
• Scope.
• Deliverables.
• Exclusions.
• Responsibilities.
• Timeline.
• Price.
• Relevant proof.
• Terms.
• Acceptance process.

How long should a proposal be?

It should be long enough to explain the decision clearly and no longer. A simple engagement may need only a few pages, while a complex, expensive, or high-risk project may require more detail.

Should a proposal include pricing?

Yes. A commercial proposal should normally state the price, payment schedule, taxes or expenses, validity period, and conditions that may change the amount.

Should the price appear at the beginning or end?

Place it where the buyer can interpret it correctly. For custom work, it often appears after the problem, solution, and scope. Do not bury it behind unnecessary promotional content.

Should a proposal include several options?

Include several options only when the client has several valid levels of solution. Recommend the option that best fits the situation and explain why.

What is the difference between a proposal and a quote?

A quote primarily states a price for defined work. A proposal also explains the problem, recommendation, scope, value, process, evidence, and decision.

What is the difference between a proposal and a contract?

A proposal presents the business case and commercial recommendation. A contract establishes legally enforceable rights and obligations. A proposal can sometimes become contractual when accepted, depending on its wording and applicable law.

Is a proposal legally binding?

It may be, depending on its language, acceptance method, surrounding communication, and applicable law. Use clear acceptance terms and obtain legal advice for significant engagements.

Should a solopreneur charge for proposals?

Routine proposal preparation is usually treated as a sales cost. Charge for discovery when defining the solution requires substantial analysis, investigation, strategy, technical work, or stakeholder engagement.

Should the proposal be sent before discussing price?

The buyer should normally know the likely investment or commercial range before receiving a detailed proposal. The final amount may depend on detailed scope, but it should not be a complete surprise.

Should a proposal contain a detailed strategy?

Include enough reasoning to make the recommendation credible. Do not provide the complete implementation strategy when creating it is a substantial part of the paid engagement.

What are client responsibilities in a proposal?

They are the actions the customer must complete for delivery to proceed, such as supplying access, providing information, consolidating feedback, approving work, attending sessions, and paying third-party costs.

What are proposal assumptions?

Assumptions are conditions used to define the solution, price, or schedule. Examples include the number of systems involved, expected data quality, stakeholder availability, and the use of an existing platform.

Should proposals expire?

Usually, yes. An expiration date protects the price, capacity, schedule, assumptions, and third-party costs. The deadline should correspond to a real commercial constraint.

How quickly should a proposal be sent?

Send it as soon as the required discovery, internal review, and commercial calculations are complete. Speed matters, but an inaccurate proposal creates more delay through revisions and disputes.

Should a proposal be presented in a meeting?

A live review is useful for custom, complex, or high-value work. It lets the provider explain the recommendation, answer questions, discover hidden stakeholders, and agree on the next step.

How should you follow up after sending a proposal?

Follow the review process agreed before sending it. Each follow-up should help complete a decision by answering a question, confirming a revision, supplying evidence, or verifying the decision date.

What should you do when a client asks for a proposal revision?

Understand the reason, update every affected section, record the new version, and confirm whether the change affects the scope, price, timeline, assumptions, or terms.

What should you do when a client asks for a discount?

Diagnose whether the concern is price, value, scope, cash timing, risk, or comparison. Consider reducing scope or changing commercial conditions before lowering the price for the same work.

What proposal metrics should a solopreneur track?

Track:

• Win rate.
• No-decision rate.
• Average proposal value.
• Accepted value.
• Price realization.
• Time to proposal.
• Time to decision.
• Revision rate.
• Discount rate.
• Proposal creation cost.
• Performance by service and lead source.

Can AI write a business proposal?

AI can help organize notes, outline sections, simplify language, compare versions, and proofread. The solopreneur must verify client facts, prices, commitments, scope, legal terms, calculations, proof, and confidential information.

The central principle

A proposal should make the client’s decision easier.

It should show that the solopreneur understands the situation, recommends an appropriate solution, has defined the work responsibly, can deliver it credibly, and has made the commercial next step clear.

The best proposal is not the document with the most pages, design, or persuasion techniques.

It is the document that turns a qualified conversation into a shared, specific, and approvable agreement.