Service Rate Matching¶

Essence¶

Service Rate Matching is the queueing intervention for the moment when the arithmetic of waiting has become impossible: work arrives faster than it can be served, so the queue grows even if the service order is fair and the backlog is visible. The archetype changes the service side of the system—capacity, cadence, staffing, worker activation, processing rhythm, parallelism, or service mode—so effective service rate matches arrival pressure within explicit quality, cost, and fairness guardrails.

It is not generic capacity improvement. It is queue-specific capacity alignment. The telltale question is: What service rate is required for this queue to remain stable over this arrival window, and what responsible levers can change that rate?

Compression statement¶

When work arrives faster than it can be served over the relevant interval, change the service side—staffing, cadence, automation, parallelism, service windows, or processing rate—so effective service rate tracks arrival pressure while preserving quality, fairness, and cost guardrails.

Canonical formula: arrival_rate > effective_service_rate -> queue_growth; arrival_rate_signal + service_rate_model + stability_threshold -> service_rate_adjustment + feedback_check

When to Use This Archetype¶

Use Service Rate Matching when a queue is growing because the service engine is paced for a different demand reality than the one actually arriving. The pattern is especially useful when arrivals vary by hour, season, deadline, incident, release, shift, or case mix, and when the system has some ability to change staffing, cadence, automation, parallelism, or service windows.

It is weaker when the service bottleneck cannot safely move, when the main intervention should be demand smoothing or upstream backpressure, or when the problem is primarily order, priority, or admission rather than service-rate mismatch.

Structural Problem¶

A queue becomes unstable when effective arrivals exceed effective service rate over the relevant period. That does not require anyone to be lazy or the queue to be badly ordered. A support team may work constantly and still fall behind after a product launch; a permit office may process diligently and still accumulate applications before a deadline; a cloud job queue may operate correctly and still age messages because worker count is below arrival pressure.

The structural problem is a mismatch between the rhythm of demand and the rhythm of service. If the mismatch is not made explicit, the system often compensates through hidden delay, heroic overtime, rushed service, abandoned work, informal prioritization, or chronic backlog.

Intervention Logic¶

The intervention begins by making arrival rate, service rate, and backlog stability comparable. The system estimates how much work is arriving, how much work can be served under current conditions, and what queue growth or wait-time risk that mismatch implies. It then defines thresholds that trigger service-side changes: opening more workers, changing review cadence, adding a shift, activating surge staff, expanding a service window, changing batch size, or temporarily simplifying service.

The key is not merely to “add capacity.” Sometimes the right rate change is a different cadence, a more frequent review cycle, a temporary worker pool, automation for a narrow bottleneck, or a drain-rate target after a peak. The matching action should be bounded by guardrails: quality must not collapse, staff must not be exploited, complex cases must not be abandoned, and costs must remain visible.

Key Components¶

Service Rate Matching organizes a queue-stability intervention around a comparison between two rhythms: how fast work arrives and how fast it can be served. The Arrival Rate Estimate measures or forecasts demand over the relevant window, distinguishing average flow from burstiness, seasonality, and exceptional surges so that mismatch becomes visible even when long-run averages look acceptable. The Service Rate Capacity Model makes the supply side explicit — what the system can actually complete per unit of time under current staffing, tooling, cadence, and work mix — so it can be compared with arrivals rather than assumed adequate. The Backlog Visibility Signal reports current queue depth, age, growth, and drain rate, providing the control input that anchors the loop to the real waiting system. The Stability Threshold defines the acceptable bounds for queue growth, wait time, utilization, or backlog age beyond which a response must be triggered, preventing both neglect and overreaction.

When the threshold is crossed, Service Rate Adjustment is the central act: changing effective capacity, cadence, parallelism, or scope so output tracks arrival pressure rather than lagging behind it. The Cadence or Staffing Policy preauthorizes which operational changes are available — shifts, service windows, batches, worker activation — so teams do not improvise late or unfair responses under pressure. The Feedback Control Loop ties everything together by repeatedly comparing arrivals, service rate, backlog, and outcome quality, replacing one-time sizing with continuous adaptation. The Quality and Cost Guardrail prevents the easiest failure mode: shortening a queue by destroying quality, exploiting staff, excluding hard cases, or hiding cost. Two final required components handle the limits of the pattern: the Fallback Overflow Policy defines what happens when arrivals exceed what rate matching can responsibly absorb — deferral, escalation, rate limiting, or load shedding — so the system never pretends all demand can be served, and the Authority and Ownership Boundary closes the governance gap between people who see the queue and people who control the levers, naming who may change staffing, cadence, automation, or scope when conditions require it.

