Web and mobile apps 6 min

Client portal: giving clients access to their files

A client portal is an online space where each client finds, at any time, the progress of their file, their documents, their invoices and their requests. It reads data from your CRM or ERP without copying it, and shows each client only what concerns them: the server checks this on every request.

Contents7
  1. 01What a portal changes, for your clients and for the team
  2. 02What goes in it
  3. 03Three ways to get a portal
  4. 04One source, never a copy
  5. 05The golden rule: each client sees only their own data
  6. 06Getting it adopted
  7. 07Frequently asked questions

In many service businesses, part of the team’s time goes into answering the same questions: where the file is at, which document is missing, where the latest invoice is. The information exists, somewhere in the CRM, the ERP or a shared folder; it is the client who has no access to it. A client portal opens a window onto what concerns them, and only that.

In short

  • A client portal shows each client the progress of their file, their documents, their invoices and their requests, at any time.

  • It reads data from your existing software; it does not copy it.

  • Three routes: the portal built into your software, a custom portal connected to it, or a simple shared folder to start with.

  • Its golden rule: each client sees only their own data, and the server checks it.

What a portal changes, for your clients and for the team

Without a portal, a client’s question always follows the same path:

A client’s question, without a portal

  1. The question

    A call or an email, sometimes outside office hours.

  2. The search

    Someone on the team finds the file in the software.

  3. The answer

    An email, an attachment, sometimes the wrong version.

  4. The follow-up

    The client missed the answer, and calls back.

With a portal, the client checks for themselves, the team keeps its time for what truly needs a person, and the documents shared are always the latest version, since they come from the source.

The portal also helps meet an obligation. The GDPR gives everyone a right of access to their personal data, and recital 63 of the regulation envisages that, where possible, the controller should be able to provide remote access to a secure system giving the person direct access to their data. A well-built portal is exactly that.

What goes in it

A good portal starts small. The content that answers the most frequent questions:

  • Progress: the file’s stages, the current one, the next one, and what is expected from the client.
  • Documents: those you produce (quotes, contracts, reports) and those the client must upload, with their status.
  • Invoices: issued, paid, due.
  • Requests: a question or a document sent from the portal goes straight into the right file, with a trace.

The rest can wait until clients ask for it. A portal journey tests very well on a clickable prototype, with three or four real clients, before any development.

Three ways to get a portal

Your software’s portal

  • Included in some ERPs and CRMs, it is switched on without development

  • It shows what the software knows how to show, in its vocabulary

  • It is the first option to check

A custom portal connected to your software

  • It speaks your clients’ language and follows your stages

  • It reads and writes to your software through its API

  • It requires development and maintenance

The built-in portal. Some software has one. Odoo’s, for example, lets an invited contact view, read-only, their quotations, orders, invoices, projects, tasks or tickets, according to Odoo’s documentation. If your software covers your needs, it is the most economical route.

The custom portal. When the built-in portal shows screens designed for the software rather than for your clients, or when your software has none, a small app connects to it. This is the middle way described in custom-built or off-the-shelf: you keep the software that does the essentials well, and add only the missing window. It takes an API: Twenty, for example, offers REST and GraphQL APIs as well as webhooks, according to its documentation, and we explain in Twenty beyond the CRM how it serves as the back office for business data.

The shared folder. One folder per client in an online storage space is an honest starting point for a handful of clients. It reaches its limits when permissions are managed by hand folder by folder, and when the file’s progress lives somewhere else.

One source, never a copy

A portal that copies CRM data ends up showing outdated information. The rule is the reverse: the portal reads the source at the moment the client looks, and what the client sends goes straight into the source.

From the field

At Palmora Property, the CRM is the single source

At Palmora Property, a real-estate agency in Phuket that we work with, the self-hosted Twenty CRM is the single source of properties, contacts and deals. Every form on the website is saved to the database before any email is sent, then creates the contact and the deal in the CRM, and alerts the team in its channel. Details are in the Palmora case study. A request dropped into a client portal follows the same rule: saved first, attached to the right file next, never lost in an inbox.

