Business systems / Explainer
What should a small business client portal include?
A customer needs another copy of an invoice. Somebody else wants to know how their job is progressing, and a third is looking for the document you sent last month. Each request may be quick to answer, but the same requests keep coming back.
A client portal gives customers somewhere to find that information themselves. It could begin with documents and job updates, then grow to include approvals, payments or repeat orders when those are useful to the business.
We build bespoke customer portals around the systems a business already uses. I would start with the question you are most tired of answering. If a customer can sign in and find that answer, the first version is doing a useful job.
Start with the questions your customers repeat
Look through recent customer conversations and list what people ask for after a sale or job has started. Pick a few requests that happen often and have a clear answer you can provide online. A document download, a confirmed job stage or a request awaiting approval can each be a useful starting point.
For a service business, that might mean the invoice, the latest job update and the finished handover document. A customer could find all three without asking you to search an inbox. Choose the first features from the requests you actually receive.
Include the people who currently answer those requests. They know where information is missing, which messages need a conversation and what customers often misunderstand. A portal can make that knowledge easier to reach when the answers have an owner and a reliable source.
What belongs in the first version?
Keep the opening view useful. A customer should be able to identify their job or account, understand whether anything needs their attention and reach the information they came for. Use familiar wording for stages and actions.
I would keep the first release small. An upload area or payment button brings extra work behind it, so give each a reason to be there before adding it.
| Area | Useful first version | Possible later addition |
|---|---|---|
| Documents | The current agreed files for that customer | Uploads, version comparisons and document workflows |
| Job progress | A clear stage and latest confirmed update | Detailed timelines and automatic updates from more systems |
| Invoices | The relevant invoice and a reliable payment status | Online payment and reconciliation |
| Customer actions | One defined approval or response, if needed | Repeat ordering or more complex requests |
| Help | A clear contact route and useful record reference | Support tickets or a searchable help library |
Decide where each record comes from
A portal needs a clear relationship with the systems behind it. The invoice may come from the accounts package, the job stage from a CRM and the final document from an agreed file store. Map those sources before designing a dashboard full of numbers and status labels.
For each item, decide who can update it, when it becomes visible to the customer and how quickly changes should appear. If a connection refreshes periodically, make that behaviour clear. When a source is unavailable, the customer should see an appropriate message and staff should know what needs attention.
When we connect a portal to your existing systems, I want to see an update travel all the way through. Change a job stage, open the customer view and check what appears. Starting with one source makes that much easier to work through.
Check access to the actual record, including downloads
Signing in identifies the person. The portal also needs to decide which customer account, job and file that person is allowed to access. An employee of one customer may need different permissions from another contact at the same company.
OWASP recommends denying access by default and validating permissions on every request. It also covers protecting individual records and static resources. For a portal, that means access checks belong behind the page and download links, as well as in the navigation somebody can see.
Agree who can invite another contact, see invoices, download documents or approve work. Test with separate customer accounts and different roles. Changing a record reference or following an old link must not grant access to somebody else’s information.
Plan account recovery and removing access too. OWASP’s password-recovery guidance includes time-limited, single-use reset tokens. The sign-in method you choose needs an equally clear recovery and revocation process, with additional checks where the proposed actions warrant them.
Source: OWASP: authorisation guidance; OWASP: password-recovery guidance
Make an approval mean something specific
If a customer can approve work, show exactly what they are agreeing to. A useful record identifies the version, the decision and when it was made. If the document changes afterwards, decide whether that change needs a fresh approval.
The same care applies to payment status. Agree which system confirms that an invoice is paid and how that status reaches the portal. A customer returning from a payment page should see the result that has actually been verified, with a clear message if confirmation is still pending.
Try clicking twice, delaying an update and making a connection unavailable in the test setup. You need to know what the customer sees and where staff can check what happened. A tidy dashboard is little help if nobody can explain an approval recorded against the wrong document.
Test a real customer journey with safe example records
Use fictional or suitable test records while the process is being checked. Walk through an invitation, sign-in, document download and the agreed customer action on a phone as well as a computer. Ask somebody unfamiliar with the build to find the item without a spoken explanation.
I would include the checks below before inviting a wider group. Test the connections and permissions at the same time as the visible pages, so the prototype demonstrates the working process you are commissioning.
- Customer A can find their own current documents and job details.
- Customer A cannot open Customer B’s record or file, including by a direct link.
- Each contact sees only the actions their role allows.
- An expired sign-in or recovery link has a clear next step.
- Removing a contact’s access also blocks later attempts to retrieve their records.
- An updated document or job stage appears according to the agreed refresh behaviour.
- An approval records the correct version and a repeated click does not duplicate the action.
- A failed connection or missing file gives a useful message and a way to ask for help.
Invite a few customers and learn what they use
Begin with a manageable group and a named person looking after the rollout. Give customers a short explanation of what is available and a clear way to get help. Keep the existing contact route while you learn whether the portal answers the intended questions.
Measure something connected to the original problem: whether customers can find a document, how often they still ask for the same update and how much work staff spend keeping the portal current. A dashboard view count alone does not tell you whether it helped.
Agree the ongoing responsibilities as part of the build: hosting, connected services, access changes, support and how the business can export its records. Add the next feature when there is a clear customer need and a dependable process to support it.
The next time you resend the same file or type the same progress update, put it on your portal shortlist. That is a better starting point than a long feature list.
Sources
Checked on 22 October 2026.
- OWASP: authorisation guidance
Least privilege, denying access by default, checking each request and protecting access to individual records and resources. The portal roles and test examples are our proposed application of these principles.
- OWASP: password-recovery guidance
Recovery-token expiry and single-use requirements. A particular portal’s sign-in, recovery and access-removal process must be designed and tested for its scope.
- Flying Penguin: customer portal development
Our bespoke portal service, existing-system connections, documents, invoices, login options and prototype process.