How to Write a Proposal for a Six-Figure Consulting Project

Write a six-figure proposal the buyer can approve and delivery can use#

A six-figure consulting proposal must make the business case, explain the work and give the buyer a clear decision. Connect the expected value to defined deliverables, fees, responsibilities and payment terms so a reviewer can assess both the opportunity and the commitment.

Separate the desired business outcome from what you can contractually deliver. A strategy project may aim to improve revenue, but its deliverable could be a tested operating plan rather than a guaranteed revenue increase. State the evidence, assumptions and measurement approach behind the business case.

1. Confirm decisions. Write down the agreed outcome, what is excluded, who approves, and which dependencies sit with the client.
2. Convert decisions into controls. Define terms, document completion signals, and make ownership explicit so the draft is reviewable by someone outside the sales thread.
3. Define change handling. State how new requests are documented and approved before they are treated as committed work.
4. Run a pre-send gate. Check that scope, approvals, commercial language, and change handling are consistent end to end. For enterprise clients, pair this with A Freelancer's Guide to Negotiating with Enterprise Clients.

If you want a deeper dive, read How to Create a Work-Life Balance as a Freelancer.

What You Need Before You Draft Anything#

Use a working packet of discovery notes, scope, commercial assumptions and review contacts. A proposal can confirm prior alignment or develop a solution for comparison; label unresolved decisions so the draft does not imply agreement that has not happened.

Before you start: Keep all deal artifacts in one shared folder. If something is unknown, log it as an assumption instead of guessing.

1. Collect the core packet. Gather discovery notes, working SOW, MSA/NDA/DPA (if in scope), and payment terms in one place.

If objective, scope or costs are uncertain, draft a discovery phase, options or an explicitly provisional estimate. Do not present unresolved assumptions as an approved fixed commitment.

1. Confirm prior alignment where available. Identify agreed points, proposed options and open assumptions; follow the buyer’s RFP process where a prior agreement is unavailable.

2. Assign owners by review lane. Name one owner each for business approval, legal review, and payment setup.

Identify missing review owners and ask the sponsor to help route the draft. You can circulate an assumption-labelled proposal while procurement roles are being confirmed; resolve material approval authority before commitment.

1. Log applicable cross-border dependencies. Record actual payer/provider checks, tax-form routing and VAT assumptions with owner and due date; ordinary clients do not automatically carry bank-style AML obligations.

If someone asks you to proceed with unresolved terms, hold a clear boundary: move only on approved tasks, document open assumptions in writing, and route any new work through the Change Order path.

This pairs well with How to Write a Scope of Work for an AI Development Project.

Is This a Sales Document or a Confirmation Document#

Use the proposal to explain the solution and support the buyer’s decision as well as record prior alignment. State which points are agreed, proposed or conditional. A persuasive business case and specific delivery terms can coexist.

For an RFP, follow the requested structure and submission rules, including evaluation criteria and deadlines. You may need to propose a solution before any verbal alignment; make the assumptions and clarification requests explicit.

Use this confirmation sequence before you send:

1. Restate agreed outcomes. Open with the client problem and the outcomes already accepted in conversation.

Check: your sponsor can confirm it matches prior discussions.

1. Map each outcome to an execution artifact. For each promised result, track: decision, owner, where it lives, and verification status. In practice, that often means outcome in the proposal, delivery detail in the SOW, and broader terms in the MSA (if one exists).

Check: if an outcome has no owner or document location, it is not ready for approval.

1. Define acceptance and approval in plain language. State what will be delivered, who reviews it, what counts as complete, and who signs off. Keep the wording specific so scope is not left open.

2. Run a reviewer checkpoint. Read the draft as if the reviewer missed every call. If a new request adds work without owner, timing, or fees, rewrite it before circulation; if it changes scope, capture it as a separate scope update before signature.

How Do You Qualify a Six-Figure Opportunity Before Writing#

Qualify first. If qualification is weak, your proposal becomes a patch for unresolved sales, legal, and delivery risk instead of a clean approval document.

Use discovery to assess fit and risks before making firm commitments. Request the evidence needed for the proposal stage; you do not need every final procurement artifact before writing a useful draft.

Map the real decision path#

