This is a checklist your designers copy onto every request. A file upload never quietly becomes an approval, and a priority change never gets lost in Slack. You get it blank, and filled in for one landing page that changed priority and went through two review rounds.
It picks up where the design request brief template stops. The brief decides whether a job is ready. This checklist records what happens to it after that: when it started, what interrupted it, who approved which version, and whether the files actually arrived.
Set three checklist rules before your first request
Fill in the top section once per client, then copy it into every request. Three decisions matter most. Who owns the queue and decides what goes next? Which client person can approve, and who covers when they are away? Does blocked work keep its active slot, or go back to Ready so the slot keeps moving? If you have not settled these, the requests and delivery guide walks through each one.
For every exception, record a next action and owner. Do not tick a box because someone sent a reminder. A reminder does not supply the missing asset or resolve conflicting feedback. Tick a box only once you have seen the evidence: the file itself, the approver saying yes on the record, the recipient opening the folder.
REQ-014: a filled-in request, start to finish
Filled-in example (illustrative). The client is invented. It is the same request, REQ-014, as the filled brief on the design request brief page. Alex runs a solo subscription, Priya Shah sends requests and Tom Reid, the founder, approves. The brief went to Ready on Thursday 4 March 2027. Here is what happened next.
REQUEST AND POLICY
Request identifier / title: REQ-014, Landing page for the spring webinar
Accepted brief reference and version: Trello card REQ-014, brief with copy v4
Queue owner: Alex
Delivery owner: Alex
Client approver: Tom Reid, founder (Priya Shah covers if Tom is away 2+ working days)
Active-request policy reference: Standard plan, one active request, scope page v2
Blocked work retains a slot? Decision and reason: No. Blocked work goes back to Ready so the slot keeps moving
Restart order / reassessment rule: paused work restarts first once the input arrives
ENTRY AND SCHEDULING
[x] Scope, inputs, asset access and approval authority checked
[x] Client queue priority confirmed
[x] Required skills and active slot available
[x] First-review estimate distinguished from final completion
Start decision and owner: Ready Thu 4 March 2027 after Tom chose the headline (copy v4). Active Fri 5 March. Alex
Communicated estimate / assumptions / record location: first review Tue 9 March, final files still due Fri 19 March; Trello comment on REQ-014
Current state / date / changed by: Active / Fri 5 March 2027 / Alex
BLOCKER OR PRIORITY CHANGE
Event and requested change: Mon 8 March, Priya asks for an urgent webinar banner set (REQ-015) for LinkedIn ads starting Wed 10 March
Work already completed / safe stopping point: desktop layout at first-review stage; mobile not started. Saved in Figma as "REQ-014 v1 paused"
Missing input or unresolved decision: which job goes first, given one active request
Responsible person and next action: Tom Reid, choose the order on the Trello card today
Effect on current and queued commitments: banner first means the landing page first review moves by two working days, Tue 9 to Thu 11 March. Final date Fri 19 March holds
Authorised decision / communicated expectation: Tom, Mon 8 March 11:40, "banner first". New first-review date posted on REQ-014
Next review date and restart owner: Wed 10 March, Alex restarts REQ-014 when REQ-015 is delivered
REVIEW ROUND 1
Version identifier / review location: REQ-014 v2 (Figma named version), Figma comments
Decision requested and intended use: approve layout and hero direction for the 23 March invite email
Client feedback consolidator: Tom Reid
[x] Reviewers directed to the same version
[x] Conflicting instructions resolved by authorised client person
[x] Scope and scheduling effect assessed before revision
Agreed change list / unresolved issues:
1. Hero: speaker photo, not the product screenshot (Priya wanted the photo, Tom the screenshot; Tom chose the photo)
2. Mobile: move the agenda above the speaker bio
3. Button label to match copy v4 ("Save my seat")
Revision or new request? Reason and authorisation: revision; all three items sit inside the accepted brief. Alex
Next version / change-summary location: v3 due Tue 16 March; change summary as a Trello comment
Approval: [ ] Approved [x] Changes requested [ ] Decision outstanding
REVIEW ROUND 2
Version identifier / review location: REQ-014 v3 (Figma named version), Figma comments
Decision requested and intended use: final approval for build and the 23 March invite email
Client feedback consolidator: Tom Reid
[x] Reviewers directed to the same version
[x] Conflicting instructions resolved by authorised client person
[x] Scope and scheduling effect assessed before revision
Agreed change list / unresolved issues: none
Approval: [x] Approved [ ] Changes requested [ ] Decision outstanding
Exact approved version / approver / recorded date: v3 / Tom Reid / Wed 17 March 2027
Conditions or checks outside this approval: legal check of the customer quote in section 3 stays with the client (owner: Priya)
FINAL HANDOFF
[x] Export specifications and agreed deliverables checked
[x] Final version and file names match the approval record
[x] Recipient access verified
[x] Required source files and usage notes included
Final file reference / delivery recipient / recorded date: Figma v3 plus hero JPG and WebP at 1600x900 and 800x800 in "Client 03 / Webinar 2027" / Priya Shah / Thu 18 March 2027
Remaining obligations and their owner: customer quote legal check, Priya
Closure authorised by: Alex, after Priya opened both files from her own account
Next queue action / responsible person: start REQ-016 (next in the queue) / Alex
Look at the priority change. Alex did not just drop the landing page. He saved a named stopping point in Figma and asked the one person allowed to decide. Then he wrote down what the choice cost: two working days on the first review, no change to the final date. When Priya later asks why the review slipped, the answer is on the card with Tom's name on it.
Round 1 is where most studios lose the thread. Priya and Tom wanted different hero images. Alex did not pick one. Tom settled it and sent a single list of three changes against v2. Round 2 then has one job: approve v3 or not. Approval must identify the actual version, authorised person and acceptance context. That is why the record says "v3 / Tom Reid / Wed 17 March", not "looks good". It also names what the approval does not cover. Tom approved the design. He did not approve the legal wording of a customer quote, and design approval never stands in for a legal, accessibility or print check. The feedback and approvals guide covers how to tell a revision from a changed brief when round 1 starts growing.
The short version for small requests
A five-minute social resize does not need scheduling notes or a review round. Fill in four things: the request line, the state, the approval and the handoff. Skip the blocker and review sections unless something actually goes wrong. If the resize comes back with changes, it has become a normal request, so switch to the full checklist.
REQUEST: REQ-021, resize the webinar LinkedIn post to Instagram 1080x1350 Delivery owner: Alex / Approver: Priya Shah STATE: Ready and Active Tue 30 March 2027 / Alex APPROVAL: v1 approved by Priya, Tue 30 March 2027, Trello comment HANDOFF: PNG in "Client 03 / Webinar 2027"; Priya confirmed access. Closed by Alex
The line to keep, even here, is the approval. It takes ten seconds, and it is the only proof of which version the client said yes to.
Where to keep it: the Trello card or a doc
Keep it where the request already lives. In Trello, paste the entry, review and handoff boxes as a checklist on the card. Write the approval line (version, approver, date) as a card comment, so it is timestamped and cannot be quietly edited later. Trello's free plan covers up to 10 collaborators per Workspace (Trello pricing). Name versions in Figma to match the checklist (REQ-014 v2, v3) so "v3" means one file. If you run requests in Notion, make the checklist a page template inside each request. Clients can join as guests on the pages you invite them to (Notion pricing). If your feedback already happens in a proofing tool, the proofing and feedback software comparison shows which ones record the approver and version for you.
Copy the blank workflow checklist
The blank approval checklist is below, ready to download or paste onto your next request. Keep earlier review rounds rather than overwriting them.
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: ____