Customer portals without manual work: from 3 to 30 clients

A customer portal that works with three clients often stalls at thirty. Each new customer then means creating another separate account, figuring out rights and manually checking who may see what. A well-designed customer portal solves this by automatically governing rights, data and access based on who logs in, not based on what someone adds themselves.

Secure access with row-level security

Row-level security (security that determines per user which data rows are visible) ensures that client A never sees the figures of client B, even though everything runs on the same platform. The rule is set up once at data level, not again per user.

You notice that difference as soon as you grow. With three customers you can still manage access with a spreadsheet and some manual work. At thirty that becomes error-prone: someone forgets to disable an account, or a new employee accidentally gets rights that are too broad. Therefore set up the security at the level of the data itself, linked to Azure AD or SSO, so access grows automatically with every new client.

Want to know whether your current setup can already handle this? Pull out your spreadsheet or list of user rights today and check in five minutes: are there accounts that have not been used for months, or employees with access to more customers than their role needs? If you see one example of that, that is the signal that manual rights management is starting to stall.

Multi-tenant portal for teams, partners and customers

A multi-tenant portal (one environment that serves multiple customers or partners safely at the same time) prevents you from having to build a new environment for every client. One platform, different shielded entries.

In practice we see at clients that this is exactly the point at which manual solutions turn into a problem. Each new customer then does not ask for a new configuration, but for a new row in the same secured structure. Choose a setup in which employees, partners and customers consult the same underlying data, but each get their own bounded view.

Work orders and customer files in one environment

For installation companies and transport companies this means that work orders, schedules and customer files sit in the same layer. The technician sees their schedule, the customer sees only the status of their own job.

Sharing data without risk

Sharing data with partners and customers does not have to mean that everyone sees everything. With row-level security as the basis you determine per role exactly which part of the dataset is visible, without making copies or separate exports.

At Runderkamp this works with price records and supplier data that sit standardised on one platform, where each party only sees their own part. Set this up by first recording which data source has which owner, and only then attach the sharing rules. That way you share data with suppliers, technicians or customers without needing a new tool for every exception.

Governance from day one

Governance (the agreements and technology that determine who may see and change which data) only works if it is built in from the start, not as a separate layer afterwards. A portal that later has to be "secured" costs more work than a portal that from day one runs with DTAP environments.

DTAP (Development, Test, Acceptance, Production: separate environments to test changes safely) prevents a change for customer A from accidentally becoming visible at customer B. Put new connections in a test environment first before they go live, even with a small customer portal with only a few clients.

Analytics and AI directly in the portal

A customer portal only becomes truly usable when dashboards and AI functions run on the same underlying data as the rest of the platform. That way a client not only sees a report, but can also ask a question about their own figures.

That only works if the rights that apply to the portal also apply to the analytics and AI layer behind it. Therefore set up one shared data layer that reports and agents (AI functions that independently carry out tasks based on data) draw from, instead of separate connections per function.

Logging in to the customer portal

Logging in to a well-designed customer portal goes via SSO or Azure AD, whereby the rights are applied immediately after login. The user does not need to know which rules sit behind it; those rules are already recorded at data level.

For a client this means that the first visit immediately shows the right, bounded view. No extra setup work, no manual assignment per new account.

A customer portal that scales from three to thirty clients does not run on extra manual work per customer, but on row-level security and a multi-tenant setup that is right from the start. Unsure whether your current setup can handle that? Book a Discovery Call and we will look together at where the biggest gain sits.