Sales to Project Handoff Checklist for Small Teams
Turn a won deal into a clear delivery brief with confirmed promises, scope, acceptance criteria, owners, and unresolved questions. Use a practical checklist to make the handoff explicit.
On this page
A customer agrees to buy. Sales marks the deal as won. The project owner receives a proposal, a few messages, and a date that already feels close.
The gap between those events is where promises get lost. A launch date becomes an unconditional deadline. A demonstration becomes an included feature. A person who joined the sales call becomes the assumed approver.
A useful handoff gives delivery a reliable starting point. It carries the customer agreement, the reasoning behind important promises, and the questions that still need an answer. It also ends with the project owner explicitly accepting responsibility for the next step.
Start with the customer agreement
Prepare the handoff from the current agreement and its supporting communications. A proposal summary helps people navigate, but it should not replace the document or message that establishes a commitment.
Follow a hypothetical service visit through customer booking, staffing, equipment, delivery, and follow up. See how named owners keep changes consistent across the work.
·7 min read
Operations Insights
Record which version the customer accepted and where it lives. If a later message changes an important condition, include that reference and explain how the team confirmed it. Do not silently combine an old proposal with a newer price or deadline.
Distinguish three kinds of statements:
Scrollable article table
Statement
Example
Handoff treatment
Confirmed commitment
One training session is included
Put it in the delivery brief and reference the agreement
Conditional commitment
Launch depends on customer data arriving by the agreed cutoff
Keep the condition beside the launch date
Unresolved expectation
The customer asked about a second training session
Assign someone to clarify it before treating it as included
Sales should explain the context behind unusual promises. The delivery owner should be able to understand them without replaying every conversation. An unresolved expectation remains visible until someone confirms, declines, or revises it.
Define scope and acceptance together
A deliverable tells the team what to produce. Acceptance tells both sides how they will recognize that the deliverable is ready.
For each material deliverable, record the included work, its boundaries, the review method, and the person responsible for the customer decision. “Set up reporting” leaves too much interpretation. “Configure the three agreed reports using the supplied sample data, then review them with the operations lead” gives the project owner something to plan.
Acceptance does not need to become a large specification. It does need to identify observable evidence. That might be an approved design, a tested import, a completed training session, or a delivery checklist reviewed by a named customer contact.
Keep exclusions equally concrete. “Anything else is extra” offers little guidance. “Historical data cleanup is outside this phase” helps the team recognize a new request when it arrives.
If the agreement leaves acceptance unclear, mark that as a question with an owner. A handoff should expose ambiguity rather than create new terms on the customer's behalf.
Separate delivery ownership from customer authority
Small teams often have overlapping roles. The founder may sell and deliver the work. A project lead may also manage the account. Even then, write down who owns each decision.
The minimum useful ownership map includes:
Sales owner: explains the agreement and resolves questions about sales promises.
Project owner: accepts the brief, builds the delivery plan, and coordinates execution.
Customer working contact: supplies information and answers routine delivery questions.
Customer decision maker: can accept deliverables or approve material changes within their authority.
Commercial owner: handles questions about price, terms, or additional commitments.
One person can hold several roles. The point is to identify authority before a decision becomes urgent. A friendly contact who provides feedback may not be authorized to change the budget.
Also name the next customer communication owner. Otherwise sales assumes delivery will introduce itself while delivery assumes sales is arranging the kickoff.
Carry dates and financial context carefully
Record whether each date is an agreed milestone, an internal target, or an estimate awaiting confirmation. Put dependencies next to the dates they affect. Customer access, source files, staffing, and review availability can all determine whether a timeline is workable.
Give the project owner enough commercial context to plan: the agreed amount and currency, payment conditions, any deposit requirement, and the authoritative location of billing or payment records.
A won deal describes a sales outcome. It does not prove that an invoice has been issued or that money has arrived. Likewise, a project budget is a plan, not a payment record. The distinction matters when a team needs to spend before it expects to collect, as explained in Why Profitable Projects Can Still Leave a Small Business Short on Cash.
If work depends on a deposit, identify who verifies receipt and what evidence they will use. Do not make the project owner infer payment from the deal stage.
Make unknowns part of the brief
An empty field can look like a settled question. Use explicit unknowns instead.
For every unresolved item, capture the question, its delivery impact, one owner, and a decision deadline. Then say whether work can proceed while the answer is pending.
For example, a missing logo file may not block requirements work. Unconfirmed access to the customer's source system may block an import test. Treating both as generic “pending items” hides the difference.
Avoid assigning every uncertainty to the project owner by default. Sales may be best placed to clarify a promised service. A technical lead may need to inspect a data sample. The customer may need to name an approver.
A hypothetical handoff example
Consider a small team selling a four-week customer onboarding project. The accepted proposal includes one data import and one training session. Sales discussed launching on the last Friday of the month, conditional on receiving usable customer data by the first Monday.
Before the handoff, the delivery lead sees only “four-week onboarding” and the Friday date. During the review, the team discovers that the customer expects historical data cleanup and has not named the training participants.
The completed brief makes three things explicit. Cleanup is excluded from the accepted scope. The launch date depends on receiving a usable file. Sales owns confirming whether the customer wants a separately scoped cleanup service; the project owner owns reviewing a sample file before confirming the import plan.
The project owner accepts the handoff with those questions recorded. The team can prepare training material immediately, while the import schedule remains conditional. This is a hypothetical process example, not a customer result or a promise of a particular delivery speed.
Copy this handoff template
Keep the brief short enough that the receiving owner will actually use it. Link to detailed material instead of reproducing the entire sales history.
Scrollable article table
Field
What to record
Customer and deal
Customer identity, deal reference, and working contact
Agreement
Accepted version, date, and source location
Customer outcome
The operational result the customer expects
Included work
Deliverables and relevant quantity or phase limits
Exclusions
Work discussed but outside the accepted scope
Acceptance
Evidence, review method, and authorized decision maker
Dates
Milestones, conditions, and customer dependencies
Commercial context
Amount, currency, payment conditions, and record location
Owners
Sales, delivery, customer decisions, and commercial questions
Unknowns
Question, impact, owner, deadline, and effect on starting work
Handoff acceptance
Receiving owner, date, conditions, and next action
Use this checklist when sales and delivery review the brief:
The accepted agreement is identifiable and accessible.
Promises are confirmed, conditional, or explicitly unresolved.
Deliverables and exclusions are understandable without the sales call.
Acceptance evidence and customer authority are clear.
Dates retain their dependencies.
Payment expectations are separate from confirmed receipts.
Every material unknown has an owner and a deadline.
The project owner records acceptance or specific gaps to resolve.
The next customer contact has an owner and a date.
Keep the handoff close to the project
Figena supports customer-linked project records with dates and notes. Its deal workflow also supports explicitly creating a project from a won deal or linking a deal to a project, subject to workspace, customer, and permission checks.
Use the project record to keep the operational brief and its source references close to delivery. Review the resulting project plan before relying on it; creating or linking a record does not by itself establish that the customer promises have been understood or accepted by the delivery owner.
The receiving owner's acceptance can be a dated project note or a controlled team record. It is a team practice, not a claim that Figena provides a dedicated handoff approval workflow.
After kickoff, carry unresolved handoff questions into the regular operating review. The 30 Minute Weekly Operating Review offers a practical way to revisit project exceptions and next actions. Resolve questions at their source, then update the brief so the next person inherits the current understanding.
Separate decisions, actions, and open questions in meeting notes. Use a practical handoff template to confirm owners, define completion, manage dependencies, and review the result.
Decide which inquiries deserve the next sales step using evidence of need, fit, timing, and decision process. With a decision matrix, two hypothetical examples, and a reusable lead review.
