Project hand-off checklist, from a won quote to delivery.
The moment a sale becomes a project is where context is most often lost. Five sections, each with a tick box: what the client record must contain, what the agreed scope says, who owns delivery, what is excluded and what triggers a new quote, and what the client is told to expect. Twenty-seven rows, an owner per row, and a counterpart on the client side. Copy it as CSV.
The template, filled with an example
The example is one fictional won engagement, a website rebuild for a fictional textile client, with the tick boxes left empty so you can see which rows you are being asked for. Replace the example values and tick as you go.
Illustrative example only. “Sample Client Textiles”, the quotation number, the project code, and every person named are invented for this page, and the GSTIN in the header of the companion invoice template is a placeholder in a valid format rather than a real registration. No delivery time, margin, or performance figure is claimed anywhere.
Hand-over header
- Client
- Sample Client Textiles (example)
- Opportunity won
- OPP-2026-0091
- Quotation accepted
- QTN-2026-0142, dated 01-10-2026
- Project code
- P-2026-014
- Signed by the client
- Sample Authorised Signatory (example), 03-10-2026
- Handed over by
- Sample Sales Executive A (example)
- Accepted by delivery
- Sample Delivery Lead (example), 04-10-2026
- First invoice due
- On the milestone in the accepted quote, not on a new date
- Hand-over date
- 04-10-2026
The client record must contain
| ID | Tick | Item | Owner | Counterpart |
|---|---|---|---|---|
| R1 | ☐ | Company name, registered address, and the contact it should be invoiced to | Sales | Sample Authorised Signatory (example) |
| R2 | ☐ | Client GSTIN, and confirmation that invoices should carry it | Sales | Client finance |
| R3 | ☐ | A billing contact who is allowed to query an invoice, by name — not a role | Sales | Client finance |
| R4 | ☐ | A decision contact for scope questions, separate from the billing contact | Sales | Sample Project Manager (example) |
| R5 | ☐ | Where the client says the conversation happens: WhatsApp, email, or a shared channel | Sales | Client project manager |
| R6 | ☐ | PAN, PO reference if they raise one, and the payment method agreed | Sales | Client finance |
| R7 | ☐ | Access credentials handed over, and who holds each one | Sales | Client IT |
What the agreed scope says
| ID | Tick | Item | Owner | Counterpart |
|---|---|---|---|---|
| S1 | ☐ | The accepted quotation is attached, not described — the version the client approved | Sales | Delivery lead |
| S2 | ☐ | Deliverables are listed as outcomes the client recognises, with the acceptance test for each | Sales | Delivery lead |
| S3 | ☐ | Exclusions are written down explicitly, so a later request is recognisable as one | Sales | Delivery lead |
| S4 | ☐ | Assumptions are listed, with what happens if an assumption turns out to be wrong | Sales | Delivery lead |
| S5 | ☐ | Milestones, dates, and what triggers payment at each one are copied from the quote | Sales | Accounts |
| S6 | ☐ | Anything promised in the call but not in the quote is either written into the scope or deliberately left out | Sales | Delivery lead |
Who owns delivery
| ID | Tick | Item | Owner | Counterpart |
|---|---|---|---|---|
| D1 | ☐ | A named delivery owner — one person, not a team | Delivery lead | Sample Delivery Lead (example) |
| D2 | ☐ | Who does the work, named per role, and who is the client's counterpart on each | Delivery lead | Delivery team |
| D3 | ☐ | Who may approve a small change without asking the client, and the limit | Delivery lead | Sample Owner (example) |
| D4 | ☐ | Who escalates to the client, and the threshold for escalating at all | Delivery lead | Sample Owner (example) |
| D5 | ☐ | Access, files, and folders are in the delivery team's hands, not the salesperson's | Delivery lead | Build team |
What is excluded, and what triggers a new quote
| ID | Tick | Item | Owner | Counterpart |
|---|---|---|---|---|
| X1 | ☐ | New triggers are listed: new page types, new markets, a second language, a new integration | Delivery lead | Agreed with client |
| X2 | ☐ | The change route is stated in writing to the client before work starts, not when the first change arrives | Delivery lead | Client project manager |
| X3 | ☐ | Timeline shifts that are not changes — client delays, third-party delays — are named separately | Delivery lead | Agreed with client |
| X4 | ☐ | What a client gets for a new quote versus what continues under the original one | Delivery lead | Sales |
What the client is told to expect
| ID | Tick | Item | Owner | Counterpart |
|---|---|---|---|---|
| E1 | ☐ | The client is told what the first two weeks look like, including what will not have happened | Delivery lead | Client project manager |
| E2 | ☐ | Who they contact for what, with a response expectation they have been told to expect | Delivery lead | Client project manager |
| E3 | ☐ | What the client must provide, by when, and what happens if it is late | Delivery lead | Client |
| E4 | ☐ | How the first invoice will be raised and what it covers | Delivery lead | Client finance |
| E5 | ☐ | The hand-over conversation has actually happened, not just the email | Delivery lead | Client project manager |
How to read the tick column
- ☐
- Not yet confirmed
- ☑
- Confirmed by the owner of that row, and by the counterpart where the row has one
- N/A
- Does not apply to this engagement — write why in the counterpart column
A row that is not applicable is a decision worth recording. Leaving every box empty is how a hand-over goes from unticked to “it looked complete at the time” without anybody noticing the gap.
Row R2 collects the client’s GSTIN because the invoices will need it. This checklist does not decide when one is required, or what your own invoicing obligations are — confirm that with your chartered accountant.
Project hand-off checklist (CSV — illustrative example data) Field,Value Client,Sample Client Textiles (example) Opportunity won,OPP-2026-0091 Quotation accepted,"QTN-2026-0142, dated 01-10-2026" Project code,P-2026-014 Signed by the client,"Sample Authorised Signatory (example), 03-10-2026" Handed over by,Sample Sales Executive A (example) Accepted by delivery,"Sample Delivery Lead (example), 04-10-2026" First invoice due,"On the milestone in the accepted quote, not on a new date" Hand-over date,04-10-2026 Section,ID,Tick,Item,Owner of the item,Counterpart or source The client record,R1,☐,"Company name, registered address, and the contact it should be invoiced to",Sales,Sample Authorised Signatory (example) The client record,R2,☐,"Client GSTIN, and confirmation that invoices should carry it",Sales,Client finance The client record,R3,☐,"A billing contact who is allowed to query an invoice, by name — not a role",Sales,Client finance The client record,R4,☐,"A decision contact for scope questions, separate from the billing contact",Sales,Sample Project Manager (example) The client record,R5,☐,"Where the client says the conversation happens: WhatsApp, email, or a shared channel",Sales,Client project manager The client record,R6,☐,"PAN, PO reference if they raise one, and the payment method agreed",Sales,Client finance The client record,R7,☐,"Access credentials handed over, and who holds each one",Sales,Client IT Agreed scope,S1,☐,"The accepted quotation is attached, not described — the version the client approved",Sales,Delivery lead Agreed scope,S2,☐,"Deliverables are listed as outcomes the client recognises, with the acceptance test for each",Sales,Delivery lead Agreed scope,S3,☐,"Exclusions are written down explicitly, so a later request is recognisable as one",Sales,Delivery lead Agreed scope,S4,☐,"Assumptions are listed, with what happens if an assumption turns out to be wrong",Sales,Delivery lead Agreed scope,S5,☐,"Milestones, dates, and what triggers payment at each one are copied from the quote",Sales,Accounts Agreed scope,S6,☐,Anything promised in the call but not in the quote is either written into the scope or deliberately left out,Sales,Delivery lead Delivery ownership,D1,☐,"A named delivery owner — one person, not a team",Delivery lead,Sample Delivery Lead (example) Delivery ownership,D2,☐,"Who does the work, named per role, and who is the client's counterpart on each",Delivery lead,Delivery team Delivery ownership,D3,☐,"Who may approve a small change without asking the client, and the limit",Delivery lead,Sample Owner (example) Delivery ownership,D4,☐,"Who escalates to the client, and the threshold for escalating at all",Delivery lead,Sample Owner (example) Delivery ownership,D5,☐,"Access, files, and folders are in the delivery team's hands, not the salesperson's",Delivery lead,Build team Exclusions and new work,X1,☐,"New triggers are listed: new page types, new markets, a second language, a new integration",Delivery lead,Agreed with client Exclusions and new work,X2,☐,"The change route is stated in writing to the client before work starts, not when the first change arrives",Delivery lead,Client project manager Exclusions and new work,X3,☐,"Timeline shifts that are not changes — client delays, third-party delays — are named separately",Delivery lead,Agreed with client Exclusions and new work,X4,☐,What a client gets for a new quote versus what continues under the original one,Delivery lead,Sales What the client is told to expect,E1,☐,"The client is told what the first two weeks look like, including what will not have happened",Delivery lead,Client project manager What the client is told to expect,E2,☐,"Who they contact for what, with a response expectation they have been told to expect",Delivery lead,Client project manager What the client is told to expect,E3,☐,"What the client must provide, by when, and what happens if it is late",Delivery lead,Client What the client is told to expect,E4,☐,How the first invoice will be raised and what it covers,Delivery lead,Client finance What the client is told to expect,E5,☐,"The hand-over conversation has actually happened, not just the email",Delivery lead,Client project manager
The two rows that are most often skipped are S6 — anything promised in the call but not in the quote — and E5, the hand-over conversation itself. They are also the two that decide whether the invoice at the end of the project matches what the client believes they bought.
How to fill it in
Five steps, in the week after the signature rather than on the first day of work.
Start it when the quotation is accepted, not when work begins
The gap between those two moments is when the salesperson's memory is still fresh. The example's hand-over date is the day after the signature, which is late enough to be realistic and early enough to be useful.
Attach the accepted quote rather than summarising it
Row S2 in the example asks for the exact version the client approved. A summary is where scope quietly changes, and nobody notices until the invoice and the conversation disagree.
Get the billing contact and the decision contact as two different people
They usually are two different people, and assuming otherwise is a common reason a hand-off stalls in week one — a scope question sent to an accounts mailbox that nobody forwards.
Send the change route before the first change arrives
Row X2 puts it in writing early, when it is a normal part of how you work together. It is much harder to introduce once a client has already asked for something and is waiting for an answer.
Have the conversation, then file the document
Row E5 is the one people drop. A ticked checklist that nobody discussed is a record of what you intended, and the client will tell you the difference the first time something in it is not what they remember.
When to use this, and when to stop
The hand-off is the cheapest place in a project to fix something, and the most commonly skipped.
When this template is the right tool
- Sales and delivery are different people, and the delivery team currently learns the project from a folder and a forwarding email.
- You want the exclusions, assumptions, and change triggers written down while the sales conversation is still fresh.
- Scope has been lost on a previous project and the invoice did not match what anybody agreed.
- You are growing past the point where the founder personally does both the selling and the delivering.
When you have outgrown it
- The hand-over is a folder of files and a chat thread, so what was agreed is reconstructable only by asking two people.
- Approved changes are made in conversation and the quote is never revised, so the invoice cannot be checked against anything.
- Nobody can say who owns delivery, so the client asks a question that sits unanswered for a week.
- Every project is handed over differently, so problems repeat on the next one with the same cause.
The same process in NoxOrigin
A hand-off checklist is a substitute for a record that already exists. A won opportunity carries the client, the contacts, the quoted line items, the terms, and the accepted value into delivery as the same record rather than as a summary of one, so the delivery team is not reading a summary of something. Agreed scope becomes a project with status, members, tasks, and dates; exclusions stay attached to it; and an approved change is recorded as a change against that project, so the difference between what was agreed and what is billed is a figure rather than a recollection. Permissions decide who may approve a change and at what value, and the override is written to an audit trail — which is what makes a conversation a week later answerable. Invoicing then raises against the project and the milestone, and the payment recorded against it settles the same chain, so nothing has to be re-keyed between the conversation in the sales call and the invoice at the end of it.
- Sales to project hand-off softwareCarries the client, scope, contacts, and commercial context from a won opportunity into delivery, then into billing and collection.
- Scope management softwareAgreed scope, the task breakdown it became, delivery status, and invoiced value on the same project, so quoted-against-billed shows where scope was lost.
- Project delivery softwareProjects with status, dates and members, tasks, assignments, due dates, and follow-ups, connected to the client and the invoice the work produces.
- Project scope templateThe document the scope section of this hand-off points at, with deliverables, exclusions, assumptions, milestones, and acceptance criteria.
- Client onboarding checklistThe client-record half of this hand-off, taken further: access, documents, billing details, and the first-run walkthrough.
Project hand-off checklist questions
What is the point of the hand-over at all?
Because the enquiry and the delivery are usually two people and two sets of records. The salesperson knows what the client actually meant; the delivery team knows what has to be built. Without a written hand-over the second one inherits the first one's memory, and the first question the client asks in week three gets answered differently from how it was answered in the sales call.
Should this be ticked off by sales or by delivery?
Both, on the same document. The example gives each row an owner of the item and a counterpart, which makes the difference visible: sales fills in the client record and the scope, delivery ticks that it has received and understood them. A hand-over signed by only one side is a handover note, and a handover note is a summary nobody has checked.
How detailed should the scope section be?
Detailed enough that the exclusions are the interesting part. The example does not re-describe the deliverables — the accepted quotation is attached, and the rows S3 and S4 point at what is excluded and what was assumed. Those are the two lists that stop a conversation three weeks in from turning into a dispute about what was agreed.
What belongs in the new-quote triggers?
The changes you can predict from what you already know about the client. A new page type, a second language, a new market, an integration nobody quoted for. Writing them down while the context is fresh means the first request for one of them is a known case with a price already agreed in principle, instead of a negotiation that starts from zero with the original quote still unmentioned.
Do I need this for a small fixed-price job?
For a small job, the parts about the client record, the exclusions, and what the client is told to expect still apply — they are the parts that decide whether the job finishes without an argument. The parts about ownership, escalation, and change triggers earn their keep once more than one person is involved. Use the sections that apply rather than a shortened version of the document.
Hand over the project, not a summary of it.
If the delivery team learns the scope by asking, the client is paying for the time it takes to find out.