Client portals that answer the questions before customers ask
Most client portals are justified by the enquiries they stop. Work out which five questions your team answers every day, and you have the specification for the first release.
What is client portals?
Client Portals are secure, signed in areas where your customers can see their own documents, jobs, invoices and history, and complete tasks such as approving a quote or uploading a file without contacting your team. They suit Australian businesses fielding repetitive status enquiries, or sending sensitive documents by email attachment.
Get a fixed written quote- Typical timeline
- 9 to 16 weeks
- What drives cost
- The number of data sources being integrated, whether documents and signatures are in scope, the security requirements.
- Best for
- Businesses handling repeat status enquiries, documents and approvals by email
- You own
- The application, the documents and the client data
- Built with
- Secure authentication, document management, e signature, Xero and MYOB connectors
Your handover
The inbound work a client portal removes
Before designing anything we ask your client facing staff to keep a tally for a week: what did people ring or email to ask. The answers are remarkably consistent across industries. Where is my job up to. Can you resend that invoice. Did you get the documents I sent. What did we agree on the variation. Who is coming out on Thursday. Each of those is a two minute interruption that costs far more than two minutes because of what it interrupts.
- 01Client organisation and user access model
- 02Live job or matter status drawn from your operational system
- 03Document library with versions, permissions and viewing logs
- 04Quote and variation approval with electronic signature evidence
- 05Invoice, statement and payment status from your accounting package
- 06Secure upload replacing email attachments
- Notification templates that deep link into the portal
- Access and activity logging with retention rules
- Usage reporting so you can see what is worth extending
Showing a job status pulled live from your operational system is genuinely valuable
A portal turns them into self-service, and self-service is only useful when the underlying data is current. That is the part clients underestimate. Showing a job status pulled live from your operational system is genuinely valuable. Showing a status someone updates manually is worse than useless, because it will be wrong within a week and your customers will learn to ring anyway. So the first design question is never what should the portal show, it is which of your systems can be trusted as a live source.
- Job or matter status pulled live from the system that owns it
- Invoices and statements with payment status and a way to pay
- Document library with versions and a clear record of what was sent
- Quote and variation approval with a signature that holds up
- Secure upload replacing email attachments
- Contact and site details the client can maintain themselves
Documents, approvals and getting a signature that holds up
Document handling is the most common reason Australian professional and construction firms build a portal. Emailing contracts, statements and identity documents as attachments is convenient and quietly risky. Attachments get forwarded, sit in inboxes for years, and there is no reliable record of which version the client actually received.
In a portal, documents have versions, permissions and a viewing log
In a portal, documents have versions, permissions and a viewing log. You can see that the client opened the latest revision at 4:12pm on Tuesday, which ends a surprising number of disputes on its own. Approvals are captured with the identity of the approver, a timestamp, the exact document version and the client's IP address, then written to an audit trail that cannot be edited afterwards. Under the Electronic Transactions Act, that combination of consent, identification and reliable association with the document is what makes an electronic signature stand up. It is considerably stronger evidence than a reply saying yes go ahead.
How the engagement runs
How we launch a portal without losing the clients who prefer email
The failure mode is a portal that launches, gets used by eleven percent of clients, and becomes a second channel your team maintains alongside the first. That is worse than not building it. Adoption has to be engineered, and the biggest single factor is whether signing in is easier than sending an email.
- 01Enquiry auditA week of logged questions from your client facing team, categorised by volume
- 02Source system reviewWhich data can be shown live and which cannot be trusted yet
- 03Access modelHow a client organisation, its users and their permissions relate
- 04First releaseThe two or three highest volume enquiries turned into self-service, nothing more
- 05PilotA friendly group of clients, with their feedback shaping the second release
- 06Migration of communicationNotifications point into the portal, and email templates are updated to match
- 07Measure and extendTrack which screens are used, retire what is not, and add the next enquiry category
Two decisions on your side that keep the project moving
We use passwordless sign in links for low sensitivity access, deep links from notification emails that take someone straight to the document rather than to a login page, and a first visit that requires no setup wizard. We also accept that some clients will never use it. That is fine, provided the portal is the system of record and email is a view onto it, rather than the two drifting apart.
Invoices, payments and keeping accounting as the source of truth
Clients want to see what they owe and pay it without ringing anyone. That means the portal reads invoices, credit notes and payment status from Xero, MYOB or whichever package you run, rather than holding its own copy. The accounting system stays the financial record. The portal is a window onto it, refreshed frequently enough that a payment made this morning is reflected this afternoon.
The one thing we always design carefully is the overdue experience
Payment then happens through your existing gateway, with the receipt written back so nobody reconciles by hand. For businesses with progress claims or retentions, the portal can also show the claim history and what remains, which removes a whole category of phone call. The one thing we always design carefully is the overdue experience. A portal that greets a good client with an aggressive red banner over a fourteen day old invoice will cost you more goodwill than the reminder is worth, so the tone and thresholds are set by you and easily changed.
Privacy, security and what your clients are entitled to expect
A client portal concentrates personal and commercial information in one place, which raises the stakes. We build to the assumption that it will be probed, because it will be. Multi factor authentication is available and can be mandatory for sensitive document types. Sessions expire. Access is scoped so a user from one client organisation can never see another's records, and that boundary is enforced server-side on every request rather than by hiding links in the interface.
Broader controls sit alongside our security work
Under the Privacy Act 1988 and the Australian Privacy Principles, you are responsible for taking reasonable steps to protect the personal information you hold, and for being able to respond if something goes wrong. We support that with encryption in transit and at rest, Australian data residency where you require it, access logging that shows who viewed what, and a defined retention and deletion policy rather than keeping everything forever. If a notifiable breach ever occurs, the logs are what let you scope it quickly instead of guessing. Broader controls sit alongside our security work.
When a client portal is not worth building
If you have twenty clients and speak to them regularly, a portal solves a problem you do not have. Your clients value the call. Building a self-service layer to reduce contact with people who are choosing to contact you is the wrong instinct, and we will say so during scoping.
The rest of the answer
It is also the wrong project when the underlying data is not reliable. If job status lives in a whiteboard and a group chat, fix that first, because a portal will only broadcast the inaccuracy to your customers. That work usually looks like an internal portal or a better operational system before anything is exposed externally. Finally, if your requirement is really scheduling, a booking system is a narrower and cheaper answer. Portals pay off when volume is high and questions are repetitive, which is why they suit property managers, accountants and trades businesses running many concurrent jobs.
How we scope it
Four ways to scope your Client Portals project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Client Portals Pilot
One team, one process, proven before you commit further
Fixed written quote, agreed before work starts
- Client organisation and user access model
- Live job or matter status drawn from your operational system
- Document library with versions, permissions and viewing logs
Client Portals Rollout
The whole department, integrated with what you already run
Fixed written quote, agreed before work starts
- Everything in Client Portals Pilot
- Quote and variation approval with electronic signature evidence
- Invoice, statement and payment status from your accounting package
- Secure upload replacing email attachments
Enterprise
Multi site or multi entity, with the governance that needs
Fixed written quote, agreed before work starts
- Everything in Client Portals Rollout
- Notification templates that deep link into the portal
- Access and activity logging with retention rules
- Usage reporting so you can see what is worth extending
Client Portals Support
Changes, training and support as the business shifts
Rolling monthly, quoted in writing
- Changes and new requirements as the business shifts
- Training for new staff, recorded so it is reusable
- Patching, backups and a restore that has been tested
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does a client portal take to build?
Typically 9 to 16 weeks, and we aim to have a first release covering your two or three highest volume enquiries live well before the end of that. The timeline depends far more on how accessible your operational and accounting data is than on the portal itself. If job status has to be pulled from an older system with no interface, allow additional time for that work.
What determines the cost?
The number of data sources being integrated, whether documents and signatures are in scope, the security requirements, and how many distinct user types you need. Document management and electronic signature add meaningfully to the build. We work through the list in discovery and provide a fixed written quote, and we are happy to stage it so a smaller first release proves the value.
Who owns the documents and client data?
You do. Documents and data sit in cloud storage registered to your organisation, in the region you choose, and can be exported in bulk at any time. The application code is yours. We are collaborators with access you can revoke. Because a portal holds client information, we also document exactly what is stored and where, which is useful when a client asks you the same question.
Can clients use it on a phone?
Yes, and for most portals the majority of use turns out to be mobile. Documents render properly on a handset, uploads work directly from the camera, and approvals are designed to be completed one handed. For clients working on sites with poor coverage, key screens can cache so a document viewed earlier is still readable, with anything they submit queued until a connection returns.
How does it fit with our accounting system?
The accounting package remains the source of truth for invoices, credit notes and payments, and the portal reads from it on a frequent schedule. Payments made through the portal write back so nobody reconciles manually. We support the common Australian packages, and where you use something less common we assess its interface during discovery before committing to the integration.
What if clients simply do not log in?
That is the risk worth taking seriously, so we design against it. Notification emails deep link straight to the relevant document or job rather than to a login screen, sign in is passwordless where the sensitivity allows, and there is no setup process on first visit. We also report on usage from day one, so if a section is being ignored we can fix it or remove it rather than leaving it there.
Related services
Start with the five questions you answer every day
Send us your most common client enquiries and the systems that hold the answers. We reply within one business day with a fixed written quote.