Several context-specific Optional Components extend the pattern when the situation demands them. A Surge Capacity Pool provides preauthorized people, machines, or budget that can be activated when stability thresholds are crossed during predictable peaks or incidents. A Service Simplification Rule defines temporary simplifications that let service proceed faster during peaks while preserving minimum quality and fairness, distinguishing legitimate narrowing from hidden degradation. The Demand Forecast Window sets the time horizon over which arrivals are predicted, matched to how quickly capacity can change — short enough to capture bursts, long enough to avoid frantic reactions. The Drain Rate Target sets a desired net reduction when backlog is already above its stability band, recognizing that matching arrivals exactly is not enough once a queue has accumulated. The Class-Specific Rate Policy allows different rate responses for different work classes, risk levels, or service lanes when one aggregate rate would hide critical imbalances and starve complex or low-power cases.

Component	Description
Arrival Rate Estimate ↗	Measures or forecasts the rate at which new work, requests, users, cases, or demand enter the waiting system over the relevant time window. This estimate is the demand-side input to matching. It should distinguish average arrival rate from burstiness, seasonality, class mix, and exceptional surges, because a queue can be unstable even when long-run averages look acceptable.
Service Rate Capacity Model ↗	Represents how much work the system can actually complete per unit of time under current staffing, tooling, cadence, quality constraints, and work mix. The model does not have to be mathematically elaborate, but it must be explicit enough to compare capacity with arrivals and detect when the queue will grow rather than drain.
Service Rate Adjustment ↗	Changes the effective rate, cadence, or parallelism of service so output can track arrival patterns without uncontrolled queue growth. Adjustment can increase capacity, reduce service friction, change cadence, reallocate staff, activate automation, or temporarily simplify service. It is the central intervention component, not merely a measurement.
Backlog Visibility Signal ↗	Shows current queue depth, age, growth rate, drain rate, or service-level risk so rate matching responds to the actual waiting system rather than assumptions. This component borrows from Backlog Visibility but uses the signal as control input. Visibility alone is not Service Rate Matching; the matching response must change service behavior.
Stability Threshold ↗	Defines acceptable bounds for queue growth, wait time, utilization, or backlog age beyond which a service-rate response is triggered. The threshold prevents both neglect and overreaction. It can be a maximum wait, target utilization range, queue length band, age distribution limit, or service-level breach threshold.
Cadence or Staffing Policy ↗	Specifies what operational changes are available when arrivals and service rate diverge, including staffing shifts, service windows, processing batches, or worker activation. Without a defined policy, teams often notice the mismatch but improvise late, uneven, or unfair responses. The policy translates diagnosis into accountable capacity changes.
Feedback Control Loop ↗	Repeatedly compares arrival rate, service rate, backlog state, and outcome quality so the system can adapt instead of relying on one-time sizing. The loop should include measurement, decision, action, and remeasurement. It is especially important where arrivals vary by hour, season, incident, market cycle, or social behavior.
Quality and Cost Guardrail ↗	Limits service-rate increases or cadence changes that would protect queue stability by destroying quality, safety, staff well-being, equity, or financial discipline. A queue can be made shorter by rushing, under-serving, overworking staff, or excluding hard cases. Guardrails keep matching from becoming disguised degradation or exploitation.
Fallback Overflow Policy ↗	Defines what happens when arrivals exceed what rate matching can responsibly absorb, including deferral, escalation, rate limiting, load shedding, or queue draining. Service Rate Matching is not magic capacity. It needs explicit fallback paths for extreme mismatches so operators do not pretend all demand can be served immediately.
Authority and Ownership Boundary ↗	Identifies who is authorized to change staffing, cadence, automation, service windows, batch size, or service scope in response to queue conditions. Many mismatches persist because the people who see the queue cannot change the rate, and the people who control resources do not see the queue. This boundary closes that governance gap.

