Keep one copy with each request. The checklist separates queue decisions from review decisions so a file upload cannot quietly become an approval. Adapt the status definitions to your policy before using the record with clients.
Set the operating rules
Agree who owns the queue, who owns delivery and who can approve the client's work. Specify whether a blocked request keeps an active slot and how it restarts. Use the delivery guide if those rules are unresolved.
For every exception, record a next action and owner. Do not tick a check merely because someone has sent a reminder. A reminder does not supply the missing asset or resolve conflicting feedback.
Preserve the decision
Copy the review-round section when another version needs review. Retain earlier decisions rather than overwriting them. Approval must identify the actual version, authorised person and acceptance context.
The feedback guide explains how to distinguish a revision from a changed brief. Record unresolved legal, accessibility or production checks separately; design approval does not prove they happened. Complete the handoff section only after verifying the intended recipient can access the agreed deliverables.
Use this template
Download the plain-text version, or select the text below and copy it into your own document. Replace the prompts with your studio’s decisions.
Download .txtSTUDIOSIFT | REQUEST WORKFLOW AND APPROVAL CHECKLIST Copy per request. Preserve earlier versions of this record. A checked box means verified, not merely requested. REQUEST AND POLICY Request identifier / title: ____ Accepted brief reference and version: ____ Queue owner: ____ Delivery owner: ____ Client approver: ____ Active-request policy reference: ____ Blocked work retains a slot? Decision and reason: ____ Restart order / reassessment rule: ____ STATE DEFINITIONS (adapt before use) Intake: received; scope and readiness not yet accepted. Ready: brief accepted; eligible for queue ordering, not a start promise. Active: assigned owner and an available production slot. Waiting for client: named input needed; restart rule recorded. Complete: agreed approval and final handoff verified. Current state / date / changed by: ____ ENTRY AND SCHEDULING [ ] Scope, inputs, asset access and approval authority checked [ ] Client queue priority confirmed [ ] Required skills and active slot available [ ] First-review estimate distinguished from final completion Start decision and owner: ____ Communicated estimate / assumptions / record location: ____ BLOCKER OR PRIORITY CHANGE (repeat if needed) Event and requested change: ____ Work already completed / safe stopping point: ____ Missing input or unresolved decision: ____ Responsible person and next action: ____ Effect on current and queued commitments: ____ Authorised decision / communicated expectation: ____ Next review date and restart owner: ____ REVIEW ROUND (copy for every new version) Version identifier / review location: ____ Decision requested and intended use: ____ Client feedback consolidator: ____ [ ] Reviewers directed to the same version [ ] Conflicting instructions resolved by authorised client person [ ] Scope and scheduling effect assessed before revision Agreed change list / unresolved issues: ____ Revision or new request? Reason and authorisation: ____ Next version / change-summary location: ____ Approval: [ ] Approved [ ] Changes requested [ ] Decision outstanding Exact approved version / approver / recorded date: ____ Conditions or checks outside this approval: ____ FINAL HANDOFF [ ] Export specifications and agreed deliverables checked [ ] Final version and file names match the approval record [ ] Recipient access verified [ ] Required source files and usage notes included Final file reference / delivery recipient / recorded date: ____ Remaining obligations and their owner: ____ Closure authorised by: ____ Next queue action / responsible person: ____