Customer portals: what to settle before you build one

A customer portal is a private part of your website, or an app, where customers sign in to see and do their part of the work: where their job, order or application is up to, the documents that belong to them, and the forms, files and signatures you need from them. Suppliers and contractors can have the same thing, each with their own view.

A good portal is not a second system. It is a window onto the system your team already works in, showing the same records, so nobody has to keep customers up to date by hand.

The signs are usually in your team's inbox:

• customers email or call to ask where things are up to
• your team copies updates from your system into emails
• documents get sent a second time because the first email cannot be found
• files arrive as attachments, in every format, to whoever the customer last spoke to
• a new contact at the customer takes over, and nobody knows what they have already been sent.

Each of those is work your team does to keep customers informed. A portal moves it to the customer's side, at a time that suits them.

Start with what customers ask about most, and leave everything else out of the first version. That usually means:

• status: where each job, order or application is up to, and what happens next
• documents: everything that belongs to the customer, in one place and in its latest version
• requests: forms and uploads instead of email attachments, filed against the right record
• sign-off: approvals and e-signatures inside the portal, recorded with who signed and when
• notifications: an email or text saying something changed, with a link back to the portal.

Send the link, not the document. A notification that says “your report is ready” and points to the portal keeps the file behind a login instead of in an inbox.

Give every person at the customer their own account, even when several work for the same company. Shared accounts hide who did what, and the Australian Cyber Security Centre (ACSC) warns that shared accounts increase security risks and make activity harder to track (opens in a new tab).

When several people from one customer use the portal, let one of them add and remove their colleagues. When someone leaves, their access can end the same day, without anyone having to email you.

Offer multi-factor authentication (MFA), and require it for anyone who can see personal or financial information. The ACSC calls MFA one of the most effective ways to protect business accounts. It also describes passkeys as more secure than passwords, and says they help stop people being tricked into signing in on a fake website.

The rule that matters most: a customer only ever sees their own records. It sounds obvious, yet it is where web applications most often fail. In the 2025 edition of the OWASP Top 10, a widely used list of web application security risks, broken access control is ranked first, and every application tested had some form of it (opens in a new tab).

A typical failure: someone changes the number at the end of a link and opens another customer's record. Test for it on purpose before launch, and check that:

• every page and every file checks who is asking on the server, not just by hiding things on the screen
• no file can be opened through a link that works without signing in
• a customer's colleagues see their company's records, and only those
• where it matters, your own staff see only the customers they work with.

If the portal holds personal information and the Privacy Act covers your business (opens in a new tab), Australian Privacy Principle 11.1 (opens in a new tab) requires reasonable steps to protect it from misuse, interference and loss, and from unauthorised access, modification or disclosure. A portal puts that information online, so these checks are part of meeting it.

Decide which system holds each thing the portal shows: job status in your operations platform, contacts in the CRM, balances in the accounting software. The portal reads from those systems through their APIs and writes what customers send back into them, so it never becomes a copy that drifts out of date.

If that information is still spread across spreadsheets and inboxes, sort that out first: a portal on top of scattered data shows customers the mess. Start with what the work should run on.

Every action in the portal should land where a person will see it: a submitted form becomes a task for the right person, an upload is filed against the right record, a signature moves the job to its next stage. The customer should see that it arrived and what happens next.

Accept only the file types and sizes you actually need, and keep a record of what each customer did and when. It settles disagreements, and it is the first thing you need if something goes wrong.

Many products come with a portal: CRMs, help desks, practice management and job management software. If the work already lives in one product and its portal shows what customers need, use it.

Build one when the work spans several systems, when the portal is part of the service you sell, or when customers need to do something a built-in portal cannot, such as an application that moves through your own stages and rules. That is when a custom portal earns its place.

A portal needs an owner once it is live. Someone should make sure that:

• customers who cannot sign in get help quickly, without anyone needing their password
• accounts of people who have left the customer's business are removed
• the access checks from before launch are run again after every change
• you look at what customers actually use, and what they still email about.

The emails that keep arriving are the best list of what the portal should do next.

Vetrox is an Australian IT company that builds customer and supplier portals as part of custom systems for businesses across Australia. Each person sees only their own jobs, documents and messages, every upload or signature lands in your system against the right record, and the portal reads the same data your team works in. If a product's built-in portal covers what you need, we will say so on the first call.