Intake Queue¶
Workflow mechanism — instantiates Flow Channelization
Holds admitted work in an ordered, priority-ranked line with explicit rules for who advances, who may legitimately jump, and what 'done' means, so nothing waits invisibly or forever.
An Intake Queue is the ordered holding line that governs what gets worked next once work has entered a channel. What makes it this mechanism is that its whole substance is order and disposition: it ranks the waiting items by an explicit priority, defines when someone may legitimately jump the line, and states the condition under which an item has left the queue as resolved. It is not the front door through which work arrives, and it is not the per-item system of record — it is the disciplined line between arrival and resolution. Without it, "we'll get to it" is a promise with no ordering behind it; with it, every waiting item has a known position, a rule for why the item ahead of it is ahead, and a defined finish line.
Example¶
A legal aid clinic takes in far more requests for help than its handful of attorneys can serve. Before, cases sat in a shared inbox and got picked up by whoever noticed them — which meant the loudest client, not the one facing the nearest deadline, got seen. The clinic institutes an Intake Queue. Admitted cases enter a single ranked line ordered by a published priority rule: imminent eviction and removal hearings outrank routine matters, and among equal urgency, longest-waiting goes first. A bypass rule is written down explicitly — a client with a court date inside seventy-two hours may be pulled to the front, but the reason is logged, so line-jumping is a governed exception rather than a favor. And each case has an exit condition: it leaves the queue only when it is either taken on by an attorney or formally referred elsewhere with the client notified — never by quietly going stale. The clinic did not change how cases arrive or how each case's file is kept; it changed the shapeless backlog into an ordered line where position is principled, jumping is accountable, and leaving means something definite.
How it works¶
- Rank, don't just collect. Every admitted item gets a position from an explicit priority rule, so "next" is a decision the queue can defend, not an accident of who is watching.
- Govern the jump. A written bypass rule says who may legitimately skip ahead (an emergency, a hard deadline) and requires the reason be recorded, so exceptions do not quietly become the norm.
- Define the finish. An item leaves only when a stated exit condition is met — resolved, referred, or formally withdrawn — so nothing exits by neglect and no one is left waiting on a line that has silently stopped moving.
- Keep the wait visible. Position and expected wait are legible to the waiting party, so the queue reveals its own depth rather than hiding it.
Tuning parameters¶
- Priority scheme — strict first-in-first-out, weighted by urgency, or fully discretionary. Urgency-weighting serves the most pressing cases but invites disputes over whose need ranks higher; pure FIFO is fair and simple but blind to real emergencies.
- Bypass tightness — how easy it is to jump the line. Generous bypass handles genuine emergencies but erodes into routine queue-jumping; strict bypass protects fairness but can trap an urgent case behind the rule.
- Exit strictness — how much must be true before an item is counted done. Strict exit prevents premature closure but lengthens the visible queue; loose exit clears the board but hides unfinished work.
- Aging policy — whether long-waiting items automatically gain priority. Aging prevents starvation of low-priority work but can push a trivial old item ahead of a fresh urgent one.
- Queue visibility — how much of position and wait time the waiting party can see. Transparency builds trust but exposes long waits that may drive people to give up.
When it helps, and when it misleads¶
Its strength is that it converts an invisible backlog into a principled, inspectable line: the next item is chosen by a rule anyone can read, emergencies have a legitimate way through, and "done" is defined so work cannot rot unattended. It is the archetype's guard against a channel that admits flow but then leaves it in an ungoverned heap.
Its failure mode is channel capture and hidden starvation: if the priority rule is gameable, high-power or high-volume claimants learn to dress routine requests as emergencies, and the genuinely urgent-but-quiet wait forever behind them.[n1] A queue can also become a place work goes to look handled — a long line with a tidy exit rule can still be moving far too slowly for the demand arriving, and averaging the wait hides the tail of cases that wait far longer than the mean. The discipline is to audit who actually reaches the front against who should, treat repeated bypass as evidence the priority rule is wrong rather than as noise, and watch the worst-case wait, not the average.
How it implements the components¶
The intake queue realizes the ordering-and-disposition side of the archetype — how admitted flow is ranked and released, none of the intake or transport components:
channel_priority_rule— the ranking scheme is the priority rule that decides which waiting item advances and why.bypass_policy— the written line-jumping rule distinguishes legitimate exceptions (a hard deadline) from harmful queue-jumping, and logs them as design evidence.exit_condition— the stated finish — resolved, referred, or withdrawn — is the exit condition that governs how an item leaves the queue with accountability.
It does not define the front door work arrives through (channel_boundary, entry_rule) — that's Service Channel Portal — and it does not keep the durable per-item state record; that is the job of Ticketing System, a sibling under Request–Response Provisioning. The queue orders and closes work; it neither admits it nor is its file of record.
Related¶
- Instantiates: Flow Channelization — the intake queue is the ordered path admitted work moves through toward resolution.
- Consumes: Service Channel Portal supplies the admitted requests the queue then ranks and disposes of.
- Sibling mechanisms: Service Channel Portal · Ticketing System · Channel Monitoring Dashboard · Data Conduit · Drainage Channel · Overflow Lane or Spillway · Traffic Lane · Workflow Swimlane
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The live queue maintains priority state and advances, legitimately jumps, or completes admitted work under explicit runtime rules.
Nearest alternative: Decision, Gate & Allocation — Items receive priority and advancement decisions, but continuing stateful scheduling is the operative form.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Ordered waiting lines, priority disciplines, arrival rates, service rates, and wait-time analysis are canonical queueing theory and operations research.
Related originating lineages:
- Organizational & Management Science — Workflow governance materially supplies escalation rights, ownership, and definitions of completion.
Review resolution: Both independent reviews place the primary lineage in operations_research. The queued differences (origin_mode_disagreement, domain_reach_disagreement) concern secondary metadata rather than primary provenance. The final retains organizational_management only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=convergent because the reviewers document independently established or materially co-developing traditions. domain_reach=universal records application breadth separately from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Little's Law relates the average number of items waiting to the arrival rate times the average wait — a queue's length is not a fixed property but a symptom of how fast work arrives versus how fast it is cleared. It is why a tidy priority rule cannot rescue a queue whose arrival rate simply outstrips its service rate. ↩