Solution area
Corporate Portals
Moving repeated requests and document sharing to a single point where people handle their own transactions. The aim is not to add another screen, but to change where an existing process is run from.
Where a portal sits
One place to reach processes.
A portal does not create a new process. It changes where the existing one is reached from.
Corporate portal
One place to reach the organisation's processes from
Employees
Raise their own requests and collect their own documents
Process owners
See and answer the request on their own screen
Enterprise systems
The record is created here, not in the portal
Humanax HR & Payroll
Today's example of the employee self-service experience
Starting point
A request should reach the process, not a person.
In most organisations the same requests travel the same route: someone sends an email, that person looks the answer up elsewhere, and the reply comes back by email. The only way to find out where a request stands is to ask.
That route creates invisible work on both sides. The same information is asked for more than once, documents are sent one at a time, and the history of the work stays in people's mailboxes.
This is where a corporate portal comes in: people handle their own transaction, the process owner sees the request on their own screen, and the record is created in the organisation's systems. Our clearest example of this is the Humanax employee self-service portal, where leave requests are raised and payslips are collected.
So we start from the process that is moving rather than from the portal screen: which request, through which steps, and where does the result get recorded?
When a portal starts being discussed
- The same request sent by email every time
- Documents sent out one person at a time
- Having to ask where a request stands
- A process that depends on one person keeping track
- People away from the office joining the process by other routes
Workstreams
Three areas of work.
Scope is set together based on the processes that are moving and who the portal opens to; each area produces decisions for the next.
Mapping the process
The requests that will move, their steps and the people responsible are identified, and it becomes clear which transactions can genuinely be self-service.
Connection with enterprise systems
It is planned which record a portal transaction lands in, so no separate data island appears.
Controlled rollout and monitoring
The portal opens with limited scope and is tried in real use; afterwards usage is monitored and the steps that do not work are addressed.
Delivery approach
We start with a single process.
A portal is not built by moving every request at once. It grows once one process genuinely works.
Choosing the process
Work starts with a process that recurs often, has defined steps and a visible outcome.
Designing the flow and the screens
Who does what, which information is asked for and where the request goes are designed together.
Adapting the enterprise system side
What a portal transaction means is defined in the existing systems, and the record is created there.
Controlled opening and monitoring
Work starts with a limited group of users, is adjusted on their feedback, and the scope widens step by step.
Scope note
The scope of a portal, and who it opens to, is decided per organisation
Every organisation needs something different from a portal: which processes move to it, whether it opens only to employees or also to people outside the organisation, and what each group can see all depend on how the organisation works.
So we do not present the scope as a ready-made list. Once your current processes and systems have been reviewed, we agree the starting scope and the sequence together.
Let's decide together which process moves to a portal.
Let's talk through your most repeated requests and your current systems, and choose the starting scope together.