Article
Customer Portal Development Guide
A login screen is the start of a customer portal. Define the useful customer task, the permission boundaries and the staff workflow before commissioning a dashboard.
A customer portal is a private part of your website where a customer can complete a useful task: approve a quote, upload a document, view a job, pay an invoice or manage a membership. Start with the task that currently causes the most repeated emails. A large dashboard with no clear job creates another system for people to avoid.
For a Melbourne or Sydney service business, the first release might be one reliable quote-approval journey. For a wholesaler it might be approved trade access. For a growing software product it might be customer accounts and organisation permissions. The scope depends on whose data is involved and what each person may do with it.
Check whether your current software already has a portal
Ask whether your CRM, practice-management system, booking platform or accounting software already provides the required customer view. Compare the customer journey and its access controls, not only the feature list. An existing portal may be the sensible purchase if branding and integration limitations are acceptable.
Custom development becomes relevant when customers must move through rules that the existing tools cannot support cleanly: several approvers, documents tied to a specific job, different sites inside one organisation, or a combined quoting and booking workflow. Our build-versus-buy framework helps compare the ongoing cost.
Define the permission matrix before the screens
Signing in establishes an identity. Authorisation decides what that identity may read or change. A customer who has a valid account must still be prevented from opening another customer's invoice by changing a link.
| Role | May access | Must be restricted |
|---|---|---|
| Customer | Their own quotes, files and job progress | Other customers' records and staff notes |
| Customer organisation manager | Approved sites and team invitations within their organisation | Other organisations and internal pricing controls |
| Assigned staff member | The jobs and documents needed for their work | Unassigned sensitive records and administrator settings |
| Business administrator | Approved operational management functions | Actions outside their responsibility, with high-impact changes recorded |
This is a starting example, not a universal security model. Write down how a customer is connected to a record and how access ends. The OWASP authorisation guidance recommends least privilege, denial by default and permission checks on every request. Hiding a button is not an access-control mechanism.
Choose one complete journey for the first release
Consider this example: a customer receives a quote notification, signs in, views the current version, accepts it and sees the next action. Staff see the acceptance against the same quote. If the quote changes before acceptance, the system applies the agreed version rule rather than silently accepting an old price.
The brief should specify invitation expiry, password recovery, duplicate invitations and what happens when a person leaves a customer organisation. It should also cover slow connections, expired sessions and an accessible way to recover from errors without re-entering a long form.
If payments are part of the journey, distinguish paying an invoice from granting product access. Read our Stripe feature guide for possible payment models and the booking system brief for confirmation and cancellation rules.
Treat files, exports and staff tools as part of the portal
Restricting the page is not enough if an uploaded file has a permanent public URL or an export endpoint returns every customer. Include file upload, download, deletion, search and bulk export in the scope. Agree what is collected, why it is needed, who can see it and how long the business intends to keep it.
Ask your developer how the backend enforces those boundaries. Firebase's role-based access example shows checks against data permissions and notes that server client libraries bypass Firestore Security Rules. A design using those libraries needs server-side authorisation as well as appropriate infrastructure permissions. Choosing Firebase does not automatically secure the application.
Where the proposed collection or sharing creates privacy questions, our Privacy Impact Assessment service can assess the project separately. Keep customer names, documents and other identifying data out of general website analytics.
Ask for evidence from both sides of the access boundary
- A customer can complete the allowed task and sees the correct next step.
- A different customer cannot open the record, file or export, even when the URL or record identifier is known.
- A removed team member loses the access defined by the agreed offboarding policy.
- A customer cannot promote their own role or change the organisation attached to a record.
- A staff member can resolve a customer problem without receiving unnecessary permissions.
- An important change is recorded, and the business has a tested recovery procedure.
Use a separate test environment and invented test accounts. These checks should exercise backend requests, not merely confirm that the menu looks different for each role.
Our published The Makeup Co case study describes Pro Membership, trade access, Stripe checkout and staff content management. It is an example of distinct customer and staff workflows in commerce. For your portal, ask for evidence against your own permission matrix and acceptance examples.
Make the quote include operating the portal
Price the complete first release: workflow design, identity and permissions, integrations, migration where needed, testing, deployment and staff handover. Also list recurring platform costs, the support arrangement and who owns the accounts and source code. A low build price is difficult to compare when these responsibilities are missing.
For an internal or client-facing business system, start with custom software development. For sales and customer-data workflows, see CRM development. A portal that is the core of a product belongs in an app development scope. An AI-generated portal that already exists may benefit from a production-readiness audit first.
Book a Discovery Session with the task you want customers to complete and a sample of the current manual process, with private data removed. AL Phesda is Melbourne-based and delivers remotely for Sydney and other Australian businesses; the scope and review process are agreed before implementation.
Customer portal development FAQs
Can we add customer accounts to an existing website?
Possibly. The review needs to cover the current stack, hosting, identity provider, data storage and required customer actions. Adding a login page alone does not implement a secure portal.
Can one customer have several staff logins?
Yes, if the system models organisation membership, invitation and removal rules, and each role's access. Include separate organisations in the acceptance tests so one customer's team cannot cross into another's records.
Should our portal replace the CRM?
Usually the first question is which system owns each record. A portal can provide a customer view while the CRM continues to own the sales process. Define synchronisation and conflict rules before building both systems around the same data.
How do we judge whether the portal was worth building?
Record the baseline for the chosen task: staff handling time, completion rate, repeated questions and errors. Compare those measures after release and include customer feedback. Account registrations alone do not demonstrate useful adoption.