Giving Customers Access to Their Own Information

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

1. Phase one: customers see their own information
2. Phase two: documents downloadable, contact details editable
3. 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

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

Frequently asked questions