# Customer Portal Development: What to Include in Your First Version - Link: https://five-bricks.com/blog/customer-portal-development/ - Published: 2026-10-12T09:04:05+00:00 - Author: 5B\_DEV A customer asks for the latest document. Someone finds it, checks whether it is approved and emails it over. The next day, another person from the same customer asks for an update. Nothing about either request is unusual. The repeated handling is what makes the process expensive to maintain. A customer portal can give customers direct access to that information. But putting a login screen in front of a folder does not resolve unclear ownership, outdated records or an approval process that lives in someone’s inbox. The useful starting point for customer portal development is a recurring customer task. Choose one that you can support from beginning to end, including the work your own team must do. That gives the first version a purpose and a boundary. ## **Find the request customers should not need to send** Look through recent support messages and account-management conversations. Group the requests by the action the customer wanted to take: download an invoice, check a delivery, approve a document or provide missing information. For each group, ask how often it occurs and why a person currently has to handle it. Sometimes the obstacle is access. Sometimes the information does not exist in a reliable form. A portal addresses the first problem much more directly than the second. Consider a hypothetical service business whose customers approve project documents. The customer needs to see the current version, understand what requires approval and record a decision. A page containing every historical file would technically provide access, but it would leave the important question unanswered: which file am I supposed to approve? Choose a task with an identifiable finish. “Improve customer communication” is too broad. “Let an authorised customer approve the current document and see that their decision was recorded” gives the team something to design and test. ## **Build the customer journey and the staff journey together** For the document-approval example, the customer journey might start with an invitation and finish with a confirmation. Between those points, the customer needs enough context to make the decision without calling the account manager. The staff journey is just as important. Someone must prepare the document, release it to the correct organisation and handle a rejection. If a newer version replaces it, the system must make the status of the old approval clear. A sensible first release could include: * Invitations and account recovery. * A list of relevant projects or requests. * The current document and its approval status. * An approval or rejection action with a recorded history. * A staff view for resolving exceptions and managing access. That is an illustrative scope, not a universal feature list. An order-tracking portal may need no document approval at all. Avoid adding messaging, analytics and online payments simply because other portals have them. ## **Decide which system owns each piece of information** Before designing the dashboard, establish where its information comes from. The accounting system may own invoice status. Your operations software may own delivery dates. Staff may maintain a project milestone in a separate application. The portal should not quietly become another place where people update the same record. If two systems allow changes, define which changes are permitted in each and how conflicts are resolved. Freshness matters as much as availability. A customer seeing yesterday’s delivery status needs to know when it was last updated. If an integration stops working, a reassuring green label can be worse than a clear message that the status is temporarily unavailable. For the first version, ask the development team to identify the source, refresh frequency and failure behaviour for every important field. These decisions affect both the estimate and the customer’s trust in the result. ## **Define access around customer organisations** One customer company can have several users with different responsibilities. A finance contact may need invoices but not project files. A project manager may approve work without being allowed to invite colleagues. Write down who can see and change each kind of record. Include what happens when someone changes employer, leaves a project or loses approval authority. Shared company logins make these distinctions difficult to enforce and obscure who made a decision. [OWASP’s authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege, denying access by default and checking permissions on every request. For a portal, the practical consequence is that hiding a button is not enough. The server must also reject an unauthorised request for the underlying document or action. Ask for permission tests covering at least two customer organisations. A valid login should never be treated as permission to retrieve another customer’s records. ## **Make exceptions visible instead of forcing customers to guess** A first version does not need to automate every unusual case. It does need to tell people what happened and how to proceed. Suppose a customer approves a document just as a staff member replaces it. Should the old approval still count? The answer belongs to the business process, not to a developer’s assumption. Similarly, a failed file upload should not leave the customer wondering whether the team received it. List the exceptions that would create operational confusion: an expired invitation, a duplicate submission, an unavailable source system or a decision made by the wrong person. Decide which the application can resolve and which need a staff member. For cases handled manually, make ownership explicit. A notification sent to a mailbox nobody monitors is not a support process. ## **Check whether customers will actually use it** Invite a small group of suitable customers to complete the chosen task with their normal devices and realistic information. Watch where they hesitate. Do not start by giving them a tour that explains every screen. For a portal replacing status emails, track successful self-service checks alongside the relevant support requests. For approvals, look at completed decisions and the reasons people still need help. Login counts alone say little about whether the portal is useful. Keep a route for customers who cannot complete the task online. Their questions may reveal missing information or a workflow that is not ready for self-service. A portal that merely moves work from your inbox into your customer’s inbox has not solved much. ## **Check existing capabilities before commissioning a separate application** Your current CRM, commerce platform or service-management tool may already offer customer access. Test it against the actual workflow before deciding to build separately. Pay particular attention to organisation-level permissions, integration limits and the effort required to keep information current. A custom portal becomes more relevant when the workflow crosses several systems or depends on rules the existing product cannot support cleanly. Our [custom versus off-the-shelf software guide](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) explains how to assess that wider decision. To discuss a portal with Five Bricks, bring one recurring customer request, the systems holding the information and the roles that need access. Use the [client intake form](https://five-bricks.com/client-intake/) to describe that workflow. It is a more useful basis for a first-version discussion than a list of dashboard features.