A replacement project can inherit every assumption that made the original portal difficult to operate. Before selecting a new platform, establish what actually needs to change.
These seven questions provide a practical starting point for a discussion involving service operations, finance, technology and the people responsible for business policy. The aim is a defensible scope, not a larger feature list.
1. Which customer jobs still cannot be completed successfully?
Describe outcomes rather than screens. “Change a membership and understand the payment consequences” is more useful than “improve the account page”. Use real support requests to identify where completion breaks down.
For each job, record who needs it, its frequency, the current outcome and the consequence of failure. Include less frequent jobs with serious consequences. A prioritised list makes it possible to judge competing approaches against the same needs.
2. What is our true annual cost of ownership?
Bring together licensing, hosting, support, maintenance, integration, security work and internal administration. Keep the original implementation investment distinct from recurring expenditure. Include change requests and staff workarounds that live outside the technology budget.
Agree how internal time will be valued and avoid double counting work already covered by a supplier contract. The ownership cost framework offers a structure for that exercise. Without a baseline, a replacement’s apparent savings are difficult to assess.
3. How much of the problem is the interface versus the underlying systems?
A confusing screen can be redesigned. An unavailable API, inconsistent identity record or missing operational capability needs a different intervention. Classify obstacles before assuming a new portal will solve them.
In an illustrative booking change, the visible problem might be a long form. The decisive limitation could be that the booking system cannot reserve a replacement place while a fee adjustment is approved. A shorter form would not resolve that dependency.
4. Which business rules and permissions are genuinely necessary?
Separate policy from historical configuration. Identify why each restriction exists, who owns it and how it is enforced. Remove obsolete process steps through authorised business decisions, not through an implementation team’s assumptions.
Preserve identity checks, record-level access and required approvals. An adaptive experience is only useful if it operates within defensible boundaries. Plain-English policy descriptions need review and enforceable controls, not just an instruction to behave correctly.
5. Why do customers still need staff assistance?
Read a sample of repeat contacts and follow the whole request. Was the issue unclear navigation, missing information, a failed update, lack of confirmation or an exception that legitimately required judgement?
Distinguish avoidable intervention from appropriate escalation. Reducing the former can improve service; eliminating the latter can weaken it. The answer should shape both the implementation and the measures used to evaluate it.
6. Could we reuse more of our existing systems?
List the reliable capabilities already available and the permissions under which they can operate. Determine whether a coherent customer outcome could be coordinated across them without replacing the underlying applications.
Reuse is not free. Authentication, data mapping, integration maintenance and failure handling remain part of the work. Compare that scope honestly with rebuilding the interface or replacing a system. A specialist visual workspace may still be the most suitable option for some tasks.
7. How could we prove an alternative before committing?
Select a small set of meaningful jobs, establish a baseline and agree success criteria. Include normal cases, variations, access restrictions and dependency failures. Identify what evidence would justify expansion and what would lead you to stop.
Avelyndo’s Proof of Value programme starts from this principle. An intelligent, governed approach may reduce repeated journey development where supported system capabilities already exist. It cannot substitute for missing integrations, sound data or specialist implementation where those are required.
The decision after a pilot may be to expand, retain parts of the portal, resolve a dependency first or pursue another approach. A useful evaluation makes those choices clearer before another major investment is made.