Creating a customer portal starts with one customer process, clear access rights and agreed data sources. Then decide whether to configure existing portal software, add integrations or develop a custom application. This guide helps you prepare that decision and provides a completed example for your brief and first test.
First decide which process you want to improve
Examples include:
- the progress of a construction or installation project;
- handling a complaint or damage claim;
- a student, client or patient file;
- onboarding a new business customer;
- documents and actions relating to an order;
- ongoing services with recurring approvals.
Map the current customer journey for that process. Record what information a customer receives, which channels it arrives through, and when questions arise. Also look at the internal process: which team member uses which system, and where is the current status recorded?
Which features does a customer portal need?
| Component | For the first version | Add later if needed |
|---|---|---|
| Personal overview | Status, new messages, deadlines and outstanding actions | Filters, preferences and detailed reports |
| Projects or files | Clear organisation and recognisable status | Complex workflows and additional file types |
| Documents | Version, date, context and access rights | Signing, examples and automatic classification |
| Actions and forms | Confirmation, upload or a simple choice | Multi-stage approval and detailed forms |
| Communication | Updates and messages in the right context | Multiple channels and detailed preferences |
| Ongoing management | Users, access, content and outstanding actions | Automatic setup and in-depth analysis |
Messages and notifications
Keep communication with the relevant file. A notification should bring someone back to a specific action or change that matters to them. Where appropriate, let users choose the channel and frequency; a portal that emails about every small change creates more noise.
Define roles and access before you start building
A customer portal often contains personal data, documents or confidential business information. Define who may see and do what in advance. Create a simple permissions matrix showing, for each role:
- which projects or files are visible;
- which documents someone may view or upload;
- which actions someone may carry out;
- whether someone may invite other users;
- which changes must be recorded.
Start from the principle that access is granted only when it is needed. The NCSC describes identity and access management as a combination of reliable identification, authentication and authorisation. Consider the full lifecycle too: when is access granted, how is an invitation checked, and when is access revoked?
Build privacy into the design. Collect only the data needed for the agreed purpose and define when information will be deleted or archived. The GDPR guide from the Dutch Data Protection Authority sets out the legal framework.
Define which system is the source
A portal is usually not the organisation's only system. Customer details may come from a CRM, order information from an ERP, and files from a document system. Decide which system is authoritative for each data item.
- CRM: contact details and customer relationships;
- ERP: orders, invoices and financial status;
- document system: final documents;
- customer portal: communication, invitations and customer actions.
Without these agreements, team members may edit the same information in several places. It then becomes unclear which version is correct. Also decide how quickly changes need to become visible. A confirmed payment or urgent action may need immediate processing; periodic synchronisation may be enough for less time-sensitive data.
Standard software, custom software or a combination?
Having a customer portal developed entirely from scratch gives you considerable freedom, but also requires ongoing ownership of security, management and further development. A standard solution is quicker to introduce, but needs to fit your process and systems well enough.
Unsure where to draw that line? Our decision framework for custom software or standard software helps you compare process fit, integrations, ownership and total costs.
Do not judge a solution on a demonstration alone. Also assess options for your own branding and domain, roles and permissions, available APIs, data export, logging, backups, mobile use, and support with setup and migration.
Example brief: one request from submission to completion
This fictional example concerns a maintenance request. It is a design aid, not an existing customer case or a standard feature of every portal. Complete the same decisions for your first process before asking a supplier or developer for a proposal.
| Agreement | Completed example |
|---|---|
| Customer goal | The customer can see whether the request was received, which information is missing and what happens next. |
| First customer action | Submit a description and photo in the customer’s own file. Submission produces an acknowledgement of receipt, which does not yet confirm an appointment. |
| Team task | A team member reviews the request and asks for more information if needed. Only the assigned planner confirms an appointment. |
| Status source | The request status comes from the agreed management system. The appointment date appears only after the planner has confirmed it. |
| Access | The customer sees only their own file. Define separately what a colleague, external contractor or second contact may view and change. |
| Exception | If the photo is missing or a status update fails, show what still needs attention and who owns the next step. |
| First acceptance test | Have two test customers each submit a request. Check the acknowledgement, the next action and that neither can open the other’s file. Then test the same journey with missing information. |
Next decide what stays outside the first version. In this example, automatic scheduling, payment and an integration with an external contractor can be separate extensions. This lets you compare proposals against the same behaviour and test more than the dashboard’s appearance.
For documents that need review, define the upload, review and approval flow separately. For new-build projects, use the stages for digital buyer support to adapt the example to your buyer journey.
Build a customer portal in seven steps
- Choose the first customer process. Select a process with a clear problem and a defined user group.
- Interview customers and team members. Find out which questions keep coming up and where information gets lost.
- Map the intended customer journey. Define the information and actions needed at each stage.
- Create a clickable prototype. Test language, navigation and priorities before building integrations.
- Define data, permissions and integrations. Identify source systems, synchronisation timings and exceptions.
- Start with a limited pilot. Use real, controlled scenarios and gather feedback from both customers and administrators.
- Roll out in stages. Improve the first process before adding new components.
What determines the cost and timeline?
Ask for three cost components against the same brief. This shows what the initial price includes and which costs recur.
- One-off: setup, design, migration, integrations and assistance with the initial launch.
- Recurring: subscription or hosting, maintenance, updates and agreed support.
- Usage-dependent: extra projects, users or units, storage and any other extensions the supplier charges for separately.
Yindle Portal is a subscription offering; the Portal page shows the current plans and limits. Integrations with other systems and additional work are scoped separately. Compare this with both development and ongoing management when considering a fully custom portal.
Common mistakes
The most common mistake is trying to show too much at once. Putting all available data on one screen does not make a portal easier to use. Other pitfalls include using internal terminology, sharing documents without versions, failing to appoint a content owner, testing only the ideal process, and leaving integration errors invisible.
Test exceptions too: an expired invitation, a missing document, a duplicate user, a failed synchronisation or someone with multiple roles.
Frequently asked questions about building a customer portal
How long does implementation take?
Development is not the only factor in the timeline. API availability, data quality, internal decision-making and user testing have a major influence. A limited first version is easier to plan than an organisation-wide rollout in one go.
Can a customer portal use our own branding?
That depends on the solution you choose. Check whether the logo, colours, emails and domain can be customised, and whether customers get a consistent experience throughout.