The golden rule: each client sees only their own data

A client portal is, by design, an app where different clients sign in to the same database. The most serious flaw would be one client reading another’s file. It is not prevented by hiding buttons, but by access rules enforced by the server, row by row, as we explain in app security: accounts, sign-in and data. With Supabase, these are row-level security policies; the choice of back end is covered in Supabase, Firebase or your own server.

Two more points, often forgotten:

  • Several people at the same client. The manager, the accountant, the assistant: who sees the invoices, who sees the reports? Roles are decided at scoping.
  • Sign-in without a password. A client signs in rarely: a link or a code received by email spares them the forgotten password. At Supabase, that link or code expires after one hour by default, according to its documentation.

Getting it adopted

A portal nobody opens saves nobody any time. Three habits make it stick:

  1. Put the link everywhere.

    In every team email, every invoice, every signature: “your file is up to date in your space”.

  2. Notify, without sending everything.

    A “a document is waiting for you” message with the link, rather than the document as an attachment; the right dose is the one in our article on push notifications.

  3. Answer from the portal.

    When a question arrives by email, the answer points to the file in the portal.

A portal does not need the stores: a web app, possibly installable on the home screen, is enough in most cases, as explained in our PWA or native app comparison. Its cost mostly depends on the number of roles and on integrations, two lines of what makes the price of an app vary, and it is maintained like any app, following the maintenance budget after launch.

Our app development service starts with a written scope of what the portal shows on day one, and to whom.

Frequently asked questions

What is the difference between a client portal and a customer area?

None of substance: both describe an online space, protected by a sign-in, where each client views their information and exchanges with the business. “Portal” often stresses the link with internal software, “customer area” the client’s experience. What matters is what the space shows, and to whom.

Should we build a custom portal or use our software’s?

Start by checking your software’s: if it shows what your clients are looking for, in terms they understand, it costs less. Custom work is justified when the built-in portal does not exist, shows screens designed for your team rather than your clients, or does not follow your stages.

How do we make sure a client never sees another client’s data?

Through access rules checked by the server on every request, not by the interface. These rules are written before development, for each role, and tested with every release: a test signs in as one client and checks that it reads nothing belonging to another.

Does a client portal help with the GDPR?

Yes, for the right of access: recital 63 of the GDPR envisages that people can view their data directly through secure remote access. The portal does not replace the other obligations (records, security, retention periods), but it makes access simple and traceable.

Sources

  1. General Data Protection Regulation, EUR-Lex (new tab)eur-lex.europa.eu
  2. Odoo documentation, portal access (new tab)odoo.com
  3. Twenty documentation, developers (new tab)docs.twenty.com
  4. Supabase docs, passwordless email sign-in (new tab)supabase.com
Source 1

General Data Protection Regulation, EUR-Lex

Read on eur-lex.europa.eu(new tab)
Source 2

Odoo documentation, portal access

Read on odoo.com(new tab)
Source 3

Twenty documentation, developers

Read on docs.twenty.com(new tab)
Source 4

Supabase docs, passwordless email sign-in

Read on supabase.com(new tab)

Jim · founder of Brain Plus AI

Also in web and mobile apps

  • Understand7 min

    App security: accounts, sign-in and data

    The most common flaw in an app is not a guessed password, it is a forgotten access rule that lets one user read another’s data. Here is what really protects your users’ accounts and data.

  • Choose and price6 min

    Business app: custom-built or off-the-shelf software?

    Off-the-shelf software costs less as long as your way of working fits its boxes. Here are the signs that tip the balance towards custom, and the middle path that is often forgotten.

  • Choose and price6 min

    App back end: Supabase, Firebase or your own server

    Behind an app’s screens you need accounts, a database, files and rules. Supabase, Firebase and your own server answer this in three ways, and each commits you to different things.

WhatsApp