Optional components. These often strengthen the draft when the situation calls for them.

Component	Description
Surge Capacity Pool ↗	Provides a preauthorized reserve of people, machines, budget, or attention that can be activated when queue stability thresholds are crossed. This component is useful for predictable peaks or incident response, but it must not be confused with Capacity Reservation unless the central problem is protecting future capacity rather than matching current arrivals.
Service Simplification Rule ↗	Defines temporary simplifications that allow service to proceed faster during peaks while preserving minimum quality and fairness. Simplification may be legitimate when the service can be safely narrowed, but it becomes failure if it quietly lowers standards, excludes complex cases, or creates hidden rework.
Demand Forecast Window ↗	Sets the time horizon over which arrivals are predicted and matched, such as hourly, daily, seasonal, incident-based, or release-cycle windows. The right window depends on how quickly capacity can change. A forecast window shorter than the response time produces frantic reactions; one that is too long hides bursts.
Drain Rate Target ↗	Defines the desired net reduction in backlog when the queue is already above its acceptable stability band. When backlog has accumulated, matching arrivals exactly is not enough. The system may need service rate above arrival rate until the queue returns to a safe level.
Class-Specific Rate Policy ↗	Allows different service-rate responses for different work classes, risk levels, or service lanes when one aggregate rate would hide critical imbalances. This component should be used carefully because it borders Queue Partitioning and Priority-Based Admission. It fits here when the central act is capacity-rate matching for each class.

Common Mechanisms¶

Mechanism	Description
Staffing to Demand ↗	This is a labor_capacity_adjustment mechanism. Schedules or reallocates staff according to observed or forecast arrival patterns so service capacity rises where queues would otherwise grow. Works when labor is the binding service resource and enough lead time exists to change rosters, assignments, on-call activation, or cross-coverage. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Autoscaling Worker Pool ↗	This is a technical_capacity_scaling mechanism. Adds or removes processing workers, servers, threads, or containers in response to queue depth, arrival rate, latency, or utilization signals. Common in cloud, data, messaging, and workflow systems. It implements the archetype only when scaling is governed by arrival-service mismatch and stability targets. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Service Window Adjustment ↗	This is a temporal_capacity_reallocation mechanism. Expands, contracts, shifts, or staggers service hours so available service time aligns with when arrivals actually occur. May overlap with scheduling or demand smoothing. It belongs here when the service side moves to meet arrivals, not when demand is primarily pushed elsewhere. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Dynamic Capacity Allocation ↗	This is a resource_reallocation mechanism. Moves resources among queues, regions, lanes, teams, or service classes as measured mismatch changes. This can drift into Load Balancing if the primary act is routing work to equivalent capacity. It fits Service Rate Matching when resource level or cadence changes to stabilize a queue. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Processing Cadence Change ↗	This is a cadence_adjustment mechanism. Changes how often service cycles run, cases are reviewed, batches are processed, decisions are made, or work is released from a stage. Useful when the service bottleneck is a recurring review, approval, pickup, dispatch, clinic, or batch operation. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Batch Size Tuning ↗	This is a throughput_granularity_adjustment mechanism. Adjusts the amount of work handled per service cycle so throughput fits arrivals without excessive latency or waste. Larger batches can increase throughput but add wait; smaller batches can reduce delay but raise overhead. The mechanism must be tuned to the queue stability target. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Cross-Trained Surge Pool ↗	This is a surge_capacity_activation mechanism. Activates people who can temporarily serve the bottleneck queue during predictable peaks or unexpected surges. The pool must be trained enough to protect quality. Otherwise it shortens the queue by creating rework or unsafe variation. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Parallel Server Activation ↗	This is a parallelism_increase mechanism. Opens additional service stations, processing lanes, approval tracks, or machine capacity when arrival-service mismatch exceeds a threshold. Examples include opening another checkout lane, adding reviewers, spinning up processors, adding examination rooms, or activating extra dispatchers. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Peak-Mode Service Protocol ↗	This is a temporary_operating_mode mechanism. Switches to a predefined high-throughput mode during peaks while preserving explicitly defined safety, equity, and quality minima. This mechanism can be effective in emergencies and seasonal peaks, but it must not quietly normalize degraded service as ordinary operation. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.
Queue-Based Feedback Controller ↗	This is a control_rule_or_automation mechanism. Uses queue metrics such as depth, age, latency, and utilization to trigger capacity or cadence changes automatically or semi-automatically. The controller is a mechanism; the archetype is the broader governance pattern that defines what is measured, what can change, and what invariants must be preserved. It implements Service Rate Matching only when it changes effective service rate or cadence in response to arrival-service mismatch; by itself it is not the archetype.

