What a client portal changes for an architecture practice
A client portal gives an architecture practice one file per project holding every conversation, the current version of every document, and a record of who approved what and when.
A client portal gives an architecture practice one file per project holding every conversation, the current version of every document, and a record of who approved what and when.

A client portal gives an architecture practice one file per project: every conversation about that project, one document library that always shows the current version, and a record of who approved what and when. Ziggu brings those together in one environment carrying the practice's own branding, so most of the back and forth leaves the inbox and the client keeps sight of the project.
A client portal gathers an architecture practice's project communication into the file of the project it belongs to, split by topic and by who is involved, so a permit question no longer sits between a supplier quote and a newsletter.
An architect's inbox collects everything at once: clients, contractors, engineers, authorities and spam. Finding a permit decision from three weeks ago turns into a search.
In Ziggu a project carries as many conversations as the work needs. One on the permit, one on the finishes, one with the contractor that the client never sees. Each has its own participants and rights, the team can leave internal notes inside it, and email keeps working: messages that still land in the inbox get forwarded into the project, where they sit with the rest.
Maarten Makelberge, owner of Studio Mowk Interior Design, describes what he was looking for: “I wanted all project information available centrally in one place, so that everyone, the building team as well as the client, can find everything and work together without information getting lost in endless email chains.” (Translated from Dutch.)
What that looks like in an interior design practice is set out in the Studio Mowk story.

A building project produces hundreds of documents: drawings, technical plans, specifications, contracts and permits. The client portal is where those versions come together, so nobody arrives on site with an outdated drawing.
That is where an email workflow breaks. A contractor keeps building on the drawing he received last, not on the one that was revised since. The cost of that lands on site, not in the inbox.
In Ziggu the current version sits at the top of every document, and you can see who opened it. Rights are set per party: the client sees what concerns them, the contractor gets the technical set. The client keeps access to the file for years after completion, when a plan or a certificate is needed once more.
For a practice working with the same partners on every job, that settles an argument in advance. Who can reach what is fixed in the project instead of arranged by email.
Architects let clients follow along through the project milestones, and let them approve through choices presented in the client portal and recorded with a name and a date. Following along and approving are two different things, and a portal does both.
Following along is the timeline. In Ziggu the client sees the milestones of their project, which phase is finished and what comes next, alongside project news, the financials and the answers to the questions clients always ask. That is where the weekly status email and half the phone calls go.
Approving is the record. On a material choice, a change order or a finished drawing, Ziggu puts the question to the client and keeps the answer: who, what, when. That is the difference between an agreement someone remembers and an agreement that stands.
Underneath sits the log. Every action by every user is kept, and your client can open that log as easily as you can. It is not a file the practice keeps on the client, it is one record both sides can point at.
What that means for a practice working with contractors and subcontractors is on the page about Ziggu for architects and contractors.
The difference between email with a shared folder and a client portal is not one feature. It is where the truth sits. With email it sits spread across the inboxes of everyone involved. With a portal it sits on the project.
| Aspect | Email and a shared folder | Client portal |
|---|---|---|
| Communication | Scattered threads, missed messages | Conversations per topic, inside the project file |
| Documents | Versions side by side, folder hunting | Current version on top, with a read history |
| Project status | Manual updates by email or phone | Milestones the client can check themselves |
| Approvals | An agreement in an email, retrieved afterwards | Who approved what and when, on record |
| Site reports | Typed up back at the office | Filled in on site, with a photo and an owner |
A client portal lets an architect write the site report where the visit happens, with a photo, a note and an owner per item, instead of typing it up at the office afterwards.
That double handling is why reports go out late. What was seen on site gets reconstructed from notes a day later, and the party that has to fix the item hears about it a day after that.
In Ziggu a report item is an item with an owner and a deadline from the start. The client follows what is theirs and confirms what is finished for them, without needing a separate tool. Handover and aftercare run on the same mechanism: the same list, the same owners, the same history.

Ziggu stores project data encrypted server-side on Google Cloud in Belgium, backed up daily across two clouds in at least two European locations. Access is set per project, multi-factor authentication is standard, and the Ziggu team cannot open your data unless you grant permission from inside your own account.
Laura Callewaert, Interior Architect at Hoprom, on her own experience: “We've seen both younger and older clients adapt to it immediately.” A client installs nothing and gets an email notification as soon as something is waiting for them.
A practice can set up a first project and try it inside the free 14 day trial, with no credit card. Most of the time goes not into the software but into deciding which documents and which milestones belong in every project as standard.