Bin location naming: 10 schemes that scale, 3 that don't, and the one I'd actually use

A warehouse manager I worked with had named his locations after landmarks. "Behind the press", "by the office", "next to the dock door", "the bay under the leak". For about three years it worked fine — eight staff, 60-odd locations, everyone could mentally map a name to a spot in under a second. Then they took on a contract that needed 240 new pick faces and seven agency pickers a day.

Within a month the wheels came off. New pickers asked, "where's the leak bay?" three times an hour. The team lead spent his mornings walking newbies around the floor. Cycle counts had to be done on paper because the WMS rejected names with spaces. They eventually paid a consultant £6,000 to re-label everything onto a proper scheme over a long weekend.

I've seen variations of that story enough times to know the lesson: a naming scheme is not a cosmetic decision. It's a piece of infrastructure. The wrong one survives until the day it doesn't, and the migration is always painful. So this post is the comparison I wish I'd had — ten schemes that scale, three that don't, and the boring one I'd actually pick for almost any operation.

What "scales" actually means

Before the list, a definition. A naming scheme scales if it satisfies four things:

1. Parseable by a human in under a second. A picker reading off an RF gun shouldn't have to think.
2. Sortable as text. A pick list that sorts alphabetically should walk you down the aisle, not zig-zag across the floor.
3. Stable when the layout changes. Adding a bay shouldn't force a renumber of everything downstream.
4. Printable on a barcode. Long enough to be unique, short enough to fit on a label without shrinking the font to 6pt.

Anything that fails one of those four is a hidden tax you'll pay for years.

10 schemes that scale

1. Zone-Aisle-Bay-Level-Position

The conventional WMS default. Example: A-12-04-3-2 reads as zone A, aisle 12, bay 4, level 3, position 2.

This is the format every serious WMS — ours included — assumes by default, and there's a reason. It encodes the entire physical hierarchy in five fields, sorts cleanly, and accepts new aisles or zones without affecting existing codes. The character cost is real (8–10 chars) but every character earns its keep.

The trade-off: it's overkill for a 40-bay site. If you've only got one zone and one level, you're padding most of the fields with zeros.

2. Zone-Letter-Aisle-Number

A-1, A-2, B-1, B-2. The "small warehouse" scheme. Two characters, no parsing needed, you can read it out loud over a radio.

This works beautifully for sub-2,000-bay sites with a single level and no real velocity zones. It also degrades gracefully — if you outgrow it, you can append fields (A-1-T2 for tier 2) without breaking the existing codes. I've watched a kitchen-equipment 3PL run on this format for eight years and never need anything more.

Where it breaks: above ~3,000 bays you run out of letter prefixes and start inventing two-letter zones, which sort weirdly (AA between A and B? Or after Z?). Decide that early.

3. Direction-coded

N12-E04-L3 — north aisle 12, east bay 4, level 3.

For non-rectangular spaces this is the only scheme that doesn't lie. Old multi-bay sites that grew by acquiring adjacent units, L-shaped buildings, sites with a mezzanine that overlaps half the ground floor — these don't have a clean "aisle 1 through 20" mental model. Compass directions reset that.

The downside: it requires staff to know which way is north on the warehouse floor, which sounds trivial until you realise half your team has never thought about it. Paint big N/S/E/W markers on the columns or this scheme creates more questions than it answers.

4. Coordinate grid

X12-Y04-Z3. Pure mathematics, no semantic content.

Coordinate grids shine when you have automation in the loop — AMRs, conveyor sortation, anything that needs to compute distances. The code itself encodes a position you can plug into a routing algorithm. Direction-coded gets you something similar but coordinates are the format the robots actually want.

For human-only operations, this scheme is colder than it needs to be. Pickers don't think in X-Y-Z. They think "third aisle on the left". Use this when robots dominate, not when humans do.

5. Pick-path-encoded

P0001 through P9999, where the number is the position along the optimum walking sequence.

Beautiful in theory. The pick list sorts numerically and that is the walking order. No travel-path computation needed at run-time. The cycle counter follows the same sequence.

