Skip to main content
Suppose 80 cards clear intake this week, but only 50 become sale-ready while meeting the condition, record, and location rules. For that group, 30 wait. Buying faster listing equipment might help—or it might move a larger pile toward picking and packing. The decision depends on where work that still meets its guardrails is actually falling behind. A bottleneck is not the station that looks busiest. It is the stage that persistently constrains completed flow. Find it before buying a tool, hiring help, or pushing more work into the system.

​
Map the whole trip

Inventory and fulfillment often use different counting units. Follow saleable items or consistent batches from receipt through sale. At the sale, record both items sold and transactions created; then follow transactions through pick, pack, fulfillment, and resolution. Never subtract item counts from transaction counts as though they were the same thing. Safely completed means the stage finished while its quality and service rules still held. A scan, draft, touch, or opened order is activity unless it is the stage’s real output. Record batch waiting separately from active work. For each stage, keep the flow balanced: Ending queue = opening queue + units entering + returned rework − safe completions − other recorded exits Every term uses that stage’s counting unit and review period. Name other exits such as cancellation, disposal, or transfer; they reduce a queue but are not completion capacity. Do not count failed work as safely completed and then add the same work again as rework. Chapter 4.3 already supplies sale-readiness, intake-backlog, and sale-readiness-age measures. Chapter 4.4 supplies the later-fulfillment capacity and customer-promise boundary. Put those values on the map rather than rebuilding them.

​
Find the constraint, not a bad day

Look for a queue or oldest wait that persists across comparable periods because safe completion capacity is below the work presented to that stage. Keep product mix and operating conditions visible. A one-time collection, outage, or service incident is context unless it is the scenario the proposed change is meant to handle. Check the next stage too. If the improvement would only create a larger downstream queue, cap the pilot or address that limit first. A positive queue change in one period is a signal to investigate, not proof of a permanent bottleneck. When the evidence is noisy, collecting another comparable period is a valid decision.

​
Match the response to the cause

For every response, count setup, monitoring, coordination, rework, and any queue pushed downstream. Then keep the choice-specific test narrow:
  • Simplify when duplicate fields, handoffs, sorting rules, or avoidable rework create the queue. The pilot should remove steps without erasing condition, location, cost, provenance, or service evidence. Restore the prior step if errors rise.
  • Automate when a stable, repetitive step with clear inputs and outputs is the measured constraint. Include maintenance, exceptions, and damage risk.
  • Delegate when a recurring task is teachable and added human capacity fits better than a redesign. Include training, access, authority, and applicable employment or contracting duties.
  • Throttle when intake or demand exceeds safe downstream capacity and fixed capacity is not justified. Narrow or pause upstream flow inside the sourcing, pricing, venue, and customer rules already written.
These are alternatives, not stages of growth. Choose the smallest reversible response that changes the named constraint while preserving quality, cash, and customer promises.

​
Bound the pilot, including the exit

Use one pilot period and comparable work. Start with the time effect: Net hours returned = affected units × (baseline minutes per unit − pilot minutes per unit) ÷ 60 − added setup, monitoring, training, maintenance, coordination, and rework hours The result may be negative. Do not assume that extra output sells or that returned time becomes cash. The signal only asks whether the change releases useful time without moving the problem. Before starting, write the pilot cash budget and the maximum rollback exposure. Build rollback exposure from nonrecoverable setup costs, exit costs, and the portion of committed capital you do not expect to recover; list each amount once. Expected recovery cannot exceed the capital it describes, and tied-up capital must still fit Chapter 5.2. Also write the quality, service, and downstream-queue guardrails and the event that restores the prior workflow. Reject or redesign a pilot that crosses any one of those limits.

​
Record one decision

Diagnosis: Workflow-map record ___; from ___ through ___, I measured ___ using ___ as the unit. The constraint is ___ because the queue or oldest-wait evidence shows ___. Pilot: I will test simplify / automate / delegate / throttle on ___. Baseline ___; expected signal ___. Affected units ___; baseline minutes per unit ___; pilot minutes per unit ___; added hours ___; estimated net hours returned ___. Cash budget ___. Guardrails and review: Quality/service/downstream queue must remain ___. Maximum rollback exposure ___ against a maximum of ___. Stop or restore the prior workflow when ___. Owner ___; review date ___. If capacity is adequate, adding more of it is not the next task. Chapter 6.2 tests whether the business instead needs a more repeatable path to buyers or collection sellers.