Give each user access to what they need
Employees submit leave requests, partners download sales material, customers track enquiries. Access and screens are designed around each task.
Employee, customer and partner portals serve different audiences and purposes. All need a considered information architecture: people can find relevant content, documents and processes; editors know what they own; IT understands the systems and data flows.
A portal is part of a wider system. Identity management, single sign-on, business applications, document management, CRM or ERP, notifications and compliance need attention from the start. We establish where data is owned, how access is controlled and which actions must be traceable.
When an intranet or extranet helps
When information, self-service and collaboration are scattered across systems and channels.
- Employees need different information, tools and approvals according to their roles.
- Partners or customers need secure self-service access to documents, data and services.
- Access and permissions should use single sign-on or an existing identity management system.
- Forms, approvals and recurring service processes need clear ownership and visible status.
- An existing intranet or extranet needs its technology, content and responsibilities reorganised.
Integrating sign-in, search and business systems
We build restricted areas, connect existing user accounts and link documents and requests to the relevant business systems.
- Requirements, information architecture and ownership of content, approvals and ongoing updates
- Identity management, single sign-on, roles, permissions and protected areas
- Search, documents, news, forms, workflows, approvals and notifications
- Connections to HR, ERP, CRM, document management and other business systems
- Accessible interfaces, privacy, security, auditable permissions and testing, particularly for sensitive data or regulated processes
Defining access and testing portal workflows
Business teams, internal communications, IT, privacy specialists and future users approach a portal from different angles. Together we prioritise who needs what, define permissions and content ownership, and test the proposed workflows in prototypes. No single perspective decides the result.
The rollout includes migration, training and introducing new workflows. After launch, we review search queries, feedback and support cases to identify documents people cannot find and tasks they abandon. These findings guide changes to navigation, content and interaction.
Portals in use
These applications support internal teams, distribution partners and structured approval processes.