A proposal-to-contract handoff turns discovery decisions into a review-ready scope, timeline, and commercial record. When those details remain implicit, kickoff can begin with different assumptions about the work.

The stage starts once intake has produced a qualified lead and ends when a review-ready proposal and contract package exists. Comments, revisions, and approval after the package is sent belong to the Proposal revision and approval workflow.

Fix this stage when clients question what was included after work starts, or when discovery details do not carry into execution.

This workflow organizes operational handoff. It does not supply contract language; use qualified legal guidance when the agreement itself needs review.

What this handoff must achieve

Before proposal review begins, your process should produce:

  • one scope statement ready for client review,
  • a delivery timeline with milestone dates,
  • an acceptance definition for each deliverable,
  • a commercial record (fees, invoicing schedule, payment terms),
  • a change-request rule.

If any of these are missing, proposal review may begin without required context, and onboarding may require the same details to be reconstructed.

Who needs this handoff

  • Solo freelancers selling scoped project work.
  • Consultants who move from discovery calls into custom proposals.
  • Operators who already have qualified leads but still start projects with ambiguity.

If you are still attracting poor-fit work, fix intake first with How to build a client intake and qualification workflow.

Step 1: convert discovery notes into a scope draft

Your scope draft should include:

  • in-scope deliverables,
  • explicit exclusions,
  • required client inputs,
  • milestone structure.

Use plain language. If the scope relies on hidden assumptions, it is not ready for proposal.

Use a reader test: someone who was absent from discovery should be able to identify what is included by reading the draft.

Step 2: align scope to timeline constraints

For each milestone, define:

  • deliverable output,
  • owner,
  • dependency,
  • approval window.

Avoid date promises before confirming client-side dependencies.

If client inputs, approvals, or asset delivery can delay the work, show that dependency explicitly in the timeline and commercial terms.

Step 3: define commercial terms tied to execution

Define the billing events or dates that fit the engagement:

  • deposit or kickoff invoice trigger,
  • milestone-based invoicing events,
  • recurring dates for retainer or scheduled billing, when applicable,
  • payment terms and late-payment policy,
  • scope-change pricing rule.

Use Invoice and payment workflow checklist to standardize this step.

Record whether a workflow transition depends on an invoice being sent, a payment being received, or a delivery event being completed. These are separate conditions.

Step 4: run a pre-signature friction check

Ask these questions:

  1. Can both sides explain what “done” means for each milestone?
  2. Are out-of-scope items explicit?
  3. Is approval ownership clear?
  4. Is there a written path for change requests?
  5. Is each invoice tied to a defined event or date, with any payment condition for starting work made explicit?

If any answer is unclear, revise before signing.

Handoff packet example

At minimum, the internal packet you carry into onboarding should answer:

  • What exactly was sold?
  • What is explicitly excluded?
  • What must the client provide before work can move?
  • Who can approve scope, content, or deliverables?
  • Which event triggers the next invoice?

Step 5: send the package for review and signature

Before the package goes into live client review, make sure it already contains:

  • current scope and exclusions,
  • milestone timeline,
  • stakeholder/approver map,
  • communication cadence assumptions,
  • invoice schedule.

Then move into Proposal revision and approval workflow to control the revision loop and define what counts as final approval.

Step 6: carry the approved package to onboarding

Once the proposal is approved and the agreement signed, pass the same package to onboarding, updated to the approved version.

Then run onboarding with Client onboarding workflow for freelancers and consultants and its Client onboarding checklist for freelancers and consultants.

If the project is likely to evolve after kickoff, define the post-signature rule now with Change request workflow for freelancers and consultants.

Gaps that weaken the handoff

  • Proposal promises are not mirrored in the contract.
  • Exclusions are not documented.
  • Kickoff is scheduled before approval owners are mapped.
  • Payment terms are copied from a template without checking their events, dates, and start conditions against the engagement.

When to keep this stage manual

Keep proposal-to-contract transitions manual until:

  • your scope format is stable,
  • your invoice triggers are consistent,
  • your onboarding checklist follows a stable structure with documented exceptions,
  • exceptions are handled predictably by hand.

If that is not true yet, keep the handoff manual and visible. Use Rule-based workflow steps for solo service businesses after the trigger, result, exception path, and owner are clear.

Continue through review and onboarding

Handoff completion standard

The package is ready to enter client review when:

  • the proposed scope and exclusions match the discovery record,
  • milestone owners are named,
  • invoice triggers are documented,
  • required onboarding inputs and their owners are identified.

If a required item is missing, close the gap before the affected stage begins. After signature, record later changes against the signed baseline.

If the package is ready but client review is still active, continue with Proposal revision and approval workflow. If the proposal is already approved and signed, continue to Client onboarding workflow for freelancers and consultants.