> ## 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.

# 4.3 · Make Inventory Sale-Ready

> Move received inventory through condition, sale records, location, and capacity controls without creating an invisible backlog.

When a purchased batch arrives, the business has committed to the acquisition but the
inventory still is not ready to sell. Each unit or consistent batch needs a correct identity,
a defensible condition, accurate buyer-facing information, and a location from which it can
be retrieved.

Treat that work as one controlled flow. The final record depends on the venue: it may be an
active listing, a prepared live-session lot, or priced stock assigned to an in-person event.
Inventory is sale-ready only when that record is complete and the matching stock can be found
without relying on memory.

## Give every item a visible state

Use the same states for every unit or consistent batch in the chosen lane:

| State                      | Complete when                                                                                    | Required record or control                                                             |
| -------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| Received                   | The inventory and transaction record are in the business's control                               | Receipt date, source record, unit count, and temporary holding location                |
| Identified and conditioned | Exact item and condition are recorded; uncertainty is separated                                  | Product identity, condition status, and exception note                                 |
| Sale record prepared       | Price, buyer-facing disclosure, and the fields needed for the selected sales method are complete | Draft listing, live-session lot, or in-person stock record linked to the item or batch |
| Located                    | A physical location code is assigned and retrieval is tested                                     | Location code that does not depend on memory                                           |
| Sale-ready and findable    | The selected venue's readiness gate is complete and the location matches the stock               | Ready date, venue, sale-record ID or internal reference, price, and location           |

The states make waiting visible. A batch stuck in *received* is different from one fully
prepared but waiting for a location. That distinction shows where the queue is stuck without
pretending every delay has the same cause.

## Make the condition decision at intake

Use the chosen venue's current condition standard when it supplies one. If it does not, use a
written internal standard. Record the source and date; for an internal standard, name its owner.
If condition is uncertain, move the item to an exception state until a named reviewer resolves
it. Do not default to the better condition simply because that moves the item forward.

Give every condition exception an owner and review date. If the owner cannot resolve it by that
date, escalate it to a named second reviewer or remove it from the saleable workflow. Separation
without a decision deadline only creates a quieter backlog.

Physical separation can help when condition differences are easy to confuse. Separate bins,
dividers, sleeves, or labels are all valid if they keep the categories distinct. The rule is not
that every operation needs the same storage method; it is that an uncertain or played item cannot
quietly re-enter the normal sale-ready path.

Material flaws should be visible in the buyer-facing presentation and sale record through the
means appropriate to the venue and item. Preserve that record for any later customer response.

## Assign location before inventory becomes sale-ready

Every sale-ready unit or batch needs a retrievable physical address. A simple code such as
`B07-A` might mean bin 7, section A; the code is invented, and yours should match the storage
you actually use. Put the same code in the inventory or sale record and on the physical
container.

Two broad systems can work. A set-and-alphabet system makes the shelf understandable without
software but requires new items to be merged into existing order. A batch-and-code system lets
new inventory remain together but depends more heavily on accurate records. Choose according
to update effort, pick reliability, and the amount of software dependence you can tolerate.

Test the rule plainly: can someone retrieve the stock represented by the sale record without
asking where you remember putting it? If not, the inventory is not sale-ready.

## Measure completion capacity

Use one unit throughout the workflow: individual cards, sealed products, or consistent batches.
Activity such as scans or drafts does not count as completed capacity. Count only
units that reach *sale-ready and findable*.

Choose a representative baseline period and calculate:

**Weekly completion capacity = units made sale-ready and findable ÷ weeks in the baseline
period**

The baseline must contain more than zero weeks. Completed units may be zero; that produces zero
weekly capacity and triggers an intake pause and workflow review.

With no history, run the full workflow for one ordinary week, count only sale-ready/findable
completions, and label that first result provisional. Replace it after more ordinary weeks are
recorded.

This measured capacity replaces the temporary intake boundary used in [Chapter 4.1](/chapters/4-1-sourcing-the-ladder). A sourcing
plan may accept less than the capacity when cash or demand is the tighter limit. It should not
accept more merely because a good lead appeared.

## Put a ceiling and an age on the backlog

Track the queue in the same unit as capacity:

**Net backlog change for the review period = units received + units returned to the workflow for
rework − units made sale-ready and findable − other recorded exits during that same period**

**Backlog weeks = queued units ÷ measured weekly completion capacity**

Use one review period and one workflow unit for every term. A returned-rework entry applies only
when a unit had previously left the queue as a valid completion; failed first-pass work remains in
the queue and is not counted as either a completion or a rework return. Name other exits such as a
return to the seller, disposal, or transfer, and count every event once. Measure queued units at the
review point. If weekly capacity is zero, backlog weeks is not computable: pause intake and recover
the workflow instead of dividing by zero.

Suppose capacity is 60 units a week and 150 units are queued. The backlog is 2.5 weeks. If another
90 units arrive before any completion, returned rework, or other exit, the queue becomes 240 units,
or four weeks of work. Every number is invented.

Write two limits: maximum backlog weeks and maximum sale-readiness age. Sale-readiness age runs
from the receipt date until the item becomes sale-ready/findable; moving it to another state does
not reset the clock. A queue can stay under its workload ceiling while one difficult item quietly
ages, so both views matter.

Choose the first limits from your own constraints, not an industry benchmark. The backlog-weeks
ceiling should leave enough room to recover inside normal owner hours without breaking sourcing,
space, cash, or service commitments.

Set the age limit to trigger a review before stale buyer evidence, unresolved condition, a missed
venue window, or tied-up cash makes the original plan unreliable. At each baseline review, compare
both limits with actual completion and the oldest waiting item. Revise the policy deliberately
rather than moving a deadline to hide a breach.

When either limit is breached, use a prewritten response: pause or narrow new acceptance, schedule
a defined recovery block, and investigate which state is accumulating. A queue alone does not
justify buying a tool; a separate bottleneck review decides whether added capacity fits.

## Write the workflow

Finish with one operating rule in four blocks:

**Condition control:** Standard/source/date \_\_\_; exception state \_\_\_; decision owner \_\_\_; review
date \_\_\_; escalation \_\_\_.

**Sale-ready and location control:** Workflow unit \_\_\_; selected venue \_\_\_; required sale record
\_\_\_; readiness passes when \_\_\_; location format \_\_\_; retrieval passes when \_\_\_.

**Capacity and backlog:** Measured weekly capacity \_\_\_ units based on \_\_\_; backlog ceiling \_\_\_
weeks because \_\_\_; maximum sale-readiness age \_\_\_ from receipt because \_\_\_; breach response \_\_\_.

**Review ownership:** Weekly review owner \_\_\_; next review \_\_\_.