A client portal is a private environment where customers can share documents, follow a case or submit a request. It can help when those tasks recur and your team currently sends information back and forth. Start with the customer task rather than a list of modules. Our guide to custom software explains how to assess whether building is right for your business.
How does a client portal differ from an ordinary website?
A client portal presents information and actions belonging to a particular customer or organisation. Visitors need more than a way to sign in. The system must also establish which records each person can see and what they’re allowed to do with them.
A status page may answer a simple question. A portal becomes more useful when customers need to respond, supply documents or manage several requests. Don’t add an account to a task that can be handled safely and clearly without one.
Which examples help you define the scope?
The following situations are hypothetical uses. They illustrate tasks you could define, rather than customer results or price estimates.
A consultancy wants clients to approve documents. The client sees the version awaiting review, adds comments and records a decision. Agreeing what ‘approved’ means is part of the design. A download button alone doesn’t solve that.
A wholesaler wants business customers to request repeat orders. The portal shows agreed products and earlier orders. If availability still needs checking, the customer first sees ‘request received’ and only sees ‘order accepted’ after confirmation.
A documented TopDevs example is Mastone. Its property platform includes an investor portal alongside the administration environment and online brochures. Investors are a different audience from tenants. The case supports these features, but doesn’t establish a general development price or payback period for your portal.
| Customer task | First complete journey | What needs agreeing first? |
|---|---|---|
| Review a document | Open it, respond and record a decision | Version, authority and meaning of approval |
| Follow a request | Submit it and view its current status | Which source determines status and who responds |
| Request a repeat order | Select products, submit and receive confirmation | Pricing agreements, availability and corrections |
| Supply documents | Upload a file and check receipt | Permitted files, access and retention policy |
When is an existing package enough?
Start by investigating what your current CRM, industry package or accounting software offers. An included portal may fit if customers can carry out the exact task you need. Demonstrate exceptions too: a contact who works for several organisations, or someone leaving their employer.
Custom software becomes worth investigating when the existing journey doesn’t fit and adaptation or combining products won’t solve it. You might need permissions across several cases, your own approval process or information from different systems. A different brand style alone doesn’t necessarily justify rebuilding everything.
Create a clickable design of the main customer task. Ask someone unfamiliar with the daily process to explain what they think each status means. If you have to explain the distinction between ‘final’ and ‘submitted’, the design probably needs to express that more clearly.
How do you control access to customer information?
Signing in and having permission are different things. An authenticated customer shouldn’t automatically be able to open every document. OWASP recommends authorisation checks on each request, including files and other individual resources. Hiding a button isn’t a server-side access check.
Create a permissions overview around specific tasks. Who can read, upload, approve or invite another contact? Include people working for several customer organisations. Test with different accounts whether a copied document link or changed case reference reveals another customer’s information.
Think about departure and recovery too. An administrator should be able to revoke access and understand the effect on active sessions and shared links. Losing a sign-in method needs a recovery route that isn’t easier to misuse than normal authentication. Choose further measures according to the information and actions involved, and have the selected protection tested.
Limit employee permissions as well. Customer support might be allowed to resend an invitation without reading every document. The administration environment needs to make that choice possible.
What does the GDPR require for a client portal?
For organisations subject to the EU GDPR, there isn’t a universal portal checklist prescribing one hosting location or fixed log-retention period. Article 32 requires security appropriate to the risk; Article 5 links retention to purpose. Assess processing roles, processor agreements and any transfers outside the EEA. An EU server alone doesn’t demonstrate compliance.
Turn that assessment into design decisions. Which personal information is actually needed? What happens to a closed case? Who can restore a backup, and how will access be checked afterwards? Record the answers with the responsible person in your organisation. A supplier should explain which measures the software implements and which tasks remain with your team.
Don’t copy every document into notifications and logs for convenience. Design a notification around the action someone needs to take. An email can point to a new document without including its contents.
How does the portal work with your other systems?
Assign an authoritative source to each type of information. The portal might display a status from the planning system without managing that status itself. Agree how old displayed information may be and what customers see when an integration is temporarily unavailable.
Connecting software includes recovery after failed transfers. If a customer submits a request, it should remain traceable when the receiving package can’t be reached. Receiving a request and processing an order are different stages.
Decide where changes happen. If staff and customers can both edit an address, an old overnight import shouldn’t silently replace the new value. Have these situations demonstrated with sample data before using the process in production.
A mobile app isn’t an automatic requirement. Start with customers’ devices and tasks. Our guide to progressive web apps discusses what installation and offline use can and can’t add.
What determines cost and delivery time?
The price follows from complete user journeys, integrations and operational requirements. A document overview is a different assignment from cases with delegated authority and approvals. Adding up module prices without that context gives false precision.
Request an estimate covering design, development, data transfer, testing and introduction. Discuss hosting, maintenance and support separately. Our guide to software costs explains how to compare quotes against the same scope.
Plan your own work too. Someone must assess permissions, prepare customer communications and decide which documents will move. A credible schedule includes these dependencies alongside technical work. Ask the supplier to identify which untested integration or data-quality issue could still change the estimate.
How do you get customers to use the portal?
Test a complete task with a limited group of customers, from invitation through to confirmation. Ask where they get stuck and observe what help your team still provides. Measure completed tasks and recovery work, rather than just the number of accounts created.
Keep an agreed alternative available during the transition for customers who can’t proceed. Use those reports to improve the journey. A second inbox nobody monitors can create more work, so give someone responsibility for requests and support.
How do you actually get started?
Choose the recurring customer question you want to solve first. Gather examples and write down what the customer should be able to complete independently. Then compare an existing portal with the smallest complete custom option.
When building custom applications, we make that scope concrete. The code is and remains yours; operation and handover need agreements too. Book a call to discuss your first portal journey.