Do not infer authority from titles or enthusiasm. Ask who owns the outcome, who approves spend, who signs, who reviews legal or procurement, and who can block timing.

Output: a decision-owner map. Verification point: you can name sponsor, economic buyer, final signer, and likely reviewers without guessing.

Translate buying criteria into document artifacts#

Map each buying criterion to a document location before drafting: proposal, SOW, acceptance criteria, SLA, MSA, or related terms. If a criterion has no owner or document location, it is not ready for approval.

Use a Definition of Terms section when language could be interpreted multiple ways. That keeps milestone, deliverable, and cost language consistent across reviewers.

Output: a buying-criteria-to-artifact map.

Validate implementation readiness before promising timing#

Ask for the real workflow: kickoff participants, required client inputs, draft reviewers, tooling/access dependencies, and external blockers. You are checking for ownerless steps, not just missing detail.

If costs are part of the deal, confirm how they are classified and whether pre-contract start-up costs are excluded from in-contract expenditures.

Output: implementation readiness notes. Verification point: you can explain the first two weeks of delivery, including client responsibilities, without inventing steps.

Log payment and compliance dependencies#

Do not stop at net terms. Confirm milestone approval flow, completion confirmation, invoice prerequisites, and whether onboarding must finish before invoicing. If relevant, keep placeholders visible until confirmed: [KYC/AML onboarding owner], [tax form requirement], [bank verification], [procurement review time].

Also confirm whether the payment structure includes any special approval model, for example performance-linked terms, risk-sharing, or other non-standard payout logic. If you cannot describe the approval path for cash movement, the fee section is not ready.

Output: a payment dependency log. Verification point: you can state when invoices are sent, who approves them, and what pauses payment.

Before committing to a start date and final payment schedule, confirm signer authority, review responsibilities and the billing path. While details remain open, use a provisional proposal that identifies assumptions and owners rather than blocking all drafting.

If that still stays unclear, tighten the buying path first with A Freelancer's Guide to Negotiating with Enterprise Clients.

How Do You Structure and Price the Proposal So It Is Easy to Approve#

Make the proposal persuasive and easy to review. In each section, make it obvious what the buyer is approving, what procurement is checking, and what delivery will execute.

Step 1. Sequence the document in decision order. Put situation, objectives, scope boundaries, delivery approach, fees, terms, and next steps near the front. Write the opening in the client's language so reviewers can explain the background and objectives after one pass.

Step 2. Match pricing to certainty, then state the rationale. Do not just present a number; explain why the fee model fits the current level of certainty. If scope is still evolving, say that directly instead of forcing fixed-scope language that later creates redlines, kickoff friction, or invoice disputes.

Step 3. Define the actual billing triggers. They may be an agreed advance, delivery, acceptance or elapsed billing period. Where acceptance triggers an invoice, state tests, review time and the authorized reviewer. Finance and delivery should identify the same event; not every invoice must wait for acceptance.

Step 4. Keep a practical document boundary map. Use this as an alignment tool, not a legal standard, and route legal specifics through the client's review flow.

• SOW: scope, deliverables, assumptions, timeline, acceptance, pricing
• MSA: relationship terms, liability, IP, dispute path, general commercial terms
• NDA: confidentiality terms if not already covered
• DPA: data handling terms when personal or regulated data is involved

Step 5. Define change control. For genuine additions, record request, impact, approver and any price/schedule update before doing the affected extra work. Continue unchanged work where practical. Correcting work already owed under the scope is not automatically a chargeable change.

Work through a $120,000 proposal#

Hypothetical brief: an enterprise wants to reduce manual finance work across three business units. A discovery sample finds 600 reconciliation hours a month. The proposal aims to reduce the verified workload by 150 hours a month, valued internally at $60 an hour: $9,000 monthly capacity, or $108,000 over 12 months after implementation. That is an assumption-based benefit estimate, not guaranteed cash savings or proof that the $120,000 fee pays for itself in year one.

The total is $120,000 before any applicable tax or agreed reimbursable costs. Exclude rollout to the other two units and ongoing support unless priced separately. Client dependencies include access, sample data, a subject-matter reviewer and five-business-day feedback. Agree how defects, rejected tests and delayed reviews are handled; do not assume silence means acceptance unless a valid clause says so. A requested fourth unit is an addition; fixing an included test failure is a correction.

