A client portal can work as specified and remain irrelevant.

Documents are available, messages can be sent and cases have status fields. Clients still return to email because the portal makes a familiar task slower, less clear or less reliable.

Adoption is an outcome of service value, frequency, trust and context. It cannot be diagnosed from login rates alone or repaired by adding a personalised dashboard to every product.

Begin with the job clients return to do

Portal briefs often begin with internal goals: reduce document requests, move communication from email, expose workflow or lower support cost.

Those can be valid commercial outcomes. The portal needs a client job that supports them.

A client may need to provide a sensitive document safely, understand whether action is required, retrieve an invoice or see when the firm expects to respond. A member may need to record development, renew or book an event. A wealth client may need current reports and secure contact.

Research the job, its frequency, consequence and preferred channel. A portal used twice a year can be successful with low monthly activity. A mandatory weekly task with widespread avoidance is a stronger warning.

Internal status is rarely client meaning

“Awaiting partner review” may be accurate and fail to answer the client's questions: Is the firm waiting for me? When should I expect movement? Who owns the next step?

Translate state carefully. Show what has happened, what follows, who acts and a credible expectation. Avoid false precision when progress depends on another party or professional judgement.

Do not expose confidential internal notes or create pressure for staff to update a cosmetic status manually in several systems. Design the underlying workflow and ownership.

A late but accurate update can be more trustworthy than a live-looking status nobody maintains.

Personalisation should mean relevance

A useful home screen can surface active matters, current documents, tasks and deadlines for the authorised user. This is rule-based relevance as often as AI.

Personalisation also carries risks. Different people at one client may have different permissions. A delegated user, former employee or family representative can see the wrong information if identity and relationship data are stale.

Define roles, purpose, source and fallback. Let users understand why an item appears and report an error. Keep high-consequence decisions out of opaque ranking.

The source's member-portal adoption and churn figures need project records and permission. The design principle can stand without them.

Self-service needs a human escape

Routine retrieval and updates can reduce client effort and staff demand when the information is current and the route works.

Self-service becomes harmful when clients are forced through it for an exception, vulnerability or urgent issue. Provide visible, appropriately staffed help. Pass the context already supplied so the person does not restart.

Use support logs to identify recurring requests and observe why they occur. Some are good candidates for self-service. Others reveal an unclear service, missing advice or a control that requires human judgement.

Measure completion, error, assistance and repeat contact. Counting deflected calls alone can reward inaccessible service.

Notifications should reduce uncertainty

Notify users about events that matter: a document is available, action is required, a deadline approaches or an important status changed.

Give clear sender, subject, safe context and next step. Avoid putting sensitive detail in an insecure notification. Make preferences manageable where appropriate and distinguish essential service messages from marketing.

Too many alerts train people to ignore them. Too few require repeated checking. Research the urgency and frequency for each event.

Every notification link needs to survive authentication and recovery without dropping the user at a generic homepage.

Identity is part of the product

Separate credentials, difficult authentication and poor recovery can suppress use. Single sign-on may improve continuity and introduces dependency on the identity architecture.

The source cites a named professional body and precise support and self-service results. Verify the engagement, definitions, contribution and permission before restoration.

For any identity option, assess:

  • user groups and delegated access;
  • authentication strength;
  • accessible authentication and recovery;
  • joiner, mover and leaver processes;
  • account linking and duplicate identity;
  • support and fraud handling;
  • audit and monitoring;
  • failure and fallback;
  • privacy and data minimisation.

Convenient access cannot come at the expense of client confidentiality.

Integration quality sets the trust ceiling

A portal displaying stale or partial information encourages clients to seek confirmation elsewhere.

Define systems of record and expected timeliness per data type. Real-time is unnecessary for some information and critical for another. Show last-updated context where useful.

Integrations need error queues, reconciliation, monitoring and owners. Test mismatched records, revoked access, duplicate clients and a core-system outage. A successful API call is not proof that the correct client saw the correct state.

Protect sensitive data in transit, at rest and in logs. Use minimum access and test authorisation at every layer.

AI belongs behind a defined problem

AI may help search approved content, classify requests or propose summaries. It may also fabricate, expose data or give advice outside an appropriate service boundary.

Do not use behavioural tracking to infer vulnerability or rank clients without a lawful, fair purpose and strong governance. A deterministic rule can be safer and easier to explain for many portal tasks.

Client-facing legal, financial or regulated answers need specialist review of professional, legal, privacy, security and operational risk. A disclaimer does not repair an unsafe design.

Test a bounded use against representative and adversarial cases. Keep source access, human escalation and incident response.

Treat the portal as a service

A portal has an owner, roadmap, operating measures, content governance, support, security and regular research. Launch is one release.

Review:

  • priority task success;
  • adoption among eligible users for relevant tasks;
  • assistance and workarounds;
  • data and status accuracy;
  • accessibility;
  • security and privacy events;
  • performance and recovery;
  • feedback from users and frontline teams;
  • cost to operate and change.

Segment carefully. Overall login rates can hide an excellent service for one group and exclusion for another.

Fund maintenance and small improvements. A portal left unchanged while client services and core systems evolve will drift.

Repair before rebuilding

Choose the task with the greatest combined client consequence and operational demand. Observe it end to end. Identify whether the cause is navigation, content, ownership, data, authentication, integration or service policy.

Prototype the smallest useful change, test with relevant users and measure it. A rebuild may be justified where architecture, security or maintainability prevents safe improvement. It should emerge from evidence.

If you want to understand where your current portal is losing users and which improvements would have the highest impact on adoption, we've put together a portal audit framework covering the five most common failure points. It's designed for operations and marketing leaders, and you can share it directly with your technology team or portal vendor as a brief for improvement work. Certainly cheaper than commissioning another portal that nobody uses.