Verdict first: slot naming is not a creative exercise. After 30+ WMS go-lives, the format I hand every client is the same — Zone (1 letter) – Aisle (2 digits) – Bay (2 digits) – Level (1 digit) – Position (2 digits), with O and I permanently banned from the alphabet, 0 kept strictly inside numeric segments, and one check digit tacked on the end. A hundred thousand locations encoded this way: no duplicates, no ambiguity, and a scanner flags a typo the instant it happens.
I've seen this exact failure three times. The worst was in 2021, at an auto-parts 3PL in eastern China — a brand-new 43,000-square-foot building, and the location code was decided one week before go-live by the site manager on gut feeling: four numeric segments, "zone-bay-level-position," like 01020304. Looks tidy, right? The problem: aisles ran from 1 to 14 and bays from 1 to 22. When a pick ticket printed 01020304, did the picker read "zone 1, bay 02" or "zone 01, bay 2"? During peak season, with over 9,000 pick lines a day, the mispick rate climbed from roughly two per thousand to over one percent. Then came cycle count: the system treated 0102 and 102 as two different locations, and one variance report dumped 3,000+ lines. The owner looked at the report, assumed inventory was stolen, and nearly called the police. Recoding the entire building took three full weeks, and the peak-season go-live slipped.
The second time was 2019, at a beauty e-commerce warehouse in southern China. They used the letter O as a zone code — Zone O. Pickers hand-copied transfer sheets, and "O-03-12" became "0-03-12" in sloppy handwriting. The WMS didn't stop it, because 0 and O were both legal characters and nobody had thought to write a rule about it. A batch of high-value serums got put away in the wrong location, orders couldn't be picked, customer service got hammered, and the whole building shut down for two days of reconciliation. The fix was one sentence: delete the twin pairs 0/O, 1/I, and L from the character set, forever.
Same root cause both times: the location coding scheme was invented the week before go-live, and nobody asked "how will a tired human misread this?"
Why Slot Naming Always Breaks After Go-Live
I've done post-mortems on a dozen coding disasters. It always comes down to three things:
First, no hierarchy. Pure running numbers (0001, 0002 … 9999) look simple and carry zero information. A picker staring at 0731 has no idea which zone or aisle it's in without asking the WMS. Worse, expansion: a new rack row gets added and there's nowhere to insert the numbers, so they get appended at the end and the code order detaches from the physical order permanently.
Second, no confusion-proofing in the character set. 0 vs O, 1 vs I, L vs 1 — on printed labels, on small phone screens, on handwritten sheets, these are the danger zones. Let a printer ribbon fade slightly and 0 and O become identical. This always detonates during peak season, because peak season is when temps are reading the labels.
Third, business attributes stuffed into the code. This is the counterintuitive one: people love embedding client, category, or ABC class into the code, like "A3" for a key account's zone 3. It feels clever. It's a trap — locations change occupants. The client in A3 leaves next month; do you rename the location? Iron rule: a location code describes the position, never the goods inside it. Business attributes belong in the location master data in the WMS, not in the code.
Five Steps to a Location Coding Scheme
This is the full playbook for a greenfield warehouse. Brownfield retrofits, jump to step 5 for the migration part.
Step 1: Freeze the zone map before you touch codes. Take the CAD drawing and cut the building into zones: A = bulk storage, B = pick module, C = receiving staging, D = outbound staging, E = returns. One-letter zone codes starting at A. Once frozen, zone codes never change. This is the foundation — if it shifts, everything on top shifts.
Step 2: Publish a character whitelist. The allowed characters are: letters A–Z minus O and I (kills the 0/O and 1/I confusion), digits 0–9. I'd drop L too — 1 and L are twins on small labels. Bake the whitelist into the WMS code validation so illegal characters get rejected at receiving.
Step 3: Fix the hierarchy with fixed-length segments. Recommended format: Zone(1 letter)-Aisle(2 digits)-Bay(2 digits)-Level(1 digit)-Position(2 digits), e.g. A-03-12-2-05. The critical detail: fixed length, zero-padded — aisle 2 is "02", never "2". Codes then sort naturally; pull them into Excel and you get physical order for free. Start levels at 1 (ground level = 1, not 0), and number positions from the aisle entrance inward, following the walking direction.
Step 4: Add one check digit. The math doesn't need to be fancy: weight the numeric digits alternately ×1 and ×2, sum them, take the last digit. The WMS verifies it on receiving, cycle count, and every move — one wrong digit and the transaction gets blocked. Cost: one extra character. Payoff: "misread one character" errors get caught by the system instead of by the customer. For any building over 50,000 locations, that one digit is worth its weight in gold.
Step 5: Print-test the labels, and map the old codes. Print three samples of every label type, scan each 50 times, then hand them to three temps who have never seen the scheme and ask them to read the codes aloud — any combination they misread goes back to the drawing board. Greenfield: done in one pass. Brownfield: build an old-to-new mapping table and keep the old codes as aliases in the WMS for at least three months, running both in parallel during the transition.
I use this comparison table in every client proposal:
| Scheme | Readability | Expandability | Error detection | Implementation cost |
|---|---|---|---|---|
| Pure numeric running numbers | Poor (no position info) | Poor (no room to insert) | None | Lowest |
| Hierarchical alphanumeric | Good (code shows position) | Good (reserved ranges) | Weak (human eyes only) | Medium |
| Hierarchical + check digit | Good | Good | Strong (system blocks) | Medium-high |
Under 50,000 locations, the middle option is fine. Above that, go straight to the third. Don't economize on the coding scheme — one mispick's customer complaint plus one recount's rework costs more than redoing the codes three times over.
Location Coding Pitfalls: The Go-Live-Eve Checklist
Six items from my go-live-eve checklist, each one paid for in real money:
- Is the WMS location field long enough? Some legacy WMS products cap the location field at 12 characters. You design a 14-character code and the import silently truncates it. Check the field length before you finalize the code length.
- Single-sided or double-sided aisle numbering? Both sides of an aisle have racks — don't let bay numbers collide. Convention: odd bays on the left, even on the right, or aisle number plus A/B face.
- Do levels start at 0 or 1? Pick one for the whole building and write it into the SOP. I recommend ground level = 1, not 0 — human habit keeps confusing 0 with O.
- Use a monospaced font on labels. 1 vs 7 and 3 vs 8 blur together at small sizes; no decorative fonts. And nothing under 24pt — in a deep aisle with dim light, tiny labels are invisible.
- Code order must equal walking order. Walk the pick path on site and confirm the codes increase in the direction people actually walk. If they're reversed, every picker does a mental conversion on every order.
- After freeze, no rogue "temporary" codes. The classic post-go-live move is inventing "T-prefixed temp locations." Three months later there are more temp codes than real ones. Temp codes go through the formal request process — or don't exist at all.
One thing you can do tomorrow: export your building's location codes tonight and run a screen — any 0/O or 1/I mixing, any variable-length codes, any client names embedded in codes. Fix each one you find; don't wait for peak season. One hour of work now can save three weeks of rework later.
By Lin Xiao, WMS Implementation Consultant
