The typical client communication system at a small architecture firm looks like this: drawings go out as PDF attachments over email. Meeting notes go out via email. Questions come in via email. Responses go out via email. Somewhere along the way, the client's internal team starts forwarding things to people who weren't on the original thread, and now there are four versions of the SD set living in four different inboxes at the client's organization.
This is how most firms operate. It works, in the sense that projects get done. But it introduces friction at every stage and that friction has a compounding cost over the life of a project.
What a Client Portal Actually Is
A client portal is not a complex piece of technology. It's a dedicated space: separate from the firm's internal working environment — where clients can access information about their project: current documents, status updates, decisions that need their input, and communication history.
The key distinction from the typical setup: the client accesses a controlled, curated view of the project. Not the whole project folder. Not an email thread. A view that shows them what they need to see, organized the way they need to see it, with nothing extra.
What a real client portal should do:
Show current documents, not historical ones. The client should always be looking at the current set — not an attachment they received six months ago and saved to their desktop.
Organize information by project. Not by email thread, not by a shared drive folder with forty subfolders. By project, in a logical sequence.
Capture the record of what the client received and when. If there's ever a question about whether the client had a specific piece of information, the answer should be findable in seconds.
Support decision-making. Items that require client input should be clearly flagged, with context about what's being decided and what the deadline is.
Work for non-architects. The client's team may include a facilities manager, an executive, a board member, and a project coordinator. None of them are architects. The portal should be usable by someone who's never managed a design project before.
Why Most Firms Don't Have One
The actual reason is that building and maintaining a client portal has historically required either expensive software or a significant amount of manual effort. The enterprise platforms — Autodesk Construction Cloud, Procore. Have client access features, but they're built around the gc's workflow, not the design team's.
The workarounds firms use instead, a shared Google Drive folder, a Dropbox link, a project website built in Wix: have real limitations. They don't control access by role. They don't capture a formal record of what was shared. They don't flag items that require client action.
The result is that most firms default to email because it's the path of least resistance. Even though email is, objectively, a poor client communication system.
What Clients Actually Want
The instinct when thinking about client communication is to focus on what architects want to give clients. A more useful question: what do clients actually want to see?
In order:
Current project status. Is the project on schedule? Where are we in the design process? What's happening this week?
Current documents, what are the latest drawings? What are the current specs? If they have an internal team reviewing design decisions, they need a reliable way to share current documents with colleagues.
What they need to decide. Clients who are busy (which is all of them) want to know exactly what requires their attention. Not a fifteen-page status report — a clear list of open items that need their input.
A record of what's been decided. Clients who are engaged in the design process want to be able to review past decisions without digging through email archives.
Confidence that nothing is slipping. This is the meta-goal. A client who trusts that the design team has everything under control, and that they'll be informed of anything that needs their attention, is a client who approves things quickly and doesn't generate anxiety-driven check-in calls.
The Scoping Question
One of the most important aspects of a client portal is deciding what clients should not see.
Clients don't need access to internal design sketches and work-in-progress files. They don't need to see the full consultant coordination set. They don't need to be in the internal team communication channel.
What they need is a curated, professional view of the project at their level of involvement: the approved deliverables, the formal correspondence, the items requiring their decision.
Access control is the mechanism that makes this work. A client should see their project, at the level of access appropriate for a client. Nothing more, nothing less.
The Effect on Project Velocity
There's a practical argument for proper client access that goes beyond communication hygiene: it speeds up approvals.
A client who can access current drawings on their phone during a board meeting, pull up the decision item that needs their sign-off, and respond in the same session — that client approves things faster than a client who has to ask someone to forward them the right attachment and then find the relevant information in a PDF.
The design team's schedule often has more slack on the architecture side than on the client approval side. If client approvals are on the critical path. And they usually are: making it easier for clients to approve things has a direct impact on project velocity.
Getting There
You don't need enterprise software to give clients a better experience than email attachments. You need a system that's purpose-built for the way design projects work, one where the client sees their project, their documents, their decisions. One that you control.
Olumba's client access layer does exactly this: clients get a project-scoped view of what you give them access to, organized the way a design project is organized. Worth a look if client communication is a friction point on your projects.
