A client portal reduces client email during a project by holding updates, documents, approvals and questions on the project itself, where the client can find them without asking.
Client portal software reduces the number of client emails during a project, and Ziggu is the client portal for teams that run project work for clients: architects, contractors, makers and manufacturers, creative agencies and planners.
The mechanism behind that is plain. Almost every email a client sends during a project asks for something they cannot see: where the work stands, which drawing is the current one, whether the choice they made last month was registered.
Put those three things on the project, where the client can open them at eleven at night, and the mail that asked for them stops being written.
In 2026, more than 2,500 companies work in Ziggu across Belgium, Luxembourg, the Netherlands and Portugal, and more than 42,000 clients log in to a portal rather than write to one.
Not every message disappears, and it should not.
Email keeps the record of a project inside the personal mailboxes of everyone who touched it, which is why that record is never in one place when somebody needs it.
A thread belongs to whoever sat on the CC list the moment it was sent. A colleague who joins two months in inherits nothing. A colleague who goes on holiday takes half the project with them.
The pressure this puts on a coordinator is not abstract. Cedric Hamerlinck, project coordinator at Fenixco, describes it in the Fenixco success story:
A mailbox can fill up quickly, whereby emails from customers do not immediately receive the necessary attention
That sentence names the failure precisely. The mail was not ignored. It landed in a place where attention is one person’s private resource and the queue is invisible to everyone else, including the client waiting at the other end of it.
So the client writes a second message, then calls, then copies in someone senior. Each of those is a new item in a new inbox, and not one of them adds anything to the project itself.
Reply-all makes it worse rather than better. Adding three colleagues to a thread does not share the work, it duplicates the reading and leaves everyone assuming that one of the others has answered by now.
The facts of the job get harder to reconstruct while all of that runs. Which version of the plan was approved. Who agreed to the extra work. When the client was told about the delay. All of it exists, in fragments, behind a search box that only one person can use.
The difference between email and a client portal shows up on four things every project produces, plus the record that is left afterwards.
The pattern repeats on each line. Email drops the item into a personal queue. A client portal puts it on the project.
| What a project produces | By email | In a client portal |
|---|---|---|
| Status updates | Sent when someone remembers, to that day’s CC list | Posted on the project, where the client looks it up |
| Documents | Attached to a thread, newest file unclear | One current version, with a record of who opened it |
| Approvals | Confirmed in a reply, found again later | Recorded on the item, with a name and a date |
| Questions in between | Wait in one person’s mailbox | Land on the project, open to the whole team |
| The record afterwards | Split across everyone’s inboxes | One log of every action by every user |
The last row settles arguments. In Ziggu, every action by every user is logged, and your client can open that log as easily as your team can.
Ziggu holds a client’s question on the project rather than in a mailbox, next to the update, the document and the approval that the question is usually about.
Three parts of the product carry most of that work. The wider picture of the client portal for project teams sits on its own page.
Every message about a project arrives in that project’s own inbox, visible to the whole team instead of to one recipient. Internal notes stay internal, so the team can work out an answer before the client sees anything. Mail sent to a team address is forwarded in, which means a client who writes an ordinary email anyway still lands on the project.
Files live on the project, not inside an attachment. The version on the project is the version that counts, and Ziggu records who viewed what, so nobody sends a message to ask whether the drawing arrived. That access holds for years after completion, which is exactly when aftercare questions turn up.
The portal your client logs in to carries your name and your colours, and so do the notifications and the emails it sends. For your client there is no third party in the room. A client who recognises the sender opens the update instead of mailing to ask what it was.
A client portal does not repair a project that nobody is updating. It shows what is put into it, so a milestone that moves in the field and not on the screen leaves the client reading a stale page, and back they go to email.
Two habits carry the rest. One person owns the update. An answer to a question that has been asked before goes on the project, never into a private reply.
Teams that keep both stop writing the same message again and again. Teams that skip them run a portal and a mailbox side by side.
