Giving Customers Access Without Giving Them Your System

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

1. Phase one: customers can see their own information
2. Phase two: they can download documents and update contact details
3. 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

Internal notes surfacing in a customer portal is an embarrassing and entirely avoidable incident.

Frequently asked questions