pranjal.pareek
Reference · Interactive

The FC Process Map

Most process documentation describes the happy path. This is the other half — a working reference for what actually goes wrong on a fulfillment floor, who owns it, how the line keeps moving anyway, and how it gets closed out.

Why this exists

The happy path through a fulfillment center is short and gets all the attention: receive, stow, pick, pack, ship. The exceptions are where the actual operating discipline lives — a mismatched carton count, a phantom-inventory bin, a mis-sort, a wave that spikes past capacity near cutoff. Every one of those has to be handled without stopping the line, and the pattern for handling it repeats more than it first appears to.

I built this as a drill reference: something to walk a new supervisor through, or to check your own design against when standing up a new node. It covers the four pillars of forward and reverse flow — Inbound, Storage, Outbound, Returns — broken into 24 sub-processes, each with its happy path and four categories of exception.

How to read it

Every sub-process follows the same structure: pillar → sub-process → happy flow → exception, and every exception is filed into one of four buckets:

Each exception card carries a root cause, an owner, the operator buffer — the specific move that keeps the line running instead of stopping it — and the resolution path. Toggle Drill mode to blur the answers and test yourself before revealing them; useful for onboarding, less useful if you're just trying to look something up. The scope is deliberately narrow: standard, non-large-format parcels only — cold-chain/fresh and oversized/bulky flows run different playbooks (see cold-chain monitoring for that adjacent case).

FC Process Map

Exception drill reference — tap a pillar, then a sub-process. 24 sub-processes · 96 exception cells

SCOPE: standard, non-large-format parcels only. Cold-chain/fresh and oversized/bulky flows excluded.
Legend & buffer pattern library
L0 pillar → L1 sub-process → L2 happy/unhappy flow → L3 fields: bucket → root cause → owner → operator buffer → resolution path
Materialthe thing is wrong — damage, wrong item, packaging failure
Datarecord vs. reality diverge — qty mismatch, unknown SKU, sync lag
Executionpeople/SOP failed — mis-stow, mis-pick, mislabel, skipped check
Flowvolume vs. capacity — bunching, overflow, cutoff risk, asset down
Operator buffer is never "stop the line." Seven moves:
  1. Quarantine zone — segregate, main line keeps moving
  2. Exception bin/queue — park with a ticket, resolve async
  3. Rework cell — correct and reinject off the critical path
  4. Overflow staging — absorb the spike physically
  5. Manual fallback — degrade gracefully at a known reduced rate
  6. Re-sequencing — re-cut the wave, pull forward, reprioritize
  7. Bypass lane — route around the failure point
Single-file, no external dependencies — works offline. Print auto-expands every node.

Why it connects

This map is the substrate underneath the more visible systems: the dynamic task-allocation engine is largely a way of routing around the Flow-bucket exceptions here faster than a human coordinator can, and the Automation Intelligence Layer exists precisely because every new piece of hardware needs its own answer to "what happens when this specific step breaks." Understanding the exception taxonomy first is what makes the automation roadmap legible rather than a grab-bag of point fixes.