The designer does not operate the warehouse. Neither does the procurement lead, the owner's representative, or the project manager who has to tell an owner whether floor 6 can start on the 14th.
All four of them need to know what is in the building, and all four currently find out by emailing someone who has to stop what they are doing and go look.
A client portal is not a nice-to-have on a project of any size. It is the mechanism that removes a recurring interruption from the warehouse and a recurring delay from the project. But it only works if it answers the questions these people actually ask, which are narrower and more specific than a generic inventory view.
The four questions
Across hospitality, senior living and commercial fit-outs, project-side questions collapse to four.
"Has it arrived?" Asked about a specific PO or a specific vendor shipment, usually because the designer is chasing a vendor and needs to know whether to escalate. The answer needs to be at line level, not shipment level — "the container arrived" is not the same as "your 42 dining chairs arrived", and on a mixed container it is often not even close.
"Is it damaged?" Asked after a vendor mentions a rough transit, or before a phase commits. What is needed is not a yes/no but the specific pieces, the nature of the problem, and photographs. A designer approving a repair-versus-replace decision cannot make it from a status word.
"Can we release floor 6?" The scheduling question. It needs completeness against a scope: is everything for those rooms present, cleared and available, or is something held? A single held item is the difference between a productive install day and a wasted crew.
"What is still outstanding?" The procurement question. Expected but not received, by vendor, so the chase list writes itself.
A portal that answers those four well is more useful than one that exposes fifty screens.
What has to be visible
Working backwards from the four questions, the minimum useful surface is:
- Inventory by item, with quantity, allocation and what is actually available
- Receipts, showing what has arrived and what is still expected against each
- Orders and their fulfilment status
- Exceptions raised on their account, with current status
- Documents attached to their account
Two things about availability deserve emphasis, because they are where portals most often mislead.
Available is not the same as on hand. If 40 chairs are present and 3 are held pending a damage disposition, a portal that shows 40 has given the project manager a number they will plan against and be wrong about. Showing on hand, allocated and available separately is not extra detail — it is the difference between a useful figure and a misleading one.
Held has to be visible as held. A project team that can see a hold can plan around it. A project team that discovers the hold on install day cannot.
Where access should stop
The instinct when building a client portal is to expose more. The correct instinct is the opposite: expose exactly what answers the question, read-only, scoped to that client.
Three boundaries worth holding:
Read-only. A designer changing an inventory quantity is not a feature. If they believe a number is wrong, the right path is an exception record that a warehouse operator reviews — which also creates the trail explaining why the number changed.
Scoped to their own records. In a multi-client building this is not just a courtesy, it is the basic requirement. One client seeing another's inventory is a commercial incident.
No internal-only detail. Operator names on individual transactions, internal cost fields, staffing information and internal notes belong to the warehouse. A portal that leaks them creates conversations nobody wants.
The client portal page covers how this scoping works generally, beyond project work.
What a portal changes for the warehouse
The obvious benefit is fewer emails. The less obvious ones are larger.
It changes what "we'll check and come back to you" costs. When there is no portal, every status question consumes an operator for ten minutes and the client for half a day. At four questions a week across three active projects that is a meaningful share of a supervisor's time, spent on lookups rather than on the floor.
It raises the cost of a sloppy record — usefully. If clients can see the data, the data gets kept properly. Teams that turn on a client portal generally tighten their own receiving discipline within a month, because a blank destination field is now visible to somebody outside the building.
It moves the argument earlier. A damage exception the client can see the day it is raised is a decision they participate in. The same exception surfaced at install is a complaint.
A note on expectations
A portal answers "what is in the building and what state is it in". It does not answer "will my project finish on time", and presenting it as a project-management tool sets up a disappointment.
It also does not replace the relationship. The warehouse team still needs to flag the things a client should know before the client thinks to look — a container that arrived short, a vendor whose exception rate is climbing, a staging zone that is filling faster than planned. A portal makes routine questions self-serve; it does not make judgement calls self-serve.
Used that way, it is one of the highest-value things a project warehouse can offer, and one of the clearest differences between a 3PL that has done FF&E work before and one that has not.
See what client visibility looks like alongside the rest of the project chain on the FF&E and project logistics page.