Portals remove support contacts
The questions customers ask most — where is my order, what did I pay, when is my next service, can I have a copy of that invoice — are all answerable from data you already hold.
A portal answers them at any hour without anyone being involved, which is why the support volume reduction is usually the main business case.
Start read-only
- Phase one: customers can see their own information
- Phase two: they can download documents and update contact details
- Phase three: they can raise requests or place repeat orders
Read-only phase one delivers most of the support reduction at a fraction of the risk. Write access is a different security conversation and it can wait.
Authorisation is the whole security question
- Every query filtered by the authenticated customer, without exception
- Never trust an identifier from the request to determine ownership
- Test deliberately with two accounts, trying to see each other's data
- Audit every access to customer records
The classic portal vulnerability is a URL with a record identifier that is not checked against the logged-in user. It is trivially exploitable and depressingly common.
Authentication practicalities
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 is appropriate where the data warrants it and it adds friction that reduces adoption, so weigh it deliberately.
Show the right things
| Show | Do not show |
|---|---|
| Their orders and status | Internal notes about them |
| Their invoices and payments | Your margin |
| Their service history | Other customers' anything |
| Their documents | Internal system identifiers |
| Their contact details | Staff comments |
Internal notes surfacing in a customer portal is an embarrassing and entirely avoidable incident.