Do You Need a Client Portal? A Practical NZ Checklist
Use request patterns, access needs, client trials and complete costs to decide whether a portal is justified.

The practical answer
A portal is worth assessing when a repeated client task matters, staff can keep its information current and a trial improves the whole journey. A simpler form or existing product may be enough.
Discuss your client or staff portal requirements, users and existing tools so we can define a useful website or web app scope. Discuss your website or app.
A client portal is worth considering when clients repeatedly need the same private information or tasks, and the current route creates measurable friction. It is not automatically better than email, a well-designed form or a feature already included in your software.
Check the job the portal would do #
| Question | Evidence to collect | A simpler option to test |
|---|---|---|
| Do clients repeatedly ask for status? | Count requests and identify which status is missing | Clearer scheduled updates or an existing product’s status view |
| Are documents repeatedly missing or misfiled? | Record request, upload and review failures | A clearer checklist and controlled upload flow |
| Do clients need several ongoing actions? | Map tasks, frequency and access requirements | A task-specific form if the journey happens only once |
| Can staff keep the information current? | Name the source system and update owner | Fix the internal process before exposing its status |
| Will clients use the proposed route? | Observe representative users completing a task | Keep an assisted route where needed |
Example: a document request, not a whole new system #
In a fictional professional-services workflow, a client sees three outstanding requests, supplies one file and sees “received, awaiting review.” A staff member checks it, accepts it or explains what is missing. The client then sees the next step. That is a useful bounded journey; messaging, payments and a full dashboard can wait.
Measure the complete request: staff preparation, client effort, review, corrections and follow-up. Do not assume fewer emails means a lower total workload.
Test access and adoption before launch #
Test an expired invitation, forgotten access, a representative acting for multiple entities, a file submitted to the wrong request and an attempt to access another client’s record. Review the server and file permissions, not just the visible menus.
Watch a new user complete the journey on a phone. Record where they need help; there is no defensible universal rule that a two-minute login loses half your clients. Improve the actual friction and keep an appropriate alternative for people unable to use the portal.
Compare the complete cost #
Ask for setup, identity, file storage, migration, integration, training, support and future changes. Compare current packaged-product plans against a scoped custom proposal over the same period. Include the effort to keep status and requests accurate. Use consistent NZD and GST treatment in the comparison.
Decide whether to proceed #
A portal is a stronger candidate when the repeated task matters, access can be controlled, staff can keep the data current and a trial shows a better experience. If the interaction is occasional or the process itself remains unclear, improve that first.
Use the minimum portal feature guide to define a first release and the option comparison to choose how to deliver it.
A useful companion: Automation ROI Calculator.
Other articles worth reading

What to Include in a First Client Portal

What a Client Portal Should Replace in Email — and What It Should Not

