Self-service
Customers should see the state of the work without asking someone to look it up.
PrimeLabs builds secure portals for customers, clients, members, suppliers and partners. The person signs in, sees the records they are allowed to see, and can tell what they are supposed to do next.
Example interface. Not a client project.
Signed in
Alex Morgan
Northstar Advisory
Client account
What needs you
Website onboarding is waiting for a client
Latest message: the project team asked for the domain access details.
Request · Website onboarding
Confirm who controls the domain
Timeline
- 26 Sep · Project team asked for the DNS contact.
- 18 Sep · Staging site shared with Alex Morgan.
- 12 Sep · Onboarding request opened.
Confirming the contact tells the project team who can approve a DNS change. It does not change the domain.
Nothing has been confirmed.
Documents for this organisation
- Statement of work — website onboarding
- Staging notes — 18 Sep
- Brand files — logo pack
These three files are the ones this account can open. A file from another client is not in the list.
INV-1048
Project team
26 Sep · “Please confirm who we should contact before any DNS change.”
The message points at the onboarding request. It is not a second place where the status lives.
Ask about this account
The question is answered from records Alex Morgan can already see. It is not sent to a person, and it does not change the request.
Ask from the records this account can see.
The office already has the answer. The customer cannot see it.
A typical portal brief starts as a queue of repeated questions. What is the status? Where is the document? Has the invoice been paid? Which step is waiting on us? Staff look up a record they could have shown. Files travel by email. The request is in one product, the booking in another, the payment somewhere else, and none of them agree on what the customer was last told.
A customer portal, client portal or member portal is the signed-in view of that relationship. It is not a brochure with a password. People come back because something of theirs lives there: a request, a file, an invoice, a booking, a message that belongs to the same record. Outside office hours, that view is the service.
Supplier, partner and account portals are the same idea with a different audience. PrimeLabs does not split them into separate thin offers. The audience changes the records and the permissions. The engineering question is the same: who may see this object, and what may they do with it?
A login screen is not the product.
Authentication gets someone in. The portal earns the return visit by making the current state obvious.
Current state
The first screen says what is waiting, on whom, and what the next action is. The onboarding example does that before it offers a menu.
Obvious actions
If the customer must confirm a contact, that control is on the request. It is not buried in a message thread.
Navigation by goal
Requests, documents, invoices and messages are how the person thinks. They are not a map of the database.
A phone-sized screen
People check status away from a desk. The same record has to be readable there, including the action.
Confirmation
An action says what it did, and what it did not do. A mistaken tap has a way back.
Notices that point back
Email and other alerts can say that something changed. The portal remains the place the status is true.
What a portal can hold
Account details. Documents. Invoices and the fact of a payment. Service requests. Bookings. Messages. Forms. An approval the user is allowed to give. A download. A short report on their own activity. Search over help material they are allowed to read. An assistant that answers from those same records.
Not every portal needs every one of those. A member who only books a court does not need an invoice module added for symmetry. A client who only exchanges documents does not need a shop. The homepage separates customer portals from member portals because the records differ. The build is still this one: a permitted view of a relationship.
Staff-facing consoles are a different page. If the problem is an internal queue rather than an external user, that is internal business applications. If an upload has to become checked fields, that is a document workflow. If confirming something here has to move a multi-stage run, that is workflow automation.
Security, in the language of a portal
Someone proves who they are, and the session stays on that browser until it should end. A second organisation’s files are not a filter away. The check is on the object: this user, this account, this document. A role that can read invoices does not automatically get to change the billing contact.
A download link is issued after that check, not stored as a public address. Sensitive fields are not copied into an email notification just because the notification is convenient. Repeated attempts to guess a session or scrape a list are limited. When something important happens — a sign-in, a download, a confirmation — the application can record that it happened.
That is the working set. It is not a claim that a portal is finished because it uses a hosted login. The same rule appears in web application development: edge controls do not replace the check in the request.
One person, or an organisation with several people
Some portals are a single user and their records. Others are an organisation: several people, different permissions, more than one account, and a colleague who should see the request without seeing payroll. Delegated access is a real requirement when an assistant manages the relationship and the principal must still be the one who confirms a change.
None of that is the default. A two-person client does not need the model built for a franchise. Tenancy is added when the records would otherwise leak, or when two organisations must share one application without sharing data. How the platform keeps those boundaries is part of the Cloudflare application design, chosen for the portal in front of you rather than imported as a full stack.
An assistant that can only see this account
On a portal, a model is useful when it explains the status, finds a document the user is allowed to open, summarises recent activity, drafts a support note, or walks someone through a step they were going to ask the office about. The question on this page — what are you waiting on from us — is answered from the onboarding request already on the screen, and it names that request.
It does not search another customer. It does not invent a status. A write, including “I confirm the DNS contact”, is a button the person presses, separate from the answer. The wider rule is on the AI application development page.
When a sign-in is worth building
Build it
- Customers, members or partners come back to the same relationship.
- They need ongoing access to records, files or status.
- Staff answer the same “where is it up to?” question.
- Documents or requests are exchanged more than once.
- The person must do something securely: confirm, book, download, pay, or approve.
Skip it
- The contact is rare. Email really is enough.
- There is no recurring reason to sign in.
- The organisation cannot keep the underlying record current. A portal would display a stale promise.
- The need is a public page, not an account.
Start from the question people already ask
A useful brief names who signs in, what they need to see, what they must be unable to see, and the one action that should not require an email. There is no account on this website and no form.
Related
Straight answers
Is this only for customers?
No. Clients, members, suppliers and partners are the same product shape when they need a signed-in view of their own records. The permissions change with the audience.
Can one user open another organisation’s documents?
They should not be able to. The check is on the object, after sign-in, not only on the menu.
Can the assistant update the request?
Not by answering. On this page, confirming the DNS contact is a separate button, and even that button is only a demonstration.