When an ITSM portal is underperforming, teams often reach the same conclusion quickly.
We need a rebuild.
That reaction is understandable. If users are bypassing the portal, generic requests are high, work is bouncing between teams, and confidence in the experience is low, the whole thing can start to feel tired and ineffective.
But that conclusion is often reached too early.
Not every struggling portal needs to be rebuilt. Many need something more focused first: a reset of the intake experience behind them.
That distinction matters because rebuild and reset are very different responses. One is broader, heavier, and more disruptive. The other is more targeted. Done well, a reset can improve behaviour, reduce manual effort, and restore trust without replacing everything at once.
Why teams assume they need a rebuild
Portal frustration tends to build slowly.
A few pathways become unclear. Generic options get overused. Forms create rework. Routing becomes inconsistent. Users start following up outside the portal because they do not trust what will happen next.
Over time, those issues stop feeling like isolated problems. The portal starts to feel like the problem.
That is usually the point where rebuild thinking begins.
The difficulty is that visible frustration is not the same thing as proof that everything needs replacing. A portal can feel tired as a whole when the real damage is being caused by a smaller number of high-friction journeys, weak intake paths, and unreliable handoffs.
That is why it helps to pause before treating the whole portal as broken.
The key distinction: reset or rebuild
A reset is a focused effort to improve the parts of the experience that are creating the most friction, bypass, rework, and manual triage.
That usually means improving things like:
• entry clarity
• choice design
• the right fields on the right forms
• routing logic and ownership
• updates and expectation setting
• the journeys carrying the most demand
A rebuild is different. It is a broader redesign or replacement because the overall portal structure, experience model, or platform approach is no longer fit for purpose.
The important point is this: not every poor portal experience is evidence that the whole structure must be replaced. Sometimes the portal is still usable, but the intake experience behind it has become weak enough that trust has dropped.
That is where many teams go wrong. They move straight to rebuild thinking when the more useful first question is whether the experience needs a reset.
A reset targets the intake experience. A rebuild reshapes the broader portal structure.
When a reset is usually enough
A reset is often the better starting point when the core portal is still usable, but the experience around it is creating too much friction.
That often looks like this:
• users still use the portal sometimes, but not confidently
• a few common journeys create most of the complaints
• the generic path feels safer than the structured path
• forms are close, but still miss key details that matter to fulfilment
• work is being logged, but not landing cleanly first time
• users follow up outside the portal because updates are weak or unclear
• the issue feels more structural than visual
In these situations, rebuilding everything may be unnecessary. The portal is not beyond use. It is simply not behaving reliably enough where it matters most.
A reset helps narrow the focus. Instead of treating the whole portal as broken, it identifies the journeys, decisions, and handoffs that are training bad behaviour and fixes those first.
When a rebuild is justified
A rebuild may be the right answer when the experience model itself is no longer working.
That can happen when:
• the portal structure is fragmented across too many audiences or service areas
• there is no clear front door at all
• the experience is too cluttered to improve incrementally
• the underlying platform or design model is too limiting
• the portal has grown in a way that no longer matches how services should be consumed
• even targeted fixes would still leave the overall experience weak and confusing
In those cases, a reset may improve symptoms without solving the deeper design problem.
A rebuild is justified when the structure itself is working against the outcome you want.
Final thoughts
The goal is not to avoid rebuilds. Sometimes they are the right decision.
The goal is to diagnose the problem properly before choosing the response.
IIf the portal is fundamentally misaligned, fragmented, or no longer fit for purpose, rebuild may be the right path. But if the real issue sits in weak entry points, unclear choices, missing detail, poor routing, and low trust, a focused reset is often the smarter place to start.
That is usually the more practical question: Does the portal really need replacing, or does the intake experience need restoring?
Need a clearer view?
If your portal is underperforming, the first step is often to work out whether the issue is isolated friction or a broader intake design problem. My Portal Experience Quick Check is a useful first signal. Where the issues run deeper, the next step may be a more focused Portal Intake and Experience Assessment.