Customer services
Orders, invoices, documents and requests with a visible interaction history.
Direction 22 / 24
Customer portalsfor actions and documents
Customers need to check a request status, find a document and complete an available action without contacting support again. We develop client portals for websites and services. First define authentication, permissions and data sources, then agree self-service journeys and integrations.
01 / 05
Who it is for
A solution shaped around your operating model
The architecture adapts to the scale, workflows and roles of your organization.
B2B partners
Controlled access to offers, resources and shared business workflows.
Suppliers and teams
File exchange, approvals, notifications and ownership of work.
02 / 05
Functional architecture
What the solution can include
We define the final module set after researching goals, users and integrations.
Sign-in and recovery
Define authentication, account recovery and additional verification for sensitive operations where appropriate.
Profiles and permissions
Separate personal and organisation roles, enforcing permissions on data access as well as interface controls.
Orders and documents
Present history, statuses, files and invoices with search and explicitly defined access rules.
Requests and notifications
Create requests, follow team responses and manage preferences for agreed notification channels.
Business system connections
Connect CRM or ERP systems, handle exchange failures and explain delayed data to users.
Administration and logs
Manage users and access permissions, with records of important actions to support investigation.
03 / 05
Project value
Start self-service with roles and permitted actions
A portal starts with rules: who can sign in, what they can see and what they can do. We design these boundaries alongside self-service journeys. The interface explains statuses and next steps while your team receives organised requests.
- 01A role model with explicit data access boundaries
- 02Clear statuses and helpful error messages
- 03Tests for user isolation and account recovery
- 04A focused self-service development plan
04 / 05
iSoft process
From industry logic to a stable launch
- 01
Discovery
We map business goals, audiences, roles, content and external systems.
- 02
UX architecture
We design journeys, structure, prototypes and the data model.
- 03
Design and build
We create the responsive interface, features, integrations and protection.
- 04
Launch and evolve
We verify quality, train the team and plan future iterations.
FAQ
Frequently asked questions
01Can a portal be added to an existing website?+
Yes. We first review architecture, authentication and data sources. The portal can be developed as a separate module with an agreed integration.
02Can organisations have different access rights?+
Yes. We define organisations, staff roles and visibility boundaries, then explicitly test data isolation between users before launch.
03Can we start with documents and requests?+
Yes. This can make a useful first release. Payments, automated reports or complex approvals can follow once the core journey is established.
04What determines the portal budget?+
Roles, operations, data sensitivity and external systems determine scope. We estimate development, verification and support after mapping the journeys.
iSoft / 22
Discuss your customer portal
Describe your users, documents and actions to move into the portal. Share your existing website and business systems so we can define permissions, integrations and the first release.