Parameter / Tuning Dimensions¶

Arrival measurement window: How far back or forward the system looks when estimating demand. Short windows respond quickly but can overreact; long windows stabilize planning but can hide bursts.
Service-rate unit: The denominator used for capacity: cases per hour, messages per second, patients per shift, permits per day, reviews per cycle, or batches per window.
Stability threshold: The queue length, wait-time band, age distribution, utilization range, or service-level risk that triggers action.
Drain-rate target: How much faster service must be than arrivals when the queue is already too large.
Activation latency: How long it takes to add staff, start workers, change cadence, open a lane, or simplify service after a threshold is crossed.
Scaling step size: How large each adjustment should be. Small steps reduce disruption; large steps recover faster but may waste capacity or cause thrash.
Deactivation rule: When surge or high-throughput mode ends. Without deactivation rules, temporary capacity either vanishes too early or becomes permanent overload.
Quality and equity floor: The limits that prevent faster service from becoming unsafe, inaccurate, exploitative, or biased toward easy cases.
Fallback threshold: The point where the system admits that service matching cannot absorb the mismatch and must use deferral, backpressure, rate limiting, load shedding, or queue draining.

Invariants to Preserve¶

Queue Stability: Backlog should not grow without a deliberate decision and visible recovery plan.
Quality Floor: Faster service must not undermine safety, correctness, dignity, or completion quality below acceptable minima.
Fair Access: Rate matching should not permanently privilege easy, high-volume, or high-status work while complex or low-power cases wait.
Cost And Load Discipline: Capacity increases must remain economically and humanly sustainable rather than relying on permanent overtime or burnout.
Feedback Legibility: Arrival, service, and backlog signals must remain interpretable enough that operators know whether the adjustment worked.

These invariants matter because the easiest way to shorten a queue is often to degrade something hidden: accuracy, dignity, worker recovery, difficult cases, or long-term cost discipline. Service Rate Matching should make the service side responsive without turning speed into the only value.

Target Outcomes¶

Reduced Uncontrolled Queue Growth: Backlog growth is prevented or reversed because service rate is no longer fixed below arrival pressure.
Shorter And More Predictable Waits: Wait times and backlog age become more stable across peaks, seasons, incidents, and operating cycles.
More Realistic Capacity Governance: Leaders see the capacity arithmetic and can decide whether to adjust service, smooth demand, reject excess, or invest.
Less Heroic Recovery: Recurring overload is handled by designed rate response rather than repeated emergency catch-up.
Better Service Reliability: Service commitments are less likely to fail because throughput is matched to known arrival patterns.

When the archetype works, managers and operators stop treating backlog as a vague morale problem and begin treating it as a governed flow relationship. The result should be a queue that remains within a deliberate stability band or, when it cannot, an explicit fallback decision rather than hidden accumulation.

Tradeoffs¶

Stability Vs Cost: Matching service rate to peaks can reduce delay but may require standby capacity, overtime, automation, or idle capacity during quiet periods.
Responsiveness Vs Thrashing: Frequent adjustments keep up with changing arrivals but can destabilize schedules, workers, systems, and user expectations.
Throughput Vs Quality: Increasing service rate can shorten queues while increasing error, rework, rushed judgment, or unsafe shortcuts.
Aggregate Efficiency Vs Equity: Capacity may drift toward high-volume or easy-to-serve work unless complex, urgent, or less visible queues receive explicit protection.
Automation Vs Human Judgment: Automated scaling and controllers can respond quickly but may ignore qualitative constraints unless guardrails are built in.
Capacity Flexibility Vs Worker Burden: Flexible staffing improves queue stability but can impose unpredictable schedules, on-call pressure, or burnout.

