Service Package Handoff Template: From Brief to Client Approval

A handoff should let someone open a client job and answer one practical question: who needs to do what next? A folder full of finished work cannot answer that if the package, latest version and approval are recorded elsewhere.

For a recurring service studio, start with a short record that travels with the work. Copy the fields below into your existing document or board. Link to your files rather than duplicating them, and keep one current record for each request. No new software is required.

1. Sold package
2. Inputs checked
3. Named version
4. Client decision
5. Remaining work checked

The next owner needs evidence from the preceding step. Missing excerpt inputs do not prevent review of a ready main edit.

A small job with one unresolved decision

The following studio, client, people and quantities are fictional. Cedar Studio sold Finch a monthly package containing one landscape interview edit and one vertical excerpt. The main edit is ready for review, but the excerpt still needs the client’s choice of quote.

Field	Completed handoff
Sold package	One landscape interview edit and one vertical excerpt this month
Required inputs	Source footage, approved spelling, logo and excerpt quote
Start condition	Mira at Cedar checks access and confirms readiness in the shared document
Responsible people	Mira edits; Jo at Finch consolidates feedback and approves
Current review version	Finch interview, landscape, v2, linked in the review tool
Included changes	One consolidated revision round per deliverable, per this fictional package
Open decision	Jo reviews main v2 and supplies the excerpt quote
Next action	Jo replies with approval or consolidated notes for main v2

The missing quote blocks the excerpt. It need not block review of the main edit. Record both facts so that a partial delivery does not look like completion of the whole package.

Follow the dependency, not just the status

Sold package → required inputs checked → named deliverable version → client decision → remaining package work checked.

This is a suggested dependency path, not a promised delivery schedule. At each transition, write the person responsible and the evidence that lets the next person begin. “In progress” is useful only if everyone knows what entered progress and what is still waiting.

An input check should establish whether files open, access works and the brief identifies an output. Receiving a folder link alone does not establish readiness. If your turnaround starts only after a complete brief, quote that actual rule and record when it was met. Do not silently start a delivery clock while an essential input is missing.

Copy this blank handoff

Field	Fill in for this request
Sold package	Package name, included deliverables and period or request identifier
Required inputs	Exact files, permissions and decisions, with their destinations
Start condition	Who checks completeness, where readiness is recorded and the applicable timing rule
Responsible people	Operator, feedback coordinator and authorized approver
Current review version	Deliverable name, format, version and stable review link
Included changes	Actual revision or scope rule agreed for this package
Open decision	What remains undecided or missing, and what it blocks
Next action	One named person, one action and any agreed due date

Use a separate version row for each asset that can be approved independently. A request identifier connects related assets; it does not make approval transfer between them.

Give the client a shorter start card

The internal handoff carries operational detail. The client-start card answers what the client needs to do first. Download the blank card and the completed fictional example.

Your package: [name and included scope]
Your first request: [one submission and destination]
Files we need: [files, access, format and a usable example]
Before work starts: [readiness check, checker and timing rule]
What happens next: [visible status and next responsible person]
Review and approval: [version, feedback route and approver]
If the request changes: [actual scope/revision rule and exception process]
If you get stuck: [written support route and actual expectations]

Replace every bracket before sharing. If you have not agreed a response window, omit a deadline promise and state how to ask for help. A start card should describe a policy you can deliver.

When a client changes the request

Suppose Jo asks for a second vertical excerpt while reviewing the main cut. Record the additional output as a scope decision. Tell Jo whether it replaces included work, consumes an existing allowance or needs a separately agreed quote. Do this before starting the addition. A board move cannot settle an unanswered commercial question.

A spelling correction also needs a clear route, but it need not be treated like an additional deliverable. Apply the package’s actual correction policy and note the corrected version. If a change follows approval, retain the old approval record and ask for a decision on the replacement version.

Put it to work on one request

Choose one current job with client names removed. Fill the package and input fields from the agreement, then add the exact review version. Read the next-action row as if you were covering for the operator. If you still need to ask what is happening, revise the record before extending it to other jobs.

For media work, use the video review packet or episode readiness matrix. For a subscription queue, use the capacity and policy worksheet.

I am developing these resources alongside DeliverLoom to learn how operators describe real handoffs. If you have a moment, email one field you would change for a recent job. A description with names removed is enough. Please do not send client files. Thank you for helping make the template more useful.