Web applications / 03
Customer portal development: what to include in the first version
Customers ask for order updates, search email threads for documents and submit the same information again. A customer portal can bring these actions into one self-service journey. Without reliable underlying data and an owned process, however, it becomes another interface that staff must maintain manually.
Key takeaway
The first version should solve one frequent task from sign-in to completion. Define data sources and permissions before making a list of screens.
1. Decide whether customers need a portal
A portal is useful when customers repeatedly return to orders, documents or service requests. Count support questions such as “What is the status?”, “Where is my invoice?” and “How do I add a document?” When the information already exists but can only be reached through a manager, there is a concrete self-service opportunity.
A one-off purchase or occasional enquiry may need only a clear form and notifications. Mandatory registration adds effort that should be justified by value to the customer. Before commissioning custom development, check the customer module in your existing CRM or industry platform: it may cover the main workflow.
2. Build an MVP around a complete journey
An MVP is a minimal version for testing usefulness. For a service business, the journey might be: sign in → find a request → understand its status → supply a missing document. This is more valuable than disconnected sections with empty analytics or incomplete notifications.
Consider an illustrative example, not a client case: a company maintains equipment for several organisations. The first version shows each customer's requests, the next action date and agreed documents. A manager changes the status in the operational system and the portal displays it. Chat, loyalty programmes and a separate mobile app stay outside the pilot.
| Include | Reason | Defer until demand is validated |
|---|---|---|
| Sign-in and account recovery | Customers can return independently | Complex profile customisation |
| Requests and statuses | Answer a recurring question | Advanced analytics |
| Documents per request | Keep information in context | A general-purpose file archive |
| Contacting a manager | Handle unusual cases | A custom messenger |
3. Define roles and access boundaries
In a B2B portal, a person and an organisation are different entities. Several people may belong to one organisation: one views requests, another uploads documents and another manages access. Create a role–action–object matrix and describe invitations, departures and transfers between organisations before development.
OWASP identifies missing object-level authorisation as an API risk. Check permission on the server for each request or document; hiding a button or using a hard-to-guess identifier does not replace that check.
A practical acceptance test is to use an account from organisation A to request an object belonging to organisation B. The server must not expose the other organisation's data. Also test file downloads, exports and old links after access is revoked. These are baseline acceptance checks.
4. Assign a source of truth to each field
An order status may live in the CRM, documents in file storage and the user profile in the portal database. Decide where each field can change and how updates reach the portal. If both customers and managers edit the same data, define how conflicts are resolved.
Agree on acceptable update delays. Some statuses can use periodic synchronisation; others may need event notifications. During an external outage, the interface should distinguish no data from a loading failure and, where useful, show the last successful update time.
5. Understand what drives development cost
Cost depends less on screen count than on the rules behind each screen. One document page may require permissions, version history, file checks and an external storage integration. Several informational pages without those requirements may be much simpler.
To compare suppliers, give them the same scope: user journeys, roles, systems, data structures and acceptance criteria. Ask for development, migration, infrastructure, maintenance and assumptions to be explained separately. Unknown API capabilities should first be investigated through a small technical discovery task.
- Users, organisations and roles.
- The main journey and explicitly deferred features.
- Data sources, API documentation and test access.
- File, activity-history and notification requirements.
- Launch, support, backup and recovery plans.
6. Validate usefulness with a small customer group
Invite customers with real recurring tasks to the pilot. Ask them to accept an invitation, sign in, find a request and retrieve a document without coaching. Observe confusion, including errors, empty lists and mobile use.
Measure the proportion completing a useful action, status-related support questions and extra workload for managers. Registration counts alone do not show value. Compare similar customer groups and periods; a seasonal reduction in enquiries cannot be attributed entirely to the portal.
Before expanding access, verify account recovery, organisation boundaries, integration failures and restoration from a backup. Give the team a support guide and assign a product owner to decide which capabilities should come next.
Common questions
- Do we need a mobile app immediately?
- Not necessarily. A responsive web portal may cover the main tasks on a phone. Evaluate a dedicated app when there is a demonstrated need for particular device capabilities or a specialised usage pattern.
- Can we add a portal to an existing website?
- Yes, when the architecture and integrations allow it. The portal may be part of the website or a separate application with coordinated sign-in and navigation. The choice depends on the existing system and access requirements.
- Will a private portal improve search visibility?
- Private account pages are not intended for search results. Public service pages and helpful articles support acquisition; the portal serves customers who have already arrived.
Apply this to your project
Describe the questions customers repeatedly ask your managers. We can turn them into a clear first-version portal journey.
Discuss your projectRelated service: Custom web application development