Give customers their own space for information, requests and progress.
Discuss your projectA customer portal gives customers access to the requests, progress and documents intended for them. A first version might support three tasks: submit a request, check progress and retrieve a document. We define which organisation and records belong to the user and which actions are permitted. The visible customer status is deliberately mapped from the internal process; internal notes and handling steps are not automatically published.
This fits when customers repeatedly request the same information or track requests through separate emails. A CRM integration can supply customer and organisation details. Internal follow-up can stay in existing workflow software, while the portal supports only the agreed customer tasks.
An existing customer area may be sufficient if it already supports the tasks, permissions and source information. Unclear statuses or responsibilities need defining first. Adding a new screen does not resolve an unclear internal process.
A customer portal gives external users access to organizational information. I distinguish signing in from being authorized to view a record. Each user, organization and document gets defined actions, including downloads, uploads and inviting colleagues. [1]
Authorization is checked on the server and tested with direct links to other records. Account lifecycle matters too: invitations, departing employees and revoked access. The portal should clearly show whether an upload, change or request succeeded and how users can recover from errors. [2][3]
Example agreements for a first B2B portal: the role, customer organisation and record assignment determine access together. Access that has not been granted is denied. This is a design proposal; it does not describe a customer implementation or show the result of a security test.
| User | Information | Permitted actions | Boundaries |
|---|---|---|---|
| Customer employee | Records from their own customer organisation that have been released to this account. | Submit requests, follow the visible status and download released documents. Submit changes to a finalised record as a change request. | No records from other organisations or internal notes. This customer role does not allow users to manage colleagues or their permissions. |
| Internal case handler | Assigned customers and records the case handler is authorised to work on. | Review requests, update the agreed statuses and release selected documents to the customer. Keep internal notes separately. | No automatic access to unassigned customers. Saving a document or note internally does not publish it to the customer. |
| Administrator | Accounts, roles and organisation memberships within the agreed administrative mandate. | Invite or block users and manage their organisation memberships and role assignments. | Administrative permissions do not automatically grant access to record contents. An additional viewing role is approved and granted separately. |
On a narrow screen, scroll the table sideways to read each column.
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| An existing product's customer area | The required customer tasks and access rules are already available. | Also check organisation boundaries, invitations, revoked access and the meaning of displayed statuses. |
| A custom customer portal | Customers need a specific combination of tasks and information from several systems. | Data boundaries, source integrations and operation belong in the scope alongside the screen. |
| A broader web application | Several user groups need more extensive functions than the selected customer tasks. | A portal can technically be a web application; the customer tasks define its functional scope. |
| Internal workflow software | The main question concerns employees, task allocation and approvals. | That processing can remain behind the portal; not every internal step needs to be customer-facing. |
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
Customers regularly ask for information or status updates already available internally.
A customer portal gives external users access to a defined part of your information. A CRM integration can supply customer records, while API integration handles exchange with other systems. Define who may view, change and approve each type of information.
What may customers view, change and request themselves?
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachI first compare the desired customer tasks with the existing customer area. Configuration may be sufficient if requests, documents, permissions and statuses are adequately supported. Custom development becomes useful for specific limitations or essential connections between systems.
A portal can often connect to existing sources if access, fields and licences support it. We agree which system remains authoritative and whether the portal only reads or also submits changes. A new central administrative system is not automatically required.
We define the relationship between users, organisations and records, then test it through server requests, details and documents. Acceptance includes other organisations, expired invitations and revoked access. Hiding a button or field alone is insufficient.
Handover establishes who manages access and alerts, and how manual takeover works. An outage has a recognisable status and contact route. Availability, support, response times and further development are agreed separately.
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
Checking access for each user and requested object.
Link and relevance checked:Technical considerations for files uploaded by customers.
Link and relevance checked:Criteria for accessible tasks and feedback.
Link and relevance checked:Exploring Customer portal development? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief