Customers experience one organisation. Inside it, membership, bookings, finance and service delivery may each have their own systems. When every system brings a portal, the customer inherits the organisation’s internal boundaries.
Multiple portals do not necessarily reflect poor decisions. Different teams may have selected appropriate tools at different times. An acquisition, a new service or a specialist operational requirement can introduce another application. The challenge is what happens when a customer’s job spans them.
A shared logo is not a shared service
Putting the same brand on two portals can make them look consistent. It does not establish a common identity, reconcile records or make business rules agree. A link between the portals may improve navigation while leaving the customer responsible for transferring information.
Imagine a member changing a service package. One system owns membership eligibility, another holds future bookings and a third maintains financial commitments. The customer wants one change with understandable consequences. Three separate confirmation screens do not necessarily add up to that result. This is an illustrative scenario, not a customer case study.
Identity is only the beginning
A common sign-in can reduce friction, but authentication answers who someone is. Authorisation determines what they may see or change. A parent, delegated administrator or household member may have different relationships to different records.
Consolidation therefore needs more than matching email addresses. It requires reliable associations between identities and records, clear rules for delegated access and a way to handle uncertain matches. Where these are missing, an attractive new interface cannot safely fill the gap.
Decide which system owns the truth
If two applications hold an address, which one should a customer update? Should the change propagate immediately? What happens if one update succeeds and another fails? These decisions are part of service design, not merely technical housekeeping.
The same applies to policy. A cancellation may be permitted in the booking system but create an unresolved financial consequence elsewhere. The organisation must define the intended outcome, permitted sequence and recovery path before exposing the action through a consolidated experience.
Consolidation can mean three different projects
Replacing the underlying applications is a system consolidation project. Building a single portal over them is an interface consolidation project. Coordinating a customer job across them is a service integration project. A programme may need all three, but they should not be mistaken for one another.
Separate their costs and dependencies. A new portal can be justified when customers need a coherent visual workspace. Replacing an application can be justified when it lacks essential capabilities. Neither decision should be automatic simply because there are two logins today.
Evaluate a service layer against a complete job
An intelligent service layer provides a simpler starting point while retaining the operational systems. It identifies the request, obtains permitted information, applies policy and coordinates supported actions. Reporting partial completion accurately and involving staff when recovery requires judgement remain essential.
The opportunity is to reduce duplicated customer-facing logic. The limitation is that underlying APIs, data quality and permissions still determine what can be achieved. Unsupported actions will require additional integration, specialist development or a clearly defined human step.
Make consolidation incremental
Choose a job that currently crosses a portal boundary. Establish a baseline for completion, customer effort and staff intervention. Demonstrate the proposed alternative, including a failed dependency and an access restriction. Retire existing functionality only once its replacement has been established and its dependencies understood.
Avelyndo uses this governed approach. A simpler customer experience should follow from clearer responsibilities and reliable actions, not from hiding unresolved complexity behind a new front door.