Customer Portals & Self-Service

Count how many calls your office takes in a week that are somebody asking a question your system already knows the answer to.

Where’s my order. Can you send me that certificate again. What did you charge us for the March job. Has the engineer been yet. Can I have a copy of the invoice.

Every one of those interrupts someone, and none of them needed a person. ☎

What goes in a portal

You decide what’s visible. It’s never the whole system.

For customers — order and job status, delivery dates, quotes and acceptance, invoices and statements, service history, certificates and documents, reporting a fault, booking a slot, updating their own details.

For suppliers and subcontractors — purchase orders, delivery confirmations, invoices submitted, specifications and drawings, compliance documents and expiry dates, job allocation and timesheets.

For your own staff — the people who only need to look something up, without a licence or a login to the main system.

The thing people underestimate is how much of the value sits in the dull half: statements, documents and history. That’s what generates the calls.

The part that has to be right

[IMG-1] — Diagram: one database, several customers, each seeing only their own slice. Clear boundaries. It’s the page’s core technical claim and worth drawing.
Alt: Data separation between customers in a shared portal

One customer must never see another customer’s data. Not by guessing a URL, not by editing a number in the address bar, not because somebody made a mistake setting up an account.

That’s the thing that goes wrong on portals, it’s usually discovered by a customer rather than by you, and it’s the sort of thing that ends a commercial relationship and becomes a reportable data breach in the same afternoon.

So separation is built in at the data layer, not bolted on at the screen. Every request is checked against who’s asking, on the server, every time — not filtered in the browser and hoped for. Access is by role and by account, tested deliberately, and logged so you can answer “who saw what, and when” months later.

It’s the least visible part of the job and the one worth paying for.

Who logs in, and how

External users aren’t staff, so they don’t belong in your staff directory.

Their own accounts, with email verification, self-service password reset and MFA where the data justifies it
Invited rather than open, in most cases — you decide who gets access, not whoever finds the page
Several people per customer, with different levels. The buyer sees pricing, the site manager doesn’t.
Access removed cleanly when someone leaves that company — which matters as much as adding it, and is the part everyone forgets
Microsoft Entra External ID where you want federated sign-in for business customers, or where a client’s own IT will insist on it

We keep it separate from your internal systems, so a portal account is never a route into anything else.

Documents, properly

Most portals end up being mostly about documents — certificates, drawings, test results, reports, invoices.

Stored outside the database so it doesn’t bloat, served through the application rather than from a public folder, with permissions checked on every download and a record of who took what. Expiry dates tracked where they matter, and versions kept so “which one did they have in March” is answerable.

Where a customer would rather have it arrive than go and look, the same documents and figures go out as a scheduled PDF or spreadsheet on whatever cycle suits them.

If you’re in a regulated sector, that audit trail is the point → [LINK: Azure and cloud → /azure-cloud/]

Their numbers, not just their records

[IMG-2] — A customer-side dashboard: spend to date, open jobs, response times, compliance status. Anonymised. Designed, not a default chart library output — this is customer-facing and it looks like you.
Alt: Customer dashboard showing their own activity and spend

Most portals show a customer their records. The good ones show them what those records add up to.

Spend — this month, this year, against last year, by site or department
Activity — jobs raised, completed, outstanding, and what’s booked in
Performance — response and completion times against whatever you’ve committed to
Compliance — which certificates are current, which expire next month, what’s outstanding. For anyone whose customers get audited, this alone justifies the portal.
Their own trends — usage by site, by asset, by category, over time

Two reasons this is worth more than it looks. It replaces the “can you send me a breakdown for our board meeting” email, which is usually half a day of somebody’s month. And a customer who can see, at renewal, exactly what you did for them all year is a considerably harder customer to lose.

One warning, and it’s the same one as above. Aggregate figures are where data separation goes wrong most easily — a total that quietly includes rows belonging to someone else. A wrong record is embarrassing; a wrong total that reveals another customer’s volumes is a different order of problem. Every aggregate gets the same server-side check as every record, and it gets tested that way.

For your own management information rather than your customers’ → [LINK: reporting and business intelligence → /reporting-business-intelligence/]

What it’s actually worth

This is the easiest business case on the site, because it’s countable.

Take the calls and emails your office handles in a week that a portal would answer. Multiply by the time each one takes, including the interruption. Most businesses we do this with land somewhere between half a day and two days a week of somebody’s time — every week, permanently.

Then there’s what you don’t see: the customer who didn’t ring because it was easier to look, the chaser that didn’t need sending, the invoice paid sooner because the statement was there at 8pm, and the complaint that didn’t happen because they could see where their job was.

It also helps with data protection. A customer who can see their own records, download their own documents and update their own details is a customer making fewer requests of you.

Built on the system you already have

The portal reads from and writes to your existing database. No second system, no nightly export, no reconciliation.

When your team updates a job, the customer sees it. When a customer uploads a document or raises a request, it lands in the system your staff already use, in the place they’d expect it.

Web: React and Next.js, working properly on a phone because half of them will be on one
Back end and APIs: .NET and C#, or Node.js and NestJS
Data: SQL Server or Azure SQL, with your existing application still attached → [LINK: Access migration and upgrades → /microsoftaccess/migration/]
Hosting: Azure, with the database on a private endpoint and never exposed
Your branding, because to your customers this is you, not a supplier’s product
BLOCK 9 — Start small

The mistake is building everything and launching it to everybody.

Pick the single question your office answers most often — usually order or job status — and build that. Give it to a handful of customers who’ll tell you honestly what’s wrong with it. Widen it once it’s earning its keep.

Your team carries on exactly as they were throughout.

[LINK: how we work → /about/howwework/]

Case studies

all case studies