Internal portals fail when they make employees translate a real job into the portal’s organisational structure. A person arrives to approve a purchase, update a customer record or find a policy. The portal answers with departments, document libraries and application names. The interface may be polished, yet the work still moves to email because the path to completion is unclear.
This is not proof that employees resist change. It is evidence that the product may not match the task. Diagnose that mismatch before replacing the search engine, adding a chatbot or commissioning a new home page.
Failure starts before the interface
Choose one frequent, consequential task and follow it from trigger to accepted result. Record what starts the work, which information the employee already has, what evidence another person must review, where approval lives and how completion is confirmed. The task often crosses several systems even when the portal presents it as one page.
Now observe people attempting the task. Note duplicated entry, missing context, permission requests, dead links, unclear status and handoffs that leave no owner. Do not ask only whether they like the portal. Ask them to show the last time they completed the work and identify the point where they changed channel. The economic case should include those detours, just as a payback discussion must include operating effort rather than feature count.
The portal may also expose a structural disagreement. A policy owner thinks in documents, operations thinks in cases, and IT thinks in applications. Users need a coherent route across all three. A new visual hierarchy cannot settle ownership, define missing states or repair an integration that loses the case identifier.
Read behavior as evidence, not resistance
Product data should describe the journey, not merely traffic. Useful events include starting the task, reaching a decision point, requesting access, saving incomplete work, returning later, submitting evidence and receiving a confirmed outcome. Segment by role, location, device and permission level only where those distinctions are legitimate and useful.
A sharp drop at one step identifies a place to investigate, not a reason by itself. Combine the event trail with support tickets, search queries and direct observation. A broken attachment may look like poor content. A hidden entitlement rule may look like confusing navigation. A recurring workaround may be rational behavior under a deadline.
Invisible constraints deserve the same attention as visible screens. The discipline used in a website risk audit applies here: verify dependencies, ownership and restrictions instead of assuming the interface tells the whole story. If someone proposes AI as the repair, use the basic questions for an AI purchase to test whether prediction or generation actually removes the bottleneck.
Repair one work path before rebuilding the portal
Define an acceptance test around the selected task. A representative employee should reach the correct starting point, understand the required evidence, recover from a predictable exception and receive an unambiguous completion state. The test must use realistic permissions and connected systems, not a design prototype populated with ideal data.
Assign an owner to every state that can block the journey. Content needs a review date. Access requests need a service expectation. Integration failures need a recovery route. Search needs a maintained vocabulary. Without those operating responsibilities, the redesigned portal will decay into another attractive index of unmanaged material.
Release the repaired path to a bounded group and compare completion, abandonment, time, support demand and exception handling with the earlier baseline. Treat any improvement as observed for that cohort and period. Do not convert one successful test into a universal adoption claim.
Frequently Asked Questions
Look for work escaping into email, chat, spreadsheets or repeated support requests. Those detours often reveal a broken task path before a satisfaction survey does.
Not automatically. Begin with the task, the evidence required to complete it and the systems that own each step. Navigation follows that structure.
Analytics can locate exits, retries and delays, but observation and interviews are usually needed to explain the reason behind that behavior.
A rebuild becomes reasonable when validated task paths cannot be repaired within the existing architecture, permissions model or content ownership structure.
When the evidence shows that interface, workflow and architecture must change together, a product and portal assessment can turn the observed journey into a scoped delivery decision.