I see that the trend is both continuing and evolving. Modern drivers for new portals come from the pursuit of efficiency but also from new technology capabilities. The feature set of a self-service is always linked to the capabilities of backend systems and the integration layer. Only processes that can be automated from the customer’s user interface to backend transactional systems can realise the efficiency gains. As these legacy backend systems are modernised, organisations have new opportunities for increasing self-service via portals.
However, there is also a new shift emphasised by AI agents. One recurring problem with self-service portals is that even though users might prefer digital channels, they would prefer to use the channels they already operate in. When each partner uses their own portals, business users are flooded with different services, login credentials and discrepant experiences. What if they could order more products from a partner via their own conversational procurement bot?
Self-service portals as a web service
Typical self-service portals from Solita perspective have been web services that offer some key features for a specific stakeholder group. Main categories include:
Customer portals: Interaction, contract management and engagement history. See example: Modern and simple way of handling forest affairs with UPM
- Vendor/dealer portals: Contract-based transactions and sales support. Read how Laattepiste has more time to engage with customers.
- B2B stakeholder services: Business-specific tools including calculators, configurators and reporting. Read about the new portal solution for Aalborg Portland.
These have traditionally been considered web services, much like websites or e-commerce services and often they indeed have been closely linked. But it’s important to understand that the web service, end-user interface, is only the tip of the iceberg. A successful service is dependent on number of integrations, data and business logic that enable the UI features. This point of view also opens up interesting possibilities in the age of AI. If we view portals as data sources and APIs for process automation, the web portal becomes only one possible UI among many others.
Portals as data sources
I see self-service portals as channels that enable external users to connect to the organisation’s core business processes.
For example, an order management system is an external interface for the order-to-fulfilment process spanning to various operational backend systems (ERP, CRM, logistics etc). This UI needs not to be a web portal, it can also be a conversational UI (chat bot), or a customer company’s own business application that connects via an API. Regardless of the UI, we need to design and implement the process from order to fulfilment systems.
From this point of view, the traditional portal can be split into 4 logical layers or phases:
Integrations: Connection to data sources and operational backend systems required for the selected use cases.
- Data: What data should be made available for external users and what is needed for business process execution? This phase often includes manipulating the source data for the portal’s use.
- Logic and business rules: What guardrails and rules are applied to data, process steps and the end users. Identity management, authentication, roles and access rights – overall security.
- User interface: A web UI, conversational UI, system API – anything that taps into the capabilities of the portal solution.
Each layer is required to realise the potential value of the solution. The implementation method can vary based on the context.
