A company launches a portal so customers can upload documents, change account details, submit requests, and check progress without calling anyone.
The first reports look encouraging. Registrations rise. More requests arrive online. Call volume falls for the tasks the portal handles well.
Behind the screen, a different picture develops. An employee downloads each uploaded document and attaches it to a case in another system. Account changes are copied into billing. A spreadsheet tracks requests that do not fit the portal’s categories. When a customer asks about progress, the service team checks two systems because “submitted” in one does not mean “accepted” in the other.
The company has added a digital front door. It has not replaced the service behind it.
A customer portal is often treated as a channel project: design the interface, connect a few systems, and move demand away from phone or email. Operationally, the portal creates a new route through the business. If that route does not replace old work, it can create a second operating model that employees maintain beside the first.
The interface cannot finish the service
A customer action is only the visible beginning of many services.
Submitting a claim can trigger identity checks, document validation, risk review, approval, payment, and an appeal. Changing an address may affect billing, delivery, tax records, contracts, and future communication. Booking an appointment may require capacity management, preparation, reminders, and follow-up.
The portal can make the first step easier without changing any of the work that follows.
Service design has long distinguished between the visible “front stage” and the operational “back stage.” Research on web-driven self-service argues that focusing on the final customer interaction can discount the information processing and support work required behind it. That connection matters because the customer experiences the result of the whole service, not the quality of the screen in isolation.
A clean form can therefore conceal a poor operating path. The fields may be easier to complete while the information still enters a queue that someone sorts manually. The status page may be accurate according to the portal while remaining disconnected from the team doing the work. Automation at the point of entry can increase volume faster than the organization can validate or fulfill it.
The interface has improved. The service may not have.
A second operating model forms quietly
Parallel operation often begins for sensible reasons.
The old system cannot be replaced before launch. Some customers still need phone or email. A regulated review remains manual. One business unit is ready while another needs more time. Running both paths temporarily can protect continuity and reduce migration risk.
The problem is not coexistence. It is coexistence without an exit decision.
The portal creates its own intake rules, identifiers, statuses, notifications, service promises, and reporting. Existing teams keep the rules and tools they already use. Someone must translate between them.
That translation rarely appears as a formal capability. It appears as small actions spread across the day: copying a reference number, checking whether two records describe the same customer, correcting a field that uses a different definition, or sending an internal message because an exception has no route.
Each action looks minor. Together, they form a reconciliation layer.
As portal adoption grows, this layer can grow with it. The company scales the visible digital channel and the invisible work required to keep it consistent with operations. What looked like automation becomes a new source of administrative demand.
A recent open-access study drawing on four IT self-service portal deployments found that service quality depended on technology, management, and organization rather than the portal alone. Much of the improvement work involved defining authorization rules, adapting data forms, and deciding which configuration items customers could request. These are operating decisions expressed through a digital product.
Integration requires more than APIs
When the two paths begin to diverge, the natural response is to ask for more integration.
Technical integration matters. Moving information automatically is better than re-entering it by hand. Shared identity, reliable data exchange, and connected notifications can remove obvious duplication.
An API can move an “approved” status without resolving whether the word means that a request passed review, entered fulfillment, or completed. Nor can it choose an authoritative record or assign an exception that crosses product, finance, and service teams. Those are operating-model decisions.
The distinction is visible in the OECD Digital Government Outlook 2026. Its public-sector evidence shows that shared digital components create value only when systems can exchange information reliably and organizations establish standards, responsibilities, and operational accountability. The context is government, but the mechanism is familiar to any business trying to join a customer-facing platform to several internal owners.
The UK’s current digital functional standard makes the operating requirement unusually explicit. It says a service should document its user-facing and internal systems, people and tasks, processes, data flows, and decision points. It assigns accountability for the end-to-end service as well as its digital component.
That is a useful test for a commercial portal. A product owner may control the backlog but not the teams that fulfill requests. Operations may own delivery but not the data model. Technology may connect systems but lack authority to simplify the policy that created the handoffs. Without an end-to-end owner, every function can deliver its part while the service remains divided.
CarMax approached its omnichannel transformation as more than a website project. MIT CISR’s account describes how leaders expected fragmented systems and processes to limit the customer experience, so the company prioritized a shared CRM foundation and cross-functional accountability across people, process, data, and technology. The lesson is not that every portal needs a new CRM. It is that a new customer journey needs an operational foundation capable of carrying it.
Portal metrics can reward addition instead of replacement
Portal teams naturally measure registrations, online completion, adoption, availability, and changes in call volume. These measures show whether customers can and do use the new channel.
They do not show whether the company now performs less work.
A request can be completed online and re-entered manually. A call can disappear from the contact center and reappear as an internal clarification. A shorter form can create more exceptions. A status page can reduce routine questions while generating harder ones when its language does not match operational reality.
The measurement boundary needs to extend beyond the portal. How often is information copied or corrected after submission? How many records exist for the same request? How long passes between customer action and operational completion? Which exceptions leave the designed workflow? What existing queue, report, or process has actually been retired?
The UK Service Standard asks digital teams to work with front-line operations and examine how changes in online and offline channels affect each other. That prevents a local improvement from being mistaken for a whole-service improvement.
The most revealing metric may be simple: what can the business stop doing because the portal works?
If the answer is nothing, the portal may be adding capacity, convenience, or useful visibility. Those can be valid outcomes. Leadership should not describe the investment as operational simplification unless some old work is genuinely removed.
Design backward from the service promise
A stronger portal begins with the outcome the customer expects, then maps backward through the organization required to deliver it.
If the portal promises that a request is complete, what must have happened in operations before that status appears? If customers can change information, which other records must change with it? If they can submit an exception, who has the authority and context to decide it? If a case moves to another channel, does it retain one identity and one owner?
This work should make several choices visible before adoption is pushed. Decide which system is authoritative for each important piece of data and each service status. A portal can display information from elsewhere, but the organization still needs one defensible answer when records disagree.
Second, assign ownership across the whole service. The person accountable for the outcome needs enough influence over the interface, operational workflow, data, policies, and improvement priorities to resolve problems between them.
Third, design exceptions as part of the service. The standard path does not reveal the strength of an operating model. The unusual request, failed validation, disputed decision, and cross-team dependency do. Exceptions need a route that does not create a second case under a second owner.
Finally, name the work that will end. A phased launch should include conditions for retiring duplicate forms, queues, spreadsheets, notifications, or records. Otherwise, temporary safeguards become permanent infrastructure.
The portal does not need to automate everything. Some work deserves judgment, conversation, or manual review. Coherent service design makes that work deliberate and connects it to the same operating logic.
A portal succeeds when it improves how the business delivers the service, not merely how the customer enters it. The decisive launch question is therefore not “Can customers use the new portal?” It is “Can the company stop running the old service beside it?”