In practice, this only works if your pick path is fixed. The first time you change a one-way aisle direction, or add a new zone, the entire numbering needs to be regenerated. I've only ever seen it work in highly engineered, low-change DCs — the kind where the layout is locked for five years. If that's you, pick-path optimisation tooling is what makes the scheme worth the rigidity.

6. Velocity-tiered

FAST-A12, SLOW-A12, MED-A12. The velocity tier is part of the code.

Tempting because it surfaces information at the worst moment to forget it — when you're putting a SKU away. A new starter putting a fast-mover into SLOW- knows something's wrong before they pull the trigger on the gun.

The catch: velocity changes. The SKU that was FAST in Q4 is SLOW by March. Either you relabel locations (expensive) or relocate SKUs (constant). Most operators end up doing the latter, and the velocity prefix becomes a stale promise. Use it only if you have a slotting routine that actually moves stock between tiers on a schedule. Otherwise the prefix lies and lying labels are worse than no labels.

7. Client-prefixed

CLIENT01-A12. The owning client is part of the bin code.

This is a 3PL pattern. The argument for it: scan a bin, the code itself tells you whose stock should be there, and your WMS can refuse a putaway that contradicts the prefix. Cross-contamination becomes a hard error.

It's a real win for shared-floor 3PLs where the alternative — soft client zones with no codified boundary — leads to "we put it next to the Acme stuff" mistakes that take a week to find. The cost is that you can't reuse a location for a different client without renaming it, which means client churn = relabel job. If your client base is stable, this scheme is gold. If you turn over 30% of clients a year, the labelling cost will eat you alive.

8. Floor-bay-tier

F1-B12-T3 — floor 1, bay 12, tier 3.

Multi-floor warehouses have a problem that single-floor schemes don't address: the same A-12-04 exists on three floors. Inserting a floor field at the front is the cleanest fix. It also forces pickers to read the floor first, which matches how you'd actually walk the route (lift up to floor 1, then find the bay, then the tier).

Don't omit the floor field "because we only have one floor right now". You'll add a mezzanine in year three and pay for it twice.

9. Aisle-letter / bay-number combo

A12, A13, B14. The "flat warehouse" scheme.

For a single-level pick face with no real height storage, this is genuinely all you need. Three characters, one barcode line, sortable, parseable. A discount retailer DC I know with 1,400 ground-level pick faces runs the entire site on this. Replenishment locations live upstairs on a separate scheme.

The risk is treating it as "good enough for now" when you actually have height storage on day one. If you have racking above you, your reserve and pick faces need different schemes or shared ones — not "we'll figure it out later".

10. Hybrid (BULK / PICK)

BULK-A12-04 vs PICK-A12-04. The functional purpose of the location is in the code.

This separates reserve storage from pick faces at the naming level. When you replenish, the system knows the source is bulk and the destination is pick — and the codes themselves disambiguate. It also forces an honest answer to "is this a bulk bay or a pick bay?" — the kind of question that's often fudged in practice ("it's pick, but we also store reserve there sometimes…").

The trade-off is the extra characters and the discipline of never letting a location be both. If you allow PICK-A12-04 to occasionally hold reserve, the scheme stops paying its rent. Combine this with proper pallet-equivalent capacity tracking and you get a really clean operating model — bulk holds N PEs, pick holds 1 PE, replenishment moves between them on a defined trigger.

3 that don't scale

Pure incremental

1, 2, 3, … through 100,000.

Sounds clean. Is a disaster. The code contains zero positional information. Bin 15,734 is meaningless without a lookup. New pickers can't predict where it is. A printed pick list sorted numerically gives you a walk that bounces all over the floor because location numbers and physical positions are unrelated.

Operators end up taping cheat-sheets to the wall ("aisle 12 is bins 8,400 through 8,700"). That cheat-sheet is the real naming scheme. The numbers are decoration.

Tribal names

by the office, the leak bay, behind the wrap station.

