Give your customers a login instead of an email thread.

It's scoped individually, so there's no figure to publish here. What moves it is how much your customers need to see and do, how many of your systems the portal reads from, and whether payments run through it. After a strategy call you get a written scope naming every screen and every integration, with the cost attached to each.

No. It reads from the systems you already run and shows each customer their own slice of what's there. Your team keeps working where they work today. Nothing gets copied, so there's no second version of a record quietly drifting out of date.

Each customer signs in with their own account. Email and password, a sign-in link, or single sign-on where it fits. Separation lives in the database itself, in row-level access rules, so one customer can't query another's records no matter what the screens happen to be showing. That design gets checked in the security review before handover.

Yes. With a Stripe integration they can open an invoice and pay it by card or bank debit without leaving the portal, and the payment lands against the right record in your accounting. Card details never touch your servers. Stripe's hosted elements handle them.

Yes. It lives on your domain, carries your logo and colors, and sends its notification emails from your domain too. Your customers see your company the whole way through. There's no third-party tool peeking out from behind your logo.

That's the one failure that can end a client relationship in a single afternoon. It's why the separation gets enforced down in the database, underneath anything the interface decides to show. A portal that hides other customers by choosing what to render is one bad URL away from showing the wrong invoice. Row-level access rules mean the query itself can't return another customer's record, whatever gets asked for. We test that before handover, and it's the first thing we check when we inherit somebody else's portal.

They log in when it answers their question faster than an email would, and not otherwise. So the three things people call about have to sit on the first screen after sign-in, with no menu in the way. Where's my job, what do I owe, where's that document. It also means the notification email telling someone something changed should link straight to the thing that changed. Portals fail on this far more often than they fail on technology.

Keep serving them the way you do now. A portal is one more channel, and a customer who'd rather phone isn't a problem to be solved. For those accounts the value lands on your side of the desk. Your team picks up and reads out the same record the portal would have shown, so nobody's digging through three systems while the customer waits. Nothing in the build should force a customer to change how they reach you.

Yes, and past a certain account size you'll need it. A site manager sees their location, a head office contact sees all of them, and an accounts payable clerk sees invoices and nothing else. You define those roles during discovery. They then get enforced in the same access rules that separate one customer from another, so a role is a real boundary. The menu isn't what's protecting anything.

It keeps working. The portal reads through an interface, so it isn't welded to one vendor, and that's the practical argument for owning it. When the accounting system or the operations system underneath changes, you rewrite the piece that talks to the new one and your customers keep the portal they've already learned. A portal that's a module inside the platform you're leaving leaves with it.