For outcome-based drafting, FAR 37.602 is a useful public-procurement example of measurable results and constraints. Its federal procurement requirements are not a mandatory template for private consulting. Use the example to check that your own deliverable can be assessed rather than merely described as “transformation”.

Which Terms Protect You From Scope and Payment Risk#

Use written terms that control scope, define payment events, and separate ownership before work starts. Verbal alignment is fragile, especially if your original contact leaves and a new team questions the agreement again.

Step 1. Run this pre-signature scope checklist. Confirm these are written in the draft: in-scope work, out-of-scope work, assumption owner, and acceptance owner for each deliverable. If any item is missing, scope can drift and you can end up delivering far more than the original fee covers.

Step 2. Agree how extra work is authorized. Require the specified written approval and impact assessment before committing to genuine additions. A dated email from an authorized person may be valid if the contract allows it; the document’s title alone does not decide authorization.

Step 3. Draft payment and delay terms. Specify when invoices issue, when they fall due and which review or notice steps apply. For client-caused delays, describe the schedule assessment and any agreed relief rather than promising every date moves automatically by the same interval. Define any work-pause and restart rights with notice and cure conditions; review enforceability for the deal.

Step 4. Define rights and dispute handling. Identify final deliverables, retained methods and third-party materials, the assignment/licence scope and its actual trigger. Payment alone does not universally transfer IP. Review unfamiliar forum terms, broad indemnities and background-IP transfers before committing.

Use the SOW generator to turn the agreed scope and acceptance tests into a reviewable draft.

How Do You Make Enterprise and Cross-Border Delivery Operationally Safe#

You make cross-border delivery safer by defining each control before kickoff: owner, trigger, evidence artifact, and escalation path. Use your appendix as an approval tool, not a place to solve every legal or tax question.

Map jurisdiction-scoped assumptions into the delivery plan#

Define assumptions by jurisdiction before work starts, then map each one to a delivery dependency. For each country or entity, state what you are assuming, who provides the input, and what project activity depends on that input.

Use a simple checkpoint: each assumption has one owner, one jurisdiction, and one linked dependency in the plan. If onboarding, entity verification, or related approvals can delay access, workshops, or invoicing, reflect that in the schedule before kickoff.

Route tax documents operationally, not interpretively#

For US payer reporting where applicable, W-9 generally documents a US person’s TIN and certification; W-8BEN concerns foreign individuals and W-8BEN-E foreign entities, subject to the actual form instructions and exceptions. Confirm the appropriate form with payer finance, use its secure collection route and record receipt. A W-8 is not a general exemption from all taxes or withholding.

Record which setup items genuinely affect invoicing or payment, the responsible person and the date needed. A pending item does not automatically prohibit every proposal, signature or delivery step. Resolve the actual payment dependency before it causes a hold.

Create one source of truth for milestones, approvals, and invoice events#

Set one shared log as the system of record for milestone status, acceptance, invoice events, and payment holds. That gives delivery, procurement, and finance the same audit trail when reviewers change.

Track event date, deliverable, reviewer or approver role, and next action for every key event. When approvals stall, log when the block started, why it is blocked, and who owns the exception, then carry those notes into handoff.

Fence off advisor-dependent topics before they slip into scope#

Keep personal FEIE and FBAR analysis separate unless tax advice is explicitly within the engagement. FEIE depends on eligible foreign earned income, foreign tax home and a qualifying residence or physical-presence route; 330 full foreign-country days is the physical-presence test, not a universal requirement for every claimant. It does not remove self-employment tax. A consultant’s personal tax result does not establish the client’s vendor onboarding obligations.

You can document that these topics require advisor handling, and note that FinCEN publishes FBAR due-date resources and extension notices, without turning personal tax determinations into project deliverables. If procurement tries to pull those determinations into scope, reset the boundary and move that discussion to A Freelancer's Guide to Negotiating with Enterprise Clients.

Need the full breakdown? Read How to Write a Freelance Proposal That Wins Clients.

Common Proposal Failures and How to Recover Fast#

