DeliverLoom resources
Design and Content Subscription Workflow: Queued Requests, Revisions and Approval
Explain how queued work, active capacity and revisions fit your subscription. Includes sample policies, two worked requests and a reusable worksheet.
By Anh, builder of InsightApps · Updated
A client asks for a revision while their next request waits in the queue. Whether the next request can start depends on the package policy. Moving a card to “Changes requested” does not answer whether that revision still occupies the active slot.
Write the policy before choosing your board statuses. Your client needs to understand both which work is included and which work can happen at the same time. Those are separate limits.
- A: revision, occupies slot
- B: missing brief input
- B: ready queue after input
- B: active after A approval
The arrows for B show a future path, not its current state. B cannot become active until its brief is ready and the slot is available.
Three rules that answer different questions
These numbers and policies are fictional alternatives for explanation, not pricing advice. A real package can combine several limits, provided their interaction is clear.
| Sample rule | What it controls | What still needs explaining |
|---|---|---|
| One active request | Simultaneous work | Whether revisions and client-waiting work retain the slot |
| Four deliverables per month | Included output | What counts as one deliverable and when allowance is consumed |
| Two revision rounds per request | Changes to an output | What forms one round and how changed scope is handled |
A package allowing many queued requests can still limit active work to one. A monthly allowance does not establish turnaround for each item. Avoid using “unlimited” without the concrete constraints that determine what the client receives.
Walk two requests through one active slot
In this fictional example, Vale Studio has one active slot per client. Revisions keep the slot until approval. An incomplete brief stays outside the ready queue. The client may agree to pause an item and promote another, with timing confirmed in writing. These are example rules only.
| Request | State | Uses active slot? | Next action |
|---|---|---|---|
| A: event landing-page design v2 | Client requests an included revision | Yes | Editor applies one consolidated set of notes |
| B: newsletter draft | Brief missing destination link | No | Client supplies link and intended action |
Request B: incomplete brief → ready queue → active only when the slot is available. Request A: active design → revision → approval → slot released.
Even after the client supplies the newsletter link, B waits behind A under this policy. The operator should say that plainly. Otherwise “ready” can sound like a promise that writing has started.
If A sits with the client for several days, follow the agreed waiting-work rule. Under this example it still holds the slot. The operator can offer to pause A and promote B, but should explain how resuming A will affect the queue. Do not invent a retroactive inactivity rule to resolve a delay.
A revision and a new brief can look similar
For request A, changing the button color within the approved visual direction may be an included revision. Asking for a second page adds an output and needs a scope decision. For request B, correcting a misspelled supplied product name differs from replacing the newsletter’s audience and offer after drafting.
The actual agreement decides how corrections consume allowances. Record that rule, including how the studio handles its own errors. Do not automatically deduct a whole revision round for every comment or automatically include every change labelled “small”. If the agreement is unclear, describe the specific request and resolve it with the client before work continues.
Copy this client-facing policy worksheet
Package and period: [name, dates and included outputs]
One request means: [bounded deliverable, formats and size limits]
Ready brief requires: [inputs and who confirms readiness]
Queue order is chosen by: [client or operator; change process]
Active capacity: [number of concurrent requests]
While waiting for client feedback: [slot retained/released; conditions]
Revision policy: [rounds, consolidation, corrections and scope boundary]
Monthly allowance: [if any; counting point and unused-work rule]
Pause and resume: [who agrees, queue position and timing effect]
Approval record: [approver, exact version, date and written evidence]
Next request starts when: [capacity and readiness conditions]
Exception route: [written contact and agreement before extra work]
If the package has no monthly allowance, write “not applicable” instead of inventing credits. Where delivery timing varies by request size, explain how an estimate is agreed once the brief is ready. Do not imply that every item has the same turnaround.
Explain the next move to the client
A message for the fictional queue could read:
Thanks for the design notes. I will apply them to request A, landing-page v2. It retains your active slot through revision under this package. Once you provide the destination link, newsletter B can enter the ready queue. It can start after A is approved, or we can agree to pause A and confirm a revised order in writing.
This answers the client’s immediate question without asking them to interpret your entire board. When A is approved, preserve the accepted version and decision, release the slot under the agreed rule and tell the client which request becomes active.
Check whether the worksheet matches your offer
Choose one public or redacted package description. Fill the worksheet using only rules it actually states. Mark any missing rule “to agree” rather than guessing. Then walk one design request and one content request through a revision. If you cannot determine which starts next, clarify the package before adding more statuses or automation.
The shared service handoff provides a shorter record for each request. Use this worksheet for the standing policy that record refers to.
ManyRequests’ client request management guide, checked 23 October 2026, describes intake, visible queues and proofing in a software workflow. The worksheet here is an original way to state the package rules before choosing how to represent them in a tool.
I am comparing how recurring service packages handle capacity while developing these resources. If you have a moment, email whether a revision occupies an active slot under your current package. Please leave out private client information. Thank you for helping make the example more accurate.