Direct answer: give every accepted request a unique ID, freeze its approved scope reference, assign one current state, record the next observable action and owner, surface blockers, and preserve delivery evidence before closing the row. The queue is a production truth source, not a list of conversations or ideas.
This queue tracks creator-approved, accepted requests from confirmation through delivery. It does not decide whether to accept a request, calculate capacity, create the creative brief, set a price or provide subscriber message scripts.
A request enters this system only after acceptance evidence and a stable scope exist. Conversations, tentative enquiries and unapproved concepts belong outside the production queue so the creator can see actual committed work without inflated demand or ambiguous promises.
Define the evidence required to enter Accepted
The entry packet needs a Request ID, accepted-offer reference, approved scope version, creator approval, relevant asset requirements and the agreed delivery condition. If one is missing, keep the item in the source workflow rather than creating a half-valid queue row.
Use the quote acceptance record to establish which proposal was accepted. The queue stores that record's identifier; it does not reinterpret the conversation or renegotiate terms.
Use the scope confirmation form when the production reference is not frozen. A request with changing instructions cannot move predictably through a state system.
Give every request one immutable identity
The Request ID follows the work through file names, production notes, review and delivery evidence. Do not create a new ID when the row changes state. Create a new version reference when approved scope changes, and preserve the relationship between versions.
Keep subscriber details to the minimum needed for accurate delivery and use the platform's appropriate identifiers. The queue should not become a duplicate archive of private conversations or unrelated personal information.
When two requests share source footage or a setup, retain separate Request IDs. Shared production can be noted as a dependency group, but delivery, approval and closure still belong to each accepted commitment.
Use states with clear entry conditions
Accepted means the entry packet exists. Ready means required inputs and dependencies are available. In production means active creation has begun. Review means a completed candidate is being checked. Ready to deliver means the approved asset and delivery information are prepared.
Blocked is a visible production state with a specific unresolved condition. Delivered requires evidence of the delivery event. Closed means no production or delivery action remains and the closure reason is recorded.
A row can hold only one current state. Supporting notes can describe nuance, but labels such as In production / Waiting / Almost done hide the next action. Choose the earliest unmet entry condition and name what moves the row forward.
Control active work instead of starting every row
The creator selects how many requests can occupy active production states. Keep newly Accepted rows ready for prioritisation rather than moving them all to In production. A long active list hides bottlenecks and makes completion dates harder to assess.
Order Ready rows by creator-approved priority, dependency opportunity and delivery condition. Do not let the loudest follow-up automatically reorder the queue. Record a priority change with the decision owner and reason.
When active capacity is full, finishing or explicitly blocking current work comes before starting another row. The queue should reveal the constraint rather than spread effort across every request.
Write the next observable action on every open row
A useful next action produces evidence: confirm wardrobe availability, capture approved scene, edit Asset Version 2, run quality review or prepare delivery. Avoid continue work or follow up, which cannot show whether the state advanced.
Assign one owner and a review timestamp. The owner is responsible for updating the row, not necessarily performing every creative task. If ownership changes, append a handoff event instead of replacing the history.
Attach the dependency or file identifier needed for the action. A queue that requires searching old messages for every step is not functioning as a production control surface.
Expose blockers as decisions, not buried notes
Record Blocker Type, exact condition, owner, opened date and next review. Useful types include missing input, unavailable location, creator pause, technical failure, approval needed or delivery-channel issue.
Every blocker needs one of three paths: resolve the condition, approve a revised scope or return the request to the appropriate prior workflow. Waiting without a decision date leaves the queue state accurate but operationally inert.
Do not mark a request Ready while a critical blocker remains in a note. Conversely, do not keep a row Blocked after the evidence arrives. State accuracy depends on updating both directions.
Escalate exceptions with a named decision
Open an escalation when a creator-set review checkpoint passes without the evidence needed for the next state, the production asset conflicts with the frozen scope version, the assigned owner cannot complete the next action, or delivery evidence cannot be reconciled with the intended asset. These are observable triggers. The age of a row by itself is not enough because a recorded pause may be intentional.
An escalation record needs the Request ID, trigger evidence, decision required, decision owner and next decision time. The available outcomes are also controlled: clear the blocker, reassign the next action, approve a versioned scope change, pause production, or return the item to the workflow that owns cancellation or renegotiation. The queue records the outcome but does not make that commercial decision.
Keep the production state and escalation flag separate. A blocked request can have an open escalation, while a Ready item may be escalated because its owner became unavailable before work started. Close the escalation only when the decision and its resulting queue update are both recorded; a reply without a state or action change is not resolution.
Copy the custom-request queue template
Practical artifact: use one row per accepted Request ID and keep state transitions in an append-only event history.
| Queue field | Required value | State rule | Evidence | Next action |
|---|---|---|---|---|
| Request ID and scope version | Unique ID plus frozen approved reference | Required before Accepted | Acceptance and scope records | Confirm prerequisites |
| Current state | Exactly one allowed state | Move only when entry evidence exists | Timestamped state trail | Named action and owner |
| Blocker | Specific condition, owner and review date | Blocked is visible, not hidden in notes | Dependency record | Resolve, rescope or return |
| Delivery | Asset version, channel and timestamp | Required before Delivered | Delivery evidence | Confirm close criteria |
| Closure | Reason and retained references | No open action remains | Creator review | Archive without deleting history |
A fictional accepted request has a scope reference, required assets and a creator-approved due window. The wardrobe dependency is unavailable, so the row is Blocked with an owner and review date. It should not remain In production merely because work started earlier. The example provides no recommended turnaround.
Move rows only when transition evidence exists
Define required evidence for each transition. Ready to In production might require an active production file and start timestamp. In production to Review requires a complete candidate asset. Review to Ready to deliver requires creator approval of a named version.
When a review fails, return the row to In production with the exact correction and retained review record. Do not create an invented state such as mostly approved. The event trail can show progress while the current state remains unambiguous.
Record who moved the row and when. If a state was selected in error, append a correction event rather than deleting it. This makes repeated workflow confusion visible for later improvement.
Require quality and delivery evidence before closure
Ready to deliver means the intended asset version, file integrity, scope match and delivery information have been checked. It does not mean the subscriber has received the item. Preserve the distinction between prepared and delivered.
Use the custom content delivery checklist for the asset-level validation. Return its evidence reference to the queue instead of copying the entire checklist into the row.
Delivered needs the channel, timestamp and asset version. Closed additionally needs confirmation that no correction, delivery or creator action remains. When closure cannot be confirmed, keep the row Delivered with a named follow-up.
Preserve scope changes without losing the original request
If the creator approves a material change, create a new Scope Version and record whether effort, dependencies or delivery condition changed. The Request ID stays stable so the history remains connected.
Do not edit an old scope document in place. Production decisions made under Version 1 should remain understandable after Version 2 exists. Mark which version controls every asset candidate and delivery event.
When the change is effectively a separate request, close or return the original through the approved workflow and create a new Request ID. The queue should not hide two commitments inside one row.
Review queue health from flow evidence
Useful operating observations include time spent in each state, blockers by type, rows returned from Review, missing next actions and delivered rows awaiting closure. Interpret them as workflow evidence, not creator-performance rankings.
Sample the oldest open rows and verify their current evidence. A long duration can reflect a deliberate pause or missing dependency; the queue should make the reason visible. Age alone does not determine priority.
Review closed and stopped work as well as successful deliveries. Repeated blocker types can justify a better entry check, while repeated review returns can reveal a weak scope reference or quality handoff.
Queue-management sources
The official Scrum Guide, released in November 2020, supports transparent work, inspection and adaptation. This queue is a creator production tool and is not presented as a Scrum implementation.
GOV.UK Governance principles for agile service delivery, published February 22, 2016 and updated May 23, 2016, supports visible blockers, timely decisions and light regular verification.
Limitations
Limitations: a queue is only as current as its last update. Platform message states, file delivery evidence and external dependencies may be incomplete. The template does not establish suitability, prevent every misunderstanding or guarantee delivery by an estimated date.
The queue does not calculate request capacity, set a price, approve scope or write subscriber messages. It starts after acceptance and controls the production state of one creator's committed work.
Creator decisions can pause, revise or stop a request regardless of its current state. The correct response is to record the decision and preserve the history, not force the row through the remaining states.