A partner portal gives architects, contractors and suppliers scoped access to one live project instead of forwarded copies, which is what stops partners building from an outdated drawing.
A partner portal is a workspace where a company gives its external partners direct access to a project, with the rights set per partner. Architects, main contractors, subcontractors, suppliers and installers log in and see the part of the project they work on. Nobody forwards them a copy.
That last sentence is the whole difference. A shared drive holds documents. An email thread holds a conversation. A partner portal holds the project itself: the current drawings, the approvals attached to them, the tasks each company owes, and the dates those tasks hang off.
The word portal does a lot of work in software, and most of what it names is unrelated to construction. In channel sales, a partner portal is where resellers download marketing material and register deals. In construction and property it means something narrower and more useful: the place where the companies building the thing and the company selling it work off the same record.
A client portal and a partner portal sit on the same project and serve different audiences. The client portal belongs to the person buying: a homebuyer, a tenant, the client commissioning a fit-out. The partner portal belongs to the companies delivering the work.
The confusion is fair: both let outsiders into a project that used to be internal. What separates them is what each audience may see, and what happens when they act.
| Client portal | Partner portal | |
|---|---|---|
| Who logs in | The client buying the project | The companies delivering it |
| What they do there | Follow progress, choose options, approve | Upload, coordinate, mark work done |
| What they may see | Their own unit or contract | Their own scope, across the project |
| What goes wrong without it | The client calls for an update | Partners build from an old drawing |
Running both on one project is normal. Running them on two disconnected systems is where the cost shows up: the buyer approves a finish in one place, the subcontractor reads the specification in another, and someone carries the decision across by hand. That someone is usually a customer advisor, and hand-carried decisions are the ones that go missing.
Partners work from the latest version when the drawing has one address and that address announces its own changes. Emailing a revision creates a copy, and a copy stops updating the moment it lands. A partner portal replaces the copy with a link: the newest version is the only version anyone can open, and the notification goes out when the file is uploaded, not when somebody remembers to forward it.
Three things have to be true for that to hold on a real project, and none of them is about storage.
The document needs one home, not a home plus a mirror on the site manager's phone. Access needs to be granted by role, so a subcontractor joining in month nine gets the current set and not the set from month one. And the approval has to sit next to the file, because a drawing without its sign-off is just a drawing that somebody has seen.
That third point is where most tools stop. Belgian general contractor DCA runs approvals and their notifications through the same portal its buyers use, and its customer advisor describes what that changes.
“We upload documents, customers approve them on the Ziggu platform, and we immediately get a notification that everything is signed. The site manager and subcontractor are also automatically informed. So everyone always has the correct, approved document in their hands.”
Mieke Mertens, Customer Advisor, DCA
The full account of how DCA set that up is in the DCA success story.
Teams treat the wrong-version problem as a filing problem and buy storage to fix it. Storage was never the issue. In most cases the correct drawing is sitting in the correct folder, correctly named, while three companies work from the version that reached their inbox in March.
Filing controls where the truth lives. Distribution controls who is standing next to it. A naming convention, a folder tree and a version number all describe the file. None of them reaches the electrician.
A partner portal succeeds or fails on what each partner sees when they open it. Give a kitchen supplier the whole project and they get a wall of information about ninety units, four of which are theirs. They look once, decide it is not for them, and go back to email. Adoption dies quietly, and nobody files a complaint about it.
Rights per partner is the fix, and it is finer than an on-off switch. The useful version scopes access three ways at once: which projects a partner is on, which parts of those projects they can open, and whether they can act or only read. In Ziggu, the partner portal sets those rights per partner, and every action in the project is written to the log, so who opened what and who approved what stays checkable long after handover.
The side effect matters as much as the access. A partner who sees only their own scope is a partner you can add without a conversation about confidentiality, which is what makes it realistic to put fifteen companies on one project instead of the three you trust most. Coordinating partners on a project covers how that works day to day.
A partner portal earns its setup when the same partners come back across projects, and when the work involves approvals someone will be asked about later. On a one-off job with two subcontractors you have worked with for a decade, it adds a login and solves a problem you do not have.
The honest test is not how many partners are on the project. It is how often an answer has to be given twice because the first one went to one person. Count that for a fortnight. If the number is low, the coordination is working and a portal is overhead. If it is high, the plan version is already drifting and nobody has noticed, because drift only becomes visible on site.