Failure Modes¶

Measurement Blindness¶

Cause: Arrival rate, service rate, or backlog age is measured too crudely to reveal mismatch or class-specific overload.

Mitigation: Track queue depth, age distribution, arrivals, completions, work mix, and drain rate together; review whether metrics reflect real service burden.

Capacity Theater¶

Cause: The system announces rate matching but lacks authority, budget, staffing, or tooling to change effective service rate.

Mitigation: Tie thresholds to preauthorized levers and named owners; document what cannot be matched and when fallback policies activate.

Quality Collapse¶

Cause: Service rate is increased by rushing, skipping checks, under-serving complex cases, or delegating to untrained staff.

Mitigation: Define quality floors, audit outcomes, protect complex-case handling, and separate legitimate simplification from unsafe degradation.

Oscillation And Thrash¶

Cause: Feedback triggers are too sensitive, delayed, or poorly damped, causing repeated scale-up and scale-down cycles.

Mitigation: Use stability bands, minimum activation durations, hysteresis, forecast windows, and post-adjustment review.

Hidden Overflow¶

Cause: When service rate cannot match arrivals, excess demand is quietly pushed into informal queues, abandoned work, or staff backlog.

Mitigation: Use explicit overflow, deferral, backpressure, rate limiting, or shedding policy with visible accountability.

Easy Work Bias¶

Cause: Service-rate metrics reward completions without accounting for complexity, causing operators to process easy items while harder cases age.

Mitigation: Measure age and service levels by class; protect complex or high-risk queues with class-specific rate policy or fairness guardrails.

Permanent Surge Mode¶

Cause: Temporary surge capacity becomes the normal expectation, masking chronic under-capacity or poor demand design.

Mitigation: Time-bound surge activation, review recurring surges, and decide whether the durable solution is capacity investment, demand smoothing, or policy redesign.

Neighbor Distinctions¶

load_leveling_or_demand_smoothing: Load leveling changes when demand arrives or is released; Service Rate Matching changes the service side so capacity or cadence tracks arrivals. They can combine, but they act on opposite sides of the mismatch.
load_balancing: Load balancing distributes work across existing capacity; Service Rate Matching changes effective service rate, staffing, cadence, parallelism, or throughput to stabilize a queue.
backpressure: Backpressure sends saturation signals upstream so inflow slows; Service Rate Matching adapts the downstream service engine to handle arrivals when that is appropriate and feasible.
rate_limiting: Rate limiting caps or throttles inflow to protect capacity; Service Rate Matching attempts to change service capacity or cadence before rejecting or throttling demand.
capacity_reservation: Capacity reservation protects capacity for future, surge, or priority use; Service Rate Matching adjusts active capacity or cadence in response to current or forecast arrival-service mismatch.
elastic_capacity_scaling: Elastic Capacity Scaling is a broader future candidate about increasing or decreasing capacity in response to demand across systems. Service Rate Matching is narrower: queue stability under arrival-service mismatch is central.
capacity_expansion: Capacity expansion increases long-run capacity; Service Rate Matching may use temporary, reversible, cadence-based, or reallocative changes and may not require permanent expansion.
queue_discipline_design: Queue Discipline Design decides service order. Service Rate Matching decides whether the service side is moving fast enough relative to arrivals.
work_in_progress_limiting: Work-in-Progress Limiting caps active work to protect completion. Service Rate Matching changes service throughput or cadence so waiting work does not accumulate.
queue_draining: Queue Draining reduces an accumulated backlog through a controlled recovery plan. Service Rate Matching prevents or limits accumulation by aligning ongoing service rate with arrivals, though it may set drain-rate targets when backlog already exists.
backlog_visibility: Backlog Visibility makes waiting work legible. Service Rate Matching uses that visibility as an input to change capacity or cadence.
buffering: Buffering absorbs mismatch by holding work. Service Rate Matching reduces mismatch by changing the service side rather than simply increasing holding capacity.

The most important boundary is the demand-side/service-side distinction. Load Leveling or Demand Smoothing changes the timing or release of demand. Service Rate Matching changes the service response to arriving demand. Backpressure slows upstream input; rate limiting caps input; load balancing distributes work; queue discipline orders waiting work. Service Rate Matching asks whether the service engine itself is paced appropriately for the arrivals it must handle.

