> ## Documentation Index
> Fetch the complete documentation index at: https://course.pokesignal.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 6.1 · Find the Bottleneck Before You Scale

> Map the workflow, name the queue that constrains it, and test the smallest reversible capacity change.

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.

| Stage                   | Counting unit                     | Flow and queue fields                                                 | Completion guardrail                 |
| ----------------------- | --------------------------------- | --------------------------------------------------------------------- | ------------------------------------ |
| Buy and receive         | Saleable item or consistent batch | Entered, safely received, ending queue, oldest wait, active time      | Acceptance and cash boundary         |
| Intake decision         | Same inventory unit               | Entered, decided, ending queue, oldest wait, active time and rework   | Condition and uncertainty rule       |
| Sale-ready and findable | Same inventory unit               | Entered, completed, ending queue, oldest wait, active time and rework | Listing and location accuracy        |
| Sold or committed       | Conversion point                  | Items sold and transactions created, recorded separately              | Acceptable economics and sale record |
| Pick and pack           | Transaction or order              | Entered, completed, ending queue, oldest wait, active time and rework | Item and protection accuracy         |
| Fulfill or resolve      | Same transaction unit             | Entered, completed, ending queue, oldest wait, active time and rework | Customer promise met                 |

*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](/chapters/4-3-listing-and-inventory-discipline) already supplies sale-readiness, intake-backlog, and sale-readiness-age measures. [Chapter
4.4](/chapters/4-4-fulfillment-and-the-customer-promise) 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](/chapters/5-2-bankroll-discipline). 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](/chapters/6-2-content-is-a-moat) tests whether the
business instead needs a more repeatable path to buyers or collection sellers.