Portals remove support contacts
Where is my order, what did I pay, when is my next service, can I have a copy of that invoice. All answerable from data you already hold, at any hour, without anyone being involved.
That support volume reduction is measurable within weeks and is usually what justifies the build.
Start read-only
- Phase one: customers see their own information
- Phase two: documents downloadable, contact details editable
- Phase three: requests raised, repeat orders placed
Read-only phase one delivers most of the support reduction at a fraction of the risk. Write access is a separate security conversation and it can wait.
Filter every query
- Every list filtered by the authenticated customer
- Every detail view checking ownership before rendering
- Never trusting an identifier in the URL
- Exports and downloads filtered the same way
- Enforced centrally rather than remembered per view
The classic portal vulnerability is a URL with a record identifier that is not checked against the logged-in user. It is trivial to exploit and common.
Make login easy
Customers forget passwords and will not tolerate a difficult login. Passwordless email links or a simple password with a reliable reset both work better than complex requirements.
Two-factor authentication where the data warrants it, weighed against the adoption cost, which is real.
Show the right things
| Show | Never show |
|---|---|
| Their orders and status | Internal notes about them |
| Their invoices and payments | Your margin |
| Their service history | Anything about other customers |
| Their documents | Internal identifiers |
| Their contact details | Staff comments |
Internal notes surfacing in a customer portal is an embarrassing and entirely avoidable incident.