If two clients keep asking what is in progress, and a card in "Doing" could mean three different things, the fix is rarely a new board. You need five states with one meaning each, a named person who moves cards between them, and a turnaround that starts when a request is ready.
Usually nobody agreed what each column means, so "Doing" covers started, half started and waiting on a logo file. This guide fixes that meaning, names who moves each card, and gives you turnaround wording you can keep on a bad week.
Five states, one meaning each
Every request sits in exactly one of these states. If a card could honestly sit in two, your definitions are too loose.
- Intake: received but not yet checked for scope or completeness. Nobody has agreed to do anything yet.
- Ready: the brief passes your entry checks and has a place in that client's order. The client can still reorder it.
- Active: a designer has accepted it into the client's slot and is working on it. This is the only state that uses capacity.
- Waiting for client: a named input or decision is missing. The card says what is missing and who owes it, for example "Feedback on v1, Priya, due Thursday".
- Done: approved on a named version and the final files are delivered. An uploaded file on its own is not done.
The definitions only work if the moves have owners too. This is the version we would start with in a studio of one to six people.
| State | Moved in by | Moved out by | What the client sees |
|---|---|---|---|
| Intake | Client, by submitting the request form or card | Queue owner, after checking the brief | "Received, we will check it today" |
| Ready | Queue owner | Designer, by pulling the top card when the slot is free | Their list, in the order they set |
| Active | Designer | Designer, to Waiting or towards Done | Who is on it and when the first version is due |
| Waiting for client | Designer, with the missing item written on the card | Designer, as soon as the client's input arrives | Exactly what they owe and by when |
| Done | Queue owner or designer, only after the approver signs off | Nobody. Further changes start a new request | The approved version and the files |
Clients never drag cards. They submit, reorder Ready and approve. That one rule stops the Monday surprise where a client has moved three cards into Active and expects all three by Wednesday. Waiting for client also covers feedback. When you send v1, the card goes to Waiting with the date you need comments by, so the client can see the ball is in their court.
Slack is where requests go missing. A request typed into a Slack thread is not in Intake until it becomes a card. Reply with the link to your request form rather than copying it across yourself, or you become the intake form. How many requests a client can have in Active at once is a separate decision. It is covered in what the one active request rule limits and what it does not.
One person owns the queue
Appoint one queue owner who reconciles each client's priorities with scope and the skills you have free. In a six-person studio that might be the account lead. If you work alone, it is you, but at a fixed time of day, not whenever a message pings.
Each morning the queue owner clears Intake, returning any incomplete brief with the specific missing input instead of a vague "needs more detail". They then check every card in Waiting for more than two working days and chase the named person. That way designers can start the day by pulling the next card without asking. The full morning routine and the Trello board setup are in how to manage a design request queue without overpromising.
The board itself is cheap. Trello Free covers up to 10 collaborators per Workspace. Standard is $5 per user a month billed annually or $6 billed monthly, as listed on Trello's pricing page. If your current board can already show these five states and a name on every card, keep it. Compare project management tools for request queues only when you hit a gap it cannot cover, such as clients needing to see their own cards and nobody else's.
How to word a turnaround you can keep
Look at how established services word the promise before you write yours. These are the vendors' own published claims, not measured results.
| Service | Published wording | What limits it |
|---|---|---|
| DesignJoy | "Avg. 48 hour delivery" | "One request at a time"; an average, so some requests take longer |
| Penji Essentials | "1 day turnaround" | "2 Active Workstreams (Equal to 2-4 hrs daily)" |
| ManyPixels Advanced | "Next-day delivery" | "1 Daily output" |
| Brett Williams, Indie Hackers AMA, May 2021 | 12 to 13 requests a day in two-day sprints, revisions "usually completed the very next day" | One active request per client; he describes roughly 50 to 60 hours a week |
Notice what every one of them does. Each figure is an average, a per-request number or a daily cap, and each applies after the request is ready. None of them says "anything you send, back in 24 hours". The clock starts when a ready request reaches the front of that client's list, not when the email arrives at 11pm on a Friday.
Avoid publishing a single turnaround that silently covers every request type. A social post and a 12-page pitch deck do not share a clock. Write yours in this order:
- List the request types you actually got last month and how long a first version took for each.
- Set the promise for the common, small ones, and state it in working days from Ready.
- Say that larger requests are split into parts, and that you give an estimate when you accept them into Active.
- Distinguish an estimated first review from final completion. Completion depends on how fast the client sends feedback, which you do not control.
- Put the wording in your terms and on the request form, so the client sees it at the moment they submit.
A line that survives a bad week reads like this: "Most requests get a first version within two working days of being ready and at the top of your list. Bigger requests are split into parts, and we give you an estimate when we start. Revisions usually come back the next working day."
Priority changes halfway through
Here is what that looks like on a Wednesday. A client's homepage hero is Active and half built in Figma. At 10am they message that a trade-show banner is now needed by Friday. The client can choose the priority. The studio has to state the delivery consequence before anyone starts.
The queue owner finds a safe stopping point, saves the hero as a named Figma version, and moves its card back to the top of Ready. The note on the card says where work stopped. The banner goes into Active, and its turnaround starts now. The queue owner then confirms in writing on the card that the hero's first version moves back by however long the banner takes. The request history stays on the original card, so nobody later argues about what was promised.
What you do not do is run both at once to be helpful. That quietly gives the client two active slots and teaches them urgency gets rewarded. The queue guide walks through this case with timings in its worked mid-request priority change.
What "done" has to include
Done needs two things on the card: approval on a named version, and files the client can open. "Looks great!" in Slack is not approval of anything. "Homepage hero v3 approved by Priya, 14 October" is, because it names the version and the approver.
Files the client can open means exports in the formats they asked for, such as PNG, PDF or SVG. Add a Figma link with view access if they want the source. A Figma link to a file they cannot open does not count. Once a card is Done, any further change is a new request that starts at Intake. That keeps your turnaround clock honest and stops finished work drifting back into Active.
For how many revision rounds to allow and how to record sign-off, see the feedback and approvals guide. To run the closing checks without relying on memory, use the workflow and approval checklist, which records blockers, priority changes and the approved version for every request.