A portal can be technically complete and commercially disappointing. The screens work. The integrations pass their checks. The project is delivered. Yet customers still ask staff to finish the very tasks the portal was supposed to make easier.
This is the portal paradox: adding functionality can increase the amount of software an organisation owns without increasing the amount of useful work a customer can complete. Understanding that distinction matters before approving the next phase of development.
A successful release is not a successful service
Technology programmes need concrete deliverables. A login page, account screen or booking form can be specified, estimated and tested. A customer outcome is less conveniently bounded. Changing a booking may involve eligibility, availability, a fee adjustment, a confirmation and a record in another system.
If the portal covers only the first part, the customer has started a digital transaction but the organisation still has a manual service obligation. Counting that transaction as digital adoption obscures the unfinished work. The useful unit of analysis is the completed job, including what happens after the screen says the request was received.
The evidence calls for a better question
Gartner’s August 2024 research reported full self-service resolution for 14% of service and support issues, from a December 2023 survey of 5,728 customers. Accenture’s 2025 report found that 32% of consumers thought service quality had improved over five years.
These are broader service findings, not measurements of portal project economics. They do not establish that any particular implementation failed. They do justify asking whether technology investment is translating into outcomes that customers recognise, rather than relying on the existence of a digital channel as evidence of success.
Complexity accumulates at the boundaries
Consider an illustrative membership organisation. Members can update their profile in one application and manage bookings in another. A change in membership category affects eligibility and pricing, but neither interface owns the whole request. Staff reconcile the two systems.
A new integration can help. It also introduces decisions about record ownership, timing, failure handling and permissions. A new screen can make the request easier to initiate while adding another place where the same business rule must be maintained. Each local improvement can be reasonable; the combined service can still become harder to change.
The budget continues after launch
Licensing is only one part of the commitment. Design, specialist development, integration, testing, operational support and change requests continue to matter. A new service may require changes across several of these layers. Staff workarounds add another cost, often recorded in a different departmental budget.
This does not mean bespoke development is inherently wasteful. A carefully designed interface can be the right answer for a stable, repeated task. The concern is repeatedly building customer-facing paths around changing circumstances without examining whether the operating model itself is creating avoidable work.
Replace the assumption before replacing the portal
Start with a small set of jobs customers struggle to finish. Map the decisions, information and authorised actions required for each. Identify which obstacles come from the interface, which come from system limitations and which come from unresolved business policy. Those problems need different remedies.
An intelligent service approach interprets the request and coordinates available actions within those boundaries. It still needs working integrations, reliable records and enforceable permissions. Its potential lies in reducing the need to prescribe a separate customer journey for every variation.
Before a wider commitment, test that proposition against real systems. A scoped Proof of Value should reveal both completed outcomes and remaining limitations. More software is not the objective. A service that reliably finishes useful work is.