The test is repeated questions
Portals are frequently built because competitors have one. The justification that actually holds is simpler: are customers repeatedly contacting you for information you already hold in a system?
Order status, invoices, documents, appointment history, service records. If your support inbox is full of those requests, a portal removes them. If it is not, a portal will sit unused.
Build the three things, not the account area
The commonest mistake is scoping a general customer account with everything in it. Look at what people actually ask for and build those three things well.
- The top three requests from your support log, and nothing else
- Read-only first — showing information is far cheaper than allowing changes
- One user type initially; role hierarchies multiply the work
- Login that people can actually complete, with sensible recovery
Understand what you are committing to
A portal is not a page, it is an application. Accounts, permissions, data protection, security patching, and support for users who cannot log in. Budget 15–25% of the build annually and someone's ongoing attention.
If that maintenance is not affordable, the portal is not affordable, and it is better to know before the build than eighteen months into a decaying system.
Cheaper alternatives worth checking first
Proactive notifications remove most status enquiries without any login. Emailed documents with secure links remove most document requests. A well-designed public tracking page with a reference number removes the rest.
In several projects we have scoped, the honest recommendation was notifications rather than a portal, at a fraction of the cost.
Adoption decides whether it was worth it
- Tell customers it exists, repeatedly, in the messages they already receive
- Link directly to the relevant page rather than to a login screen
- Make password recovery painless, because most portal abandonment is a forgotten password
- Measure active users honestly, and be willing to conclude it is not being used