Practical delivery guide

Manage a design request queue without overpromising

Run a daily queue review that separates incomplete briefs, ready work, active commitments and blocked requests, including mid-request priority changes.

A client can submit work faster than a studio can assess it. The queue therefore needs an entry gate and a commitment gate. Receipt means the studio has the request; an active assignment means it has accepted a place in production. Explain that distinction wherever clients submit work.

Prepare a board that can answer questions

Use the state definitions in the delivery guide, then add the information required to make the next decision: request owner, client priority, missing input, active-slot status and next update. Avoid collecting fields that nobody uses during triage.

The queue owner controls scheduling changes. Clients control the relative priority of ready work within their service, while the studio checks scope, capability and existing commitments. Designers should not have to reconcile separate priority instructions from email, chat and the board.

Run the daily review

  1. Check active commitments first. Identify work at risk and communicate the changed expectation before quietly starting something else.
  2. Inspect waiting work. Every blocker needs a specific input, a responsible person and a next review point. An old "waiting" label is not a recovery plan.
  3. Review new intake for scope and readiness. Return missing inputs as one actionable list; keep unready work out of the scheduling decision.
  4. Confirm the order of ready requests with the authorised requester. Resolve competing priorities before a designer begins.
  5. Start the next request only when the active policy, required skill and available effort permit it. Record the first-review estimate and its assumptions.
  6. Check completed work for approval and accessible final files before releasing its slot under your policy.

Keep the outcome short enough to maintain: current commitment, next likely request, blockers and the owner of the next update. The workflow checklist provides a request-level record for exceptions and approvals.

Handle a mid-request priority change

Consider a hypothetical studio adapting a presentation when the client asks for an urgent event graphic. Do not simply drag the graphic above the active presentation. The presentation already contains work and may need a restart later.

Ask the delivery owner to identify a safe stopping point and assess the new brief. Tell the client what work will pause, what estimate is no longer valid and what remains unknown. Record their authorised choice. If the new brief is incomplete, it does not become ready merely because the deadline is urgent.

Decide how blocked work returns

A service may keep a blocked request in its active slot, or release the slot and reassess the request when the input arrives. Either policy can be explained. The unsafe option is to release the slot while silently promising immediate resumption.

When the missing input arrives, check whether the brief or effort changed and whether the required person is available. Give the client a revised next step. Use capacity planning to keep restart obligations visible alongside new work.

Measure the wait you can change

Review a sample of ageing requests by cause: incomplete intake, unavailable capability, client decision or repeated scope change. Compare the actual next action with the status label. This is more actionable than judging the queue solely by how many cards it contains.

If clear rules and an owner make the existing board workable, keep it. Use request software criteria only when the tool cannot represent the needed permissions, history or states. No queue routine guarantees a universal turnaround or removes the need to decline work that exceeds the service.