Client portals

Setting Up a Client Portal: Structure, Naming and the First Invite

How to set up a client portal people return to: a simple structure, names that last, what to add on day one and how to send the first invite.

By Ayebridge TeamPublished 7 min read

Abstract illustration of a portal window with three tidy project panels and a small invitation envelope

Why setup decides whether a portal gets used

A client portal is only useful if the client opens it without being reminded. That habit forms, or fails to form, in the first week. If the first visit shows an empty page, unclear folder names and nothing to do, the client goes back to email, and the portal becomes one more place you have to keep up to date.

The good news is that setup is mostly decisions, not work. You decide how projects are organized, what things are called, what the client sees first and how you introduce it. This guide walks through each of those decisions in the order you will meet them.

Decide the structure before you upload anything

Start with a sketch on paper. A structure that is easy to explain in one sentence is easy for a client to navigate.

A pattern that suits most freelancers and small studios:

  • One portal per client. The client is the company or person who pays for the work. Everyone at that client who reviews or supplies material is a contact inside the same portal.
  • One project per piece of work. A website rebuild, a brand refresh and a quarterly content retainer are three projects, not three folders in one project. Each has its own status, dates and description.
  • A few folders per project, named by purpose. For example: "Brief and references", "Work in review", "Final deliverables". Three or four folders are easier to scan than ten.

Resist building the structure you might need in a year. The Nielsen Norman Group's guidance on progressive disclosure applies here: show the few things people need most and keep the rest out of the way until it matters. You can always add a folder when a project actually needs it.

In Ayebridge, each client gets a private portal with its own address, and projects live inside it. The client portals page shows how the pieces fit together.

Names that still make sense six months later

Names are the main way a client finds things, and they are hard to change once people have learned them. A few rules keep them readable.

Project names should say what the work is, not what it was called in your sales pipeline. "Website rebuild 2026" is clearer than "Phase 2" or an internal job number.

Folder names should describe what is inside from the client's point of view. "Final deliverables" tells a client where to look at the end of a project. "Exports" does not.

File names should describe the content and leave the version to the system. If your portal keeps versions for you, a file called homepage-design.pdf with versions 1, 2 and 3 is easier to follow than three separate files called homepage-v2-final-FINAL.pdf.

Instead of Try
Phase 2 Website rebuild 2026
Stuff from client Brief and references
Exports Final deliverables
logo_v3_final_new.png primary-logo.png (version 3)

Write names in plain words. The GOV.UK guidance on writing for user interfaces makes the same point for any interface: short, plain labels help people finish what they came to do, including people reading in a second language.

What to put in on day one

The first visit sets expectations. An empty portal says "nothing to see here", and people believe it. Research on empty states recommends using any empty area to explain what will appear there and to offer a clear next step. You can do the same with content.

Before you invite anyone, add:

  1. The project, with a status, dates and a one-paragraph description. The description should say what is being delivered and roughly when.
  2. A first update. Two or three sentences: where the project stands, what happens this week, and what you need from the client.
  3. One or two open requests. The first things you need, such as brand files, access details or a list of reviewers, each with a due date. Requests give the client something concrete to do on the first visit, which is the fastest way to make the portal feel useful. The requests feature turns each of these into a checklist item the client can answer, attach files to and mark done.
  4. Any reference material you already have. The signed proposal or scope summary, if you keep one in the portal, so the client can find it later.

That is enough. Do not upload a backlog of work in progress just to make the portal look busy.

Write a welcome message that does one job

If your plan includes branding, the portal home page can show a welcome message. Keep it to what a first-time visitor needs: what this place is for and what to do first.

A template you can adapt:

Welcome to your project portal. This is where we will post progress updates, share work for review and ask for anything we need from you. To get started, please look at the open requests on the project page. You will get an email whenever something needs your attention.

Avoid instructions that depend on the reader knowing how the portal works. "Open the project and look at the requests" is clearer than "Check the Requests tab under the relevant project."

Send the first invite with a heads-up

An invitation from an unfamiliar sender is easy to ignore or lose to a spam filter. A short message from you, sent first, fixes both problems.

Who to invite first. Start with the one or two people who will review work or supply material. You can add others later. A smaller first group makes it easier to see whether the invite arrived and whether the first visit made sense.

What to send before the invite. A note from your own email address, for example:

I am setting up a private project portal for us. In a minute you will get an email with a sign-in link. There is no password to create; each time you visit, you request a new link to your inbox. Everything for the project, including updates, files for review and the things I need from you, will be in one place from now on.

Then send the invitation. In Ayebridge, client contacts sign in with a magic link sent to their email, so there is no account or password to set up. The inviting clients help article covers the steps, including what to check if an email does not arrive.

Look at the portal from the client's side

Before and after the first invite, open the portal as the client would see it. Ayebridge lets team members preview a portal as the client sees it, which makes this a two-minute check.

Look for:

  • Anything internal. Draft names, test files or notes meant for your team.
  • Empty areas without explanation. If a section is empty, is it obvious why and what will appear there?
  • The next step. Can a first-time visitor tell what they should do within a few seconds?
  • Names that only make sense to you. Abbreviations and job numbers are the usual suspects.

Fix what you find before the client finds it.

Keep it alive after the first week

A portal stays useful when it is the place where things actually happen. A few habits help:

  • Post work in the portal first, then mention it by email if needed. If the email is the only place the link lives, the portal loses its role.
  • Move decisions back into the portal. When a client answers by email, record the decision in the portal and reply with a link to it.
  • Post a short update at a regular rhythm. Even a quiet week deserves a one-line update, so the client learns that the portal is always current.
  • Close requests promptly. A request the client answered three weeks ago that still shows as open makes the whole list look stale.
  • Archive finished projects. The history stays available, and the client sees only the work that is current.

Client portal setup checklist

Use this list for each new client:

  • Client created, with a clear name for the portal address
  • One project per piece of work, with status, dates and a short description
  • Three or four folders named by purpose
  • File names that describe content; versions kept by the system
  • First update posted
  • One or two open requests with due dates
  • Welcome message written, if your plan includes branding
  • Heads-up email sent from your own address
  • First contacts invited
  • Portal checked from the client's side
  • A reminder set for your first regular update

None of this takes long. What matters is doing it before the first invite, so the client's first visit shows them a place worth coming back to.

Frequently asked questions

Should each client get one portal or one portal per project?

One portal per client usually works best. Put each piece of work inside it as a separate project, so the client has a single address to remember and you can archive finished projects without losing their history.

How much should I put in a portal before inviting the client?

Enough that the first visit answers three questions: what is happening now, what the client needs to do next, and where the work will appear. A project with a description, one short update and one or two open requests is usually enough.

What if a client keeps replying by email instead of using the portal?

Answer the question, then post the decision or file in the portal and send them the link. Doing this consistently teaches the habit faster than asking people to change how they work.

Sources

  1. Progressive Disclosure (Nielsen Norman Group)(nngroup.com)
  2. Designing Empty States in Complex Applications (Nielsen Norman Group)(nngroup.com)
  3. Writing for user interfaces (GOV.UK Service Manual)(gov.uk)