Project furniture carries two addresses at once. There is where the piece physically sits in the building you operate, and there is where it is going in the building being finished. Losing either one costs you; losing the relationship between them costs you more.
A companion piece covers the destination side — tracking FF&E inventory by room, floor and project phase. This one is about the storage side: what the location record has to hold, and what happens on the day those two addresses stop agreeing.
What the inventory record has to hold
Six dimensions, each answering a question somebody will ask during the project.
| Dimension | What it holds | The question it answers |
|---|---|---|
| Facility | Warehouse, zone, specific location | Where do I walk to? |
| Item | SKU, description, barcodes, aliases | Is this the right piece? |
| Quantity | On hand, allocated, on hold | How many can I actually use? |
| Owner | The customer the stock belongs to | Whose is it? |
| Project | Project record, destination, room, floor, kit, sequence | Where is it going? |
| Status | Location status, staging-zone state | Is anything stopping it? |
The one that trips people up is quantity. On hand, allocated and held are three different numbers, and a system that reports only the first will let you plan against stock that is already committed or already frozen.
On hand is not available
Say a project has 40 dining chairs on hand. Three were found scuffed at receiving and are held pending a disposition. Twelve are allocated to a release wave for floor 4 next week.
Available is 25. Not 40.
That gap is where over-promising happens. A project manager looking at 40 will tell the designer floor 5 is covered. The picker working the floor-5 wave will come up short, and the shortage will be discovered during a pick rather than during planning — which is a much worse moment to find it, because the truck is already booked.
Two habits follow:
Report the three numbers separately, everywhere. Internal views, client portal, exports. A single "quantity" column is a number that will be wrong at the moment it matters most.
Treat held quantity as a project signal. Held stock climbing on an active project is an early warning that the install window is tightening, weeks before it shows up as a missed date.
Naming locations for project work
Standard location schemes are built for picking efficiency — aisle, bay, level, position, optimised for travel. Project work adds a second pressure: large volumes of one project sitting together for months, and needing to be found as a group rather than as individual pieces.
What works in practice:
- Keep the underlying scheme. Do not invent a project-specific location language. The warehouse still has to run its other work in the same building.
- Use zones for project scope, locations for storage. A zone can mean "floors 4 and 5 of the Marriott job" while individual locations stay ordinary rack addresses.
- Reserve bulk floor space explicitly. Project freight often lives on the floor rather than in rack. Floor positions that are real, named locations behave properly in the system; floor positions that are "over by the north wall" do not.
- Do not encode the project into the location name. The building outlives the project. A location called MTL-MARRIOTT-01 becomes a lie the moment the next job moves in.
Our warehouse location naming conventions guide covers the general scheme; the project-specific part is the zone layer on top of it.
Putaway is where the two addresses first meet
The moment a carton moves from the receiving lane into storage is the moment both addresses have to be true at once: it now has a rack location, and it should already have a room.
That is why putaway tasks need a source as well as a destination. A task carrying only a destination cannot tell you whether the move happened — only where it was supposed to end up. With both endpoints recorded, the balance reflects a completed transaction rather than an intention.
It is also why the destination fields belong on the receiving line rather than being added later. A carton put away without a room is a carton that will be opened again.
The putaway workflow covers the mechanics; the project-specific discipline is simply that neither address is optional.
When the room matrix changes
It will. Floors get resequenced, a room type gets revised, a scope gets added. Somewhere between container six and container nine, 300 pieces that were going to floor 5 are now going to floor 7.
This is the test of whether your model actually works, because there are two wrong ways to handle it.
Wrong way one: edit the destination and leave the stock. The record now says floor 7 while the freight still sits in the floor-5 staging zone. Every subsequent decision is made against a location that no longer matches the allocation.
Wrong way two: move the stock and fix the record later. The physical move happens on a busy afternoon, the record update is deferred, and for some period the system is confidently wrong about where 300 pieces are.
The right way is unremarkable and is the whole reason to have a system: the re-sort is generated as relocation tasks. Each task carries a source and a destination, gets assigned, and updates the balance when it completes. The allocation change and the physical change are the same event rather than two events somebody has to keep in sync.
Practically, that means a room-matrix change is a piece of project work with a size you can estimate, not an edit somebody makes in a spreadsheet and hopes the floor hears about.
The limit worth stating plainly
WarePulse tracks quantity by item, lot and location. It does not maintain a serial number for each individual piece of furniture.
For most FF&E programs that is the correct granularity. You need to know that 40 chairs of SKU X are at these locations, that three of them are held, and that this group is going to floor 4 — not which specific chair is which.
Where it bites is a program that has to trace an individual piece through its whole life: a specific numbered artwork, a piece under an individual warranty, or a high-value item where the client requires per-unit chain of custody. If that is your requirement, settle it in scoping rather than discovering it at go-live. It is the first question worth asking on a high-value program.
A location-integrity checklist
Weekly, on an active project:
- Held quantity by project, trending — rising held stock is an early schedule warning
- Untagged received lines — lines with no destination that should have one by now
- Staging-zone occupancy against what is still inbound
- Locations holding project stock that sits outside its assigned zone
- Relocation tasks open longer than a few days, which usually means a re-sort stalled
The test that matters more than any report: pick a carton at random, and see whether the system can tell you both of its addresses without a phone call. See how the two are modelled together on the FF&E and project logistics page.