Works for a 60-bay shop with eight staff. Doesn't survive your first agency hire. Doesn't survive a WMS that disallows spaces. Doesn't survive the day you move the wrap station.

The deeper problem isn't the names. It's that tribal naming bakes institutional knowledge into the warehouse layout itself. The day your team-lead retires, half your locations become un-pickable until someone re-translates the names. I've seen this happen. The recovery cost dwarfs whatever was "saved" by not setting up a real scheme on day one.

Department-coded

ELECTRONICS-12, CLOTHING-04.

The seductive argument: it's self-documenting, you scan a bin and you know what category lives there. The fatal flaw: SKUs move between departments. A seasonal item moves from "garden" to "outdoor leisure" when the buyer reorganises the merchandise hierarchy. Now GARDEN-12 holds outdoor leisure stock. Multiply that across a year of category re-orgs and your location codes lie about half their contents.

Worse, you cannot put a "homewares" SKU in a CLOTHING- bay even if it's the optimal empty slot, because the code says clothing. Either you carry that operational tax forever, or you accept the codes mean nothing — at which point why have them?

The general rule: encode physical reality in the code, not categorical reality. Physical reality is stable. Categories move.

The one I'd actually use

For 90% of warehouses, the answer is the boring one: Zone-Aisle-Bay-Level-Position.

It's not glamorous. It's not optimised for any particular automation use case. It doesn't expose velocity or category or pick-path. It's just the format that does the four things a naming scheme needs to do, every time, without surprises.

Why it's the right answer for most operators:

It prints cleanly on a barcode. Eight to ten characters, dashes optional. Code-128 prints it at full size on a standard 50mm label. No font-shrinking, no two-line wraps. Your RF guns scan it without complaint.

It sorts to walking order. Sort by location code and you get zone, then aisle, then bay, then level. A pick list sorted that way walks you down the aisle pulling top-to-bottom — exactly how an experienced picker walks anyway.

It supports cycle counting routes. Generate a count list filtered to "zone A, aisle 12" and you've got a discrete chunk a counter can do in a session, with codes that match the printed shelf labels exactly.

It's robust to layout changes. Adding aisle 21? A-21-01-1-1 slots into the sort order at the right place. Adding zone D? Same. You don't renumber anything that already exists.

It's understandable to anyone with WMS experience. Hire a team-lead from a competitor — they've used this format before. Onboard a new agency picker — explain the five fields once and they're picking.

The only operators I'd push toward a different scheme:

• Pure 3PLs with shared floor: add the client prefix (scheme 7).
• Multi-floor sites: insert the floor field (scheme 8).
• Single-level flat warehouses under 2,000 bays: drop down to scheme 9. You don't need the extra fields.
• Operations with significant automation: consider coordinate grids (scheme 4) for the automated zones, conventional for the manual zones.

Everyone else: scheme 1. Boring is the feature.

A note on the migration

If you're reading this thinking we're on tribal names / incremental / department codes and we need to move — the migration is a planned weekend project, not a brave new world. Plan it like this:

1. Draft the new scheme with zones, aisles and bays mapped on a floor plan. Don't print yet.
2. Walk the floor with the draft and find the corners that don't fit. Mezzanines, weird columns, half-aisles. Fix them on paper before they cost you label re-prints.
3. Run the old and new codes in parallel for two weeks in your WMS. Every location has both. Pickers see both on the gun.
4. Pick a cutover weekend. Re-label, deprecate the old code, run for a month, then remove the old code from the data.

The mistake people make is treating it as an IT change. It's an operational change with an IT component. The real work is on the floor.

---

A naming scheme is one of those decisions that's invisible until the day it's expensive. Get it right early and you'll forget you ever made it. Get it wrong and you'll feel it every time you onboard, every time you cycle-count, and every time the layout changes.

If you're setting up — or rebuilding — a location structure and want it modelled properly from day one (zones, aisles, bays, levels, positions; with capacity and footprint tracking baked in), the bin-location config in Loaditude's warehouse installations is built around exactly this pattern. The boring scheme, done right.