Use this worksheet when the main problem is not the stage itself, but the boundary between stages.
This is a support asset, not a lifecycle guide. Its job is to help you define what must be true before work is allowed to move forward, who owns the next move, what evidence should exist, and what should block transition if the boundary is not actually ready.
Use this when the transition rule itself is weak. If the boundary is already clear and the real problem is one missing client-side item, move narrower to Client Input Dependency Worksheet for Solo Operators.
Do not use this worksheet to invent a lifecycle stage from scratch. Use it only after the stage workflow already exists and the open issue is boundary quality between two known stages.
What this page is for
Use this page to define one exact handoff boundary after the stage logic already exists. It is for making “ready to move forward” visible enough to verify instead of debate.
What this page is not for
Do not use this worksheet to map the full lifecycle, create a brand-new process, or fix a general project-management problem. It only clarifies one transition point at a time.
When to use this worksheet
Use it when:
- kickoff keeps starting before the project is truly ready,
- milestones reach review or billing with fuzzy evidence,
- final delivery feels complete but offboarding still stalls,
- the team uses phrases like “basically ready” or “close enough to move” too often.
If you still need the broader lifecycle method first, use Freelance Client Workflow System: Inquiry to Final Payment or the specific stage workflow before using this asset.
Safest next step after this worksheet
If the boundary is now clear but the project is still blocked, move narrower to Client Input Dependency Worksheet for Solo Operators or Escalation and Pause-State Worksheet for Solo Operators. If the boundary itself still feels conceptually weak, go back to the relevant workflow page rather than adding more worksheet detail.
What this worksheet does not decide
This worksheet should not decide:
- the full workflow design for the whole client lifecycle,
- tool-stack structure,
- pricing or scope strategy,
- whether a change belongs in pre-signature revision or post-signature scope control.
Those decisions belong on the workflow, comparison, and blueprint pages. This asset only documents the transition rule between one stage and the next.
How to use it
- Pick one exact stage transition, not the whole project lifecycle.
- Define the readiness rule in operational language rather than emotional language.
- Name one owner for the next move after the transition.
- Write what evidence must exist before the boundary is considered passed.
Practical rule: if the stage can still move forward even when nobody can show the evidence, the boundary is still weak.
What this worksheet assumes you already know
- which two stages the boundary sits between,
- what the upstream stage is supposed to produce,
- who should own the first move after the boundary passes,
- what should count as valid approval.
If that stage logic is still fuzzy, return to the workflow page before using this asset.
Handoff boundary worksheet
| Stage transition | Required inputs | Approval / signoff needed | Next action owner | Blocked / waiting condition | Evidence required before transition |
|---|---|---|---|---|---|
| Proposal approved -> onboarding ready | signed scope, kickoff dependencies, stakeholder contacts | approval owner confirms final version | consultant or operator | waiting on access, deposit, or final stakeholder input | approved proposal record, kickoff-ready project record |
| Delivery complete -> invoice ready | milestone output, QA pass, acceptance point | client acceptance or documented milestone trigger | operator billing owner | review pending, rework open, dependency unresolved | deliverable link, QA note, visible milestone status |
| Invoice closed -> offboarding ready | payment received or financial close rule met | billing state confirmed | operator or account owner | invoice overdue, procurement delay, hidden extra request | paid status, closeout record draft, next-step state |
Stage transition being documented
Write the transition in this format:
- from which stage,
- into which stage,
- what the transition event actually is,
- what should become true immediately after it happens.
Avoid vague labels like “project starts” or “wrap up begins.” Use a visible transition such as:
- proposal approved -> onboarding ready,
- first milestone active -> delivery underway,
- delivery complete -> invoice ready,
- invoice closed -> offboarding ready.
Required inputs before handoff
List the exact items that must exist before the transition can happen.
Examples:
- signed agreement or approved proposal version,
- required client assets or access,
- milestone output or review package,
- invoice trigger event,
- final files or handoff materials.
Inputs should be specific enough that a second person could verify them without guessing what “mostly ready” means.
If readiness depends on several reviewers feeding one decision path, define that routing separately with Approval and Feedback Routing Worksheet for Multi-Stakeholder Review.
If readiness depends on missing client-side materials, answers, or access, define those items separately with Client Input Dependency Worksheet for Solo Operators.
If the boundary is already blocked beyond an acceptable waiting window, define the pause or escalation rule separately with Escalation and Pause-State Worksheet for Solo Operators.
If the work has already crossed that line and the original transition plan is no longer trustworthy, reset it explicitly with Scope Reset and Recovery Worksheet for Solo Operators.
Required approvals / signoff
Define:
- who has authority to approve the transition,
- what message or action counts as approval,
- what does not count as approval.
Examples:
- named approval owner accepts the final proposal version,
- milestone review result is logged explicitly,
- finance state is confirmed before closeout messaging starts.
Silence, assumption, or emotional confidence should not be treated as approval unless your process explicitly says so.
Owner of next action
For the chosen transition, write:
- who owns the first action after the boundary,
- what that action is,
- when it should happen,
- what they need in hand to do it cleanly.
This matters because many lifecycle stalls happen after a transition is “approved” but no one owns the immediate next move.
Blocked / waiting conditions
Define the conditions that should stop the transition.
Examples:
- proposal approved but deposit still missing,
- delivery ready but client review question not explicit,
- invoice sent but payment still open,
- offboarding planned but signoff still unclear.
If a block exists, the stage should remain visible as blocked rather than quietly moving forward.
Evidence or artifacts required before transition
Document what proof should exist before the boundary is passed.
Examples:
- approved proposal version,
- kickoff-ready project record,
- milestone QA record,
- client approval note,
- sent invoice with due date,
- closeout record with final files linked.
If the artifact only exists in chat memory, the boundary is probably not stable enough yet.
What to do if the boundary is not met
- Hold the current stage visibly instead of pretending the next one already started.
- Name the missing requirement directly.
- Name one owner for resolving the block.
- Set the next review point instead of letting the issue drift into silence.
Example: do not start onboarding because “the client said yes in principle” if approved scope, access, or payment conditions are still incomplete.
Suggested stage-boundary examples
Proposal approved -> onboarding ready
Best when the real risk is kickoff starting from an unstable agreement.
Use with:
- Proposal Revision and Approval Workflow for Freelancers and Solo Service Businesses
- Client Onboarding Workflow for Freelancers and Consultants
Delivery complete -> invoice ready
Best when work is being sent, but billing still depends on memory or soft signals.
Use with:
- Milestone Delivery Workflow for Solo Service Businesses
- Invoice and Payment Workflow Setup for Freelancers and Consultants
Invoice closed -> offboarding ready
Best when closeout timing is vague and testimonial or archive steps start too early.
Use with:
- Invoice and Payment Workflow Setup for Freelancers and Consultants
- Client Offboarding Workflow for Freelancers and Solo Service Businesses
Warning signs of weak handoff design
- the next stage is active before its inputs are fully visible,
- approval exists only as a vague feeling or chat impression,
- no one can name who owns the very next action,
- blocked states are hidden inside ordinary status updates,
- billing or closeout triggers happen because it feels “about time.”
What to do after completing the worksheet
- If the boundary you documented is proposal review moving into kickoff, continue to Client Onboarding Workflow for Freelancers and Consultants.
- If the boundary is milestone completion moving into billing, continue to Invoice and Payment Workflow Setup for Freelancers and Consultants.
- If the boundary is payment closure moving into closeout, continue to Client Offboarding Workflow for Freelancers and Solo Service Businesses.
- If the bigger problem is still the stage design itself, go back to the relevant workflow page instead of adding more worksheet detail.
Completion standard
This worksheet is complete when:
- one exact transition is named,
- readiness conditions are visible and testable,
- required approvals and evidence are explicit,
- the next action owner is clear,
- blocked conditions are strong enough to stop premature transition.
