A portal where clients and suppliers serve themselves, and each one sees only their own part

Three ways to sign in, permissions by role, and every action on record. What this application is, what it is actually for, and what you can do with it.

by Nadia Maar · 30 August 2026

It is the piece of software companies build last and then use every day: the front door to their own data for people who are not employees. The supplier updating a price list, the reseller checking availability, the large client who wants to see their orders without phoning.

Today that work is done by hand — emails, attachments, phone calls — not for lack of will, but because opening your systems to an outsider looks complicated. It is not: it is three well-defined pieces, and this article walks through them with the application in front of you.

1 · What it is, in one sentence

A private area where every person outside the company signs in with their own identity, sees the slice of data that concerns them, and can do a precise list of things. It is not a website with a shared password: it is a system that knows who is talking and adapts what it shows accordingly.

Put negatively — which is often clearer: no files swapped by email, no records retyped by hand, no phone call to ask “where is my order”, no price list updated by you on the supplier's behalf. Each of those becomes something the interested party does themselves, when it suits them, and that reaches your systems already correct.

• For the supplier: update their own price list and availability, confirm the orders that concern them, upload documents and invoices. The same things they email you today, without anyone having to transcribe them.
• For the reseller or B2B client: consult price lists at their own discount level, see order history, reorder in two clicks, download invoices and delivery notes.
• For your sales team: see the same screen the client is looking at while they are on the phone, without rebuilding the context from three different systems.
• For management: know at any moment who did what, without having to ask anyone.

When it is worth it, concretely

The practical threshold is low: about ten external counterparties writing to you regularly is enough for a portal to start paying for itself in hours saved. Below that, manual work is still sustainable and waiting is sensible. Above it, every new supplier adds fixed work for somebody in the company — and that is the point where automation stops being a luxury.

2 · How people sign in: three doors, one identity

Sign-in is the first thing anyone sees and it decides whether the portal gets used at all. A complicated one gets abandoned on the second attempt, and everyone goes back to email. So there are three ways, chosen according to who is coming in.

• Password, when the counterparty is used to it and signs in often. Simple, familiar, with a second factor where the data deserves it.
• Emailed code, for whoever comes in twice a year. No password to remember or recover: type the address, receive a code, come in. It removes the “I forgot my password” call, which in B2B portals is the leading cause of support.
• Corporate SSO, for structured counterparties who already have an identity system. They sign in with their own company credentials, and when a user is disabled there they stop being able to sign in to you as well. Nobody has to remember to do anything.
• The second factor, switched on only where it matters: on roles that see margins, reserved price lists and customer records. A six-digit code is a four-second annoyance, and it belongs where those four seconds are worth something.

The panel above shows the three ways living in the same card. It is worth actually opening it from the button: the demo card works, second factor included, and you can even change the branding live to see how it would look in your colours.

3 · Who sees what

This is what makes a portal usable with outsiders without worry. Permissions are not granted to a person, they are granted to a role: when a new supplier arrives you put them in the right group and they automatically see the right thing. Tap a role to read what it can do — and above all what it cannot.

• External supplier — What it CANNOT do: Cannot see other suppliers, cannot see your margins, cannot see end-customer orders. This is the role where boundaries matter most, because what you show leaves the company.; What it can do: Updates their own price list and availability, confirms the orders that concern them, uploads documents and invoices. They see their half of the relationship, complete and always current.
• Reseller — What it CANNOT do: Cannot see other resellers' prices or your purchase costs. The “partial” on records is the convenient rule: they edit their own delivery details, not their billing ones.; What it can do: Consults the price list at their own discount level, orders, reorders from history, downloads invoices and delivery notes. All without asking anyone for anything.
• Internal sales — What it CANNOT do: Does not create or disable users, and does not see the margin of products they are not handling. The “partial” on margins is the most useful rule in the grid: they see their own orders' margin, not the company's.; What it can do: Builds offers, applies discounts within their given limit, updates their own customers' records, and sees the same screen as the client while talking to them on the phone.
• Management — What it CANNOT do: On paper nothing — and precisely for that reason the log in the next section applies to this role too, with no exceptions.; What it can do: Everything, including creating and revoking users in one place: when a counterparty changes contact person, you update it here and it applies everywhere.