Recover fast by stopping new ambiguity first. Diagnose the pattern, contain it in writing, and confirm one concrete fix before the next milestone moves.

If a draft relies on unconfirmed promises, return to discovery or label those points as proposed assumptions. An RFP response may still be persuasive and provisional; it does not require a verbal yes before submission.

Rebuild the draft around measurable delivery controls#

Non-operational drafts and responsibility disputes usually show up together. Broad scope creates unclear direction, and unclear direction turns into avoidable rework.

Use one control pattern across every deliverable: measurable outcome, explicit acceptance criteria, named approver, and written change approval before added work starts. Then verify with three checks: what is delivered, who accepts it, and who can approve scope changes.

Contain legal and payment issues in one operating record#

When redlines and billing questions spread across inboxes, recovery slows because no one is working from the same record. Keep one shared issue tracker, with one accountable owner, one current status, and one next action per item.

Then keep approval and invoice state connected in that same view. If approvals or payments break, use the contract's existing pause/restart path instead of continuing work on assumptions.

Narrow cross-border recovery to owned assumptions#

Do not turn delivery into a tax or reporting interpretation exercise. First lock operational ownership: which jurisdiction is in scope, which input is needed, who provides it, and where advisor escalation begins.

For higher-complexity relationships, make controls more specific, not more abstract, across the full relationship life cycle. Recovery is complete only when each jurisdiction or entity assumption has a clear owner, reporting path, and advisor boundary.

For a step-by-step walkthrough, see How to Write a Creative Brief for a Design Project.

Build Your Proposal Operating System and Run It Every Time#

Run this like a gate-based system: qualify first, then draft, then move only when the next owner is clear.

1. Step 1. Qualify before firm commitments.

Confirm the sponsor and likely decision path early. Where roles are unresolved, draft proposed options with explicit assumptions and a route to finalize them. Establish authority and binding terms before kickoff rather than requiring a verbal yes before every proposal.

Verification point: the buyer can explain the problem, proposed solution, fee basis, decision required and remaining assumptions. Watch for a draft that describes approval as complete when it is still pending.

1. Step 2. Build an approval-ready structure.

Write in decision order so each reviewer can act fast: outcomes, scope, acceptance criteria, price, terms, next steps. Then make handoffs explicit: sponsor confirms business case, approver confirms authority and budget, payment owner confirms billing setup and prerequisites.

Verification point: A new reviewer can quickly explain what they are approving, what triggers payment, and what remains an assumption.

1. Step 3. Pair each risk term with a trigger and response.

Define the relevant notice, review, cure, payment or escalation action for each material risk. A liability cap does not itself require a work pause. Hold genuine extra work pending the agreed change approval, and follow the actual billing trigger if acceptance is disputed; collect undisputed amounts under existing terms.

Verification point: Every risk term has a trigger, an owner, and a pause or escalation action. Use life-cycle logic: controls should cover the full relationship, and the rigor should match the deal's risk and complexity.

1. Step 4. Scope compliance and tax items before signature.

Include KYC, KYB, AML, W-9, W-8BEN, or VAT assumptions only when they actually apply to payer setup, jurisdiction, or onboarding. Assign document ownership, review ownership, and clear boundaries on what you are not advising on.

Verification point: The proposal packet or appendix shows owner, requester, status, and any dependency that blocks kickoff or billing.

1. Step 5. Run a failure drill before you send.

Test the stall scenario before signature: if approval or payment stops, how will you see it, who reconciles it, what gets logged, and what recovery action starts first.

Verification point: You can state status visibility, reconciliation owner, event log fields, pause points, escalation path, and first recovery action without guessing.

• Qualification proof logged: sponsor, approver path, payment owner
• Proposal ordered for approval: outcomes, scope, acceptance, price, terms, next steps
• Risk terms mapped to trigger, owner, and escalation response
• Cross-border/compliance/tax items scoped only where applicable, with ownership set before signature
• Failure drill completed: status visibility, reconciliation workflow, event logging, and recovery actions for stalled approvals or payments

Use the checklist to identify material kickoff conditions and open actions. Resolve the conditions that actually affect the next stage rather than treating every future milestone or optional artifact as a universal prerequisite.

Related reading: How to Write a Master Service Agreement for Long-Term Client Engagements.