Variants and Near Names¶

Static Service Rate Matching¶

Set a stable service capacity or cadence based on known recurring arrival patterns rather than reacting continuously. It remains under Service Rate Matching because The causal logic remains arrival-service alignment for queue stability. Distinctive feature: The match is designed ahead of time from known demand rhythms.

Dynamic Service Rate Matching¶

Adjust service capacity or cadence repeatedly as arrivals, backlog state, or service-level risk changes. It remains under Service Rate Matching because It still solves arrival-service mismatch by changing effective service rate. Distinctive feature: The service side changes through a feedback loop rather than through fixed seasonal planning alone.

Surge Rate Matching¶

Activate temporary service capacity when a surge would otherwise create unsafe or unrecoverable backlog. It remains under Service Rate Matching because The central intervention is still adjusting service rate relative to arrivals and queue stability. Distinctive feature: The matching action is temporary surge activation rather than everyday baseline adjustment.

Cadence-Based Rate Matching¶

Match service by changing the rhythm of processing cycles rather than only adding staff or machines. It remains under Service Rate Matching because The cadence change is chosen to align service completions with arrivals and backlog stability. Distinctive feature: The intervention changes timing rhythm, not just volume of resources.

Near names include capacity matching, service capacity matching, arrival-service rate matching, throughput matching, and staffing to demand. These should be treated carefully. Staffing to demand and autoscaling workers are mechanisms unless the surrounding arrival estimate, stability threshold, service-rate adjustment, guardrail, and feedback loop are present. Broad Elastic Capacity Scaling should remain a future or neighboring archetype unless the queue-specific waiting problem is central.

Cross-Domain Examples¶

Software infrastructure: Increase queue workers when message age exceeds a threshold and decrease them only after backlog remains stable for a defined window. This fits because arrival and backlog signals trigger reversible service-rate adjustment.
Public benefits administration: Add document-review shifts before application deadlines and track drain rate until the pending queue returns to its target band. This fits because predictable arrival peaks are matched with temporary service capacity.
Clinic operations: Use historical arrival data to schedule intake staff and activate a float nurse when waiting-room queue age exceeds the safety threshold. This fits because staffing and surge activation match arrivals while preserving care quality.
Laboratory processing: Run specimen processing cycles more frequently during morning arrivals and return to ordinary cadence after the queue clears. This fits because service cadence is adjusted to match the temporal shape of arrivals.
Customer support: Reassign trained agents during a product incident based on ticket arrival rate, age distribution, and unresolved critical backlog. This fits because service capacity is dynamically reallocated to stabilize high-pressure queues.

Extended Example¶

A city licensing office receives ordinary application volume most of the month, but demand spikes during renewal deadlines. Under a fixed staffing model, the queue grows for two weeks, applicants wait unpredictably, and staff spend the following month burning down old work. Service Rate Matching would estimate the predictable arrival surge, compare it with ordinary review throughput, define a stability band for backlog age, and preauthorize service-side responses: extra review shifts, cross-trained temporary reviewers, longer counter hours, and a drain-rate target. If the queue still exceeds the stability band, the office activates overflow rules such as appointment deferral or deadline extension rather than hiding impossible commitments. The pattern is not merely a dashboard, because capacity changes; not merely demand smoothing, because arrivals are not primarily shifted; and not merely capacity expansion, because the response may be temporary and queue-specific.

Non-Examples¶

A restaurant posts estimated wait times but keeps the same seating and service process. This is queue transparency unless staff, tables, service cadence, or throughput change in response to the queue.
A cloud service rejects requests above a fixed limit. This is rate limiting unless the service side also changes capacity or processing rate to match demand.
A hospital triage protocol moves critical patients ahead of routine patients. This is priority-based admission or queue discipline unless capacity or cadence is adjusted to match arrival rates.
A team keeps a large buffer of incoming tasks and works through it when possible. This is buffering or backlog management if no explicit service-rate matching response is present.
A dispatcher routes requests to the currently least-busy crew without adding crews or changing cadence. This is load balancing unless the intervention also changes aggregate effective service rate relative to arrivals.