4 · What stays on record

Every sign-in and every meaningful change leaves a line. It is not there to police anyone: it is there to answer in seconds questions that today take half a day of phone calls. “Who changed this price?”, “has the new contact been enabled yet?”, “did the supplier see the order or not?”.

access and change log — Tuesday 25 · extract

Forty-eight seconds. That is how long it takes to answer “who changed that price” when the rows above exist. It is also the simplest way to show a large client that their data is handled in an orderly way — a question that always comes up in tenders.

The two highlighted rows are the ones people actually go looking for. The first says who changed a price, when and by how much: no reconstruction needed. The second keeps a record of an approval — and a credit limit raised without a trace is the kind of thing that becomes a problem months later, when nobody remembers why.

5 · How it gets built, and in what order

It is not a months-long project before you see anything. It is built in layers, and every layer is already useful on its own: you can stop after the second and still have removed most of the manual work.

• First: sign-in and roles. Counterparties come in and see their own data read-only — orders, documents, price lists. A few weeks, and from here alone the calls asking for information the portal already shows disappear.
• Second: writing. The supplier updates the price list, the reseller orders, both upload documents. This is the layer that removes transcription work from your side, and the one that pays back most.
• Third: integrations. The portal stops being an island and talks to the ERP: what comes in here reaches there with no manual steps. It comes later, once it is clear which data actually matters.
• Fourth: the finishing that decides daily use — notifications, exports, the client's own branding on their screens. Small things that decide whether the portal is adopted or merely tolerated.

The cost, honestly

A portal with sign-in, roles and read-only consultation runs between fifteen and thirty thousand euros; with writing and ERP integrations it goes up, and that depends almost entirely on how many systems must talk to each other and what state their data is in. The figure that matters is a different one: how many hours a week your company currently spends transcribing, searching and replying. We find that number together in half an hour.

Half an hour to tell whether you need one, and what shape it would take

In the audit we look at three concrete things: who the external counterparties writing to you regularly are, what exactly they ask for, and how many hours a week answering costs. From there it is immediately clear whether a portal makes sense and which layer to build first.

If the answers show the counterparties are few and the requests rare, I will say so: at that point a well-built form and a couple of automations are worth more than a portal. But that too is an answer with numbers under it, which you do not have today.

The service behind this article

Custom web application development

If this was useful, carry on from here

• A CRM salespeople update because it pays them, not management — Visual pipeline, complete client record, a report in one click. What this application does, and why the CRM problem was never the software.
• An AI agent inside business processes: where it actually works, what it costs, and the three cases where it is the wrong answer — Not a chatbot on your website. An agent that reads your data, answers citing its source, and hands over to a person when it does not know — with the numbers to tell whether it is worth it.

FAQ

How do you let clients and suppliers into a portal without handing out passwords?

With three doors leading to the same identity: an email link, with no password to remember or steal; sign-in with the Google or Microsoft account they already use; password with a second factor for those who prefer it. The point is not offering choice, it is that the identity stays single — so revoking access actually revokes it everywhere, instead of leaving a shared credential nobody can trace any more.

How do you handle role-based permissions in a company portal?

You write down first what each role must NOT be able to do, and put it in a grid: roles against actions, every cell filled. It is the only way to notice the combinations nobody considered, such as a supplier seeing another supplier's price list. Then the restriction lives in the database, not in the interface: hiding a button is not a permission, it is a suggestion.

Why keep a record of who did what in a portal?

Because without one, every argument about a changed price or a vanished order becomes one person's word against another's. A useful log records time, person, action and origin, and keeps the previous value next to the new one: it lets you answer in two minutes instead of two days. It is also the same trail that makes it demonstrable, when someone asks, who could see that data.

In what order do you build a portal with a private area?

In layers, each useful on its own: identity and roles first, then the data each party can see, then the actions they can take, then the log. The first layer in production is already worth something — whoever comes in is who they claim to be — whereas waiting for the complete portal before switching anything on is the most reliable way to switch nothing on for six months.

Nadia Maar