Software & web · 3 min read
What a client portal should include (and what to leave out)
A client portal should answer the questions clients would otherwise email you about. Here's what belongs in a first version, what can wait, and the access rules that matter most.
Omer Farrukh ·
A client portal earns its place when it answers the questions clients would otherwise send you by email or WhatsApp: Where is my project? Did you get my file? What do I owe? Every feature should be judged against that.
We run our own client, team and admin portals, and build them for other businesses. Here's what we've found belongs in a first version.
The core: status, files, invoices, requests
Overview. A single screen showing the client's open work, what's due next and anything waiting on them. If a client only ever sees this page, it should still be useful.
Projects with a clear status. Every project needs a small, fixed set of statuses that mean the same thing to you and the client, such as In progress, Waiting for you, Delivered and Completed. Resist inventing a new status for every edge case; a vague status creates more questions than no status at all.
Files in both directions. Clients need to upload briefs and revisions, and download deliverables. Keep files attached to the project they belong to, and store each client's files separately so one client can never reach another's.
Invoices and payment status. Let clients see what they've been invoiced, what they've paid and what's outstanding, and download the invoice as a PDF. This one feature removes a surprising number of "can you resend the invoice?" messages.
A way to ask for new work. A short request form (what they need, when they need it, attachments) that creates a proper record on your side is better than a request buried in an email thread.
Worth adding next
- Messages per project, so conversation stays attached to the work instead of scattered across inboxes.
- Revision requests as a tracked item with notes and files, rather than a reply that's easy to miss.
- Email notifications when something changes, so clients don't have to keep checking.
- Announcements for things that affect every client, such as holiday closures.
What to leave out of version one
- Anything you don't do consistently yet. A portal exposes your process. If deadlines are usually agreed on WhatsApp, a "timeline" feature will show gaps rather than fix them.
- Internal information. Costs, margins, internal notes and who is working on what behind the scenes don't belong in the client's view, even hidden behind a toggle.
- Chat that competes with where clients already talk to you. If your clients live on WhatsApp, a portal chat nobody opens just adds another inbox to check.
- Complex account settings. Name, email and password or sign-in link are usually enough.
Access control is the feature
The most important part of a portal is the part clients never see: the rules about who can see what.
- Enforce permissions in the database, not just the interface. Hiding a button is not security. Each query should only be able to return rows that belong to the signed-in client.
- Decide field by field what each audience sees. For example, a client may see their price and payment status but never your cost or your contractor's details.
- Keep an audit trail of who changed what, especially on anything to do with money.
- Make sign-in simple and safe: email links or passwords with proper reset, and no shared logins.
Build on what already works
Many businesses already track this information in a spreadsheet. That's a good starting point, not a problem: the spreadsheet shows exactly what data exists and which rules the business follows. A portal can start by reading that data and grow into its own database when it needs to.
If you're thinking about a portal for your clients, contractors or partners, tell us who needs to see what and we'll suggest what a sensible first version looks like.
Filed under Client portals · Web applications