Create a portal for client onboarding

If you've set up Client Portal and then stalled on what to actually put in it, build a client onboarding portal first.

It's the portal every client needs, it barely changes between them, and it's the only part of your process that isn't tied to a specific piece of work. It's also the easiest to get right, which matters when you're staring at an empty portal trying to decide how much of the client relationship belongs in it. We've built one as an example, and there's a link to it further down so you can click through the whole thing.

Why should an onboarding portal be separate?

Most people doing client work have some shape to what they sell. Often it's a core service with a few optional extras attached, or three or four distinct services, some productized and some custom, priced however you price them.

Whatever that shape is, onboarding sits outside it. It isn't a service you sell. It's the thing that happens before any of them start, and it runs the same way regardless of which one the client ends up buying.

Onboarding happens once, everything else repeats

Every client goes through onboarding, and for most agencies the content of it barely changes between them. Same contract process, same questionnaire, same request for brand assets, same explanation of how you work and how quickly you reply to things.

Then it's done. The client moves on to whatever they bought, and if they come back next year for a second project, they don't get onboarded again. You already know how they like to work and you already have their logo files, so they just start a new project.

That's what makes onboarding awkward inside a project portal. It isn't part of the project, it's the thing that got them to the project, and lumping the two together means the piece you built once has to be rebuilt every time you take on new work.

It's small, fixed, and useful to every client you take on

Onboarding is also the easiest portal to build, which is the practical reason to start there rather than anywhere else.

It's more or less identical for every client, so you build it once and duplicate it. Nothing in it is tied to a particular project, so nothing goes out of date when the work changes. And it's the first thing a new client logs into, which happens to be the point where they're forming an opinion about how organized you are.

Starting with a project portal is harder work for less return. You're designing around the specifics of one job and then wondering how much of it will carry over to the next one.

What should you put in a client onboarding portal?

Everything you need from a client before you can start work, and everything they'll want to know about working with you. That's usually a handful of tasks for them to complete and a couple of pages explaining how things run.

Here are some examples of what you could include:

• Welcome and how we work (your process, communication, revisions)
• Contract
• NDA, if you use one
• Questionnaire
• Asset upload
• Kickoff call booking
• Invoices
• Practical resources: Slack, FAQ, the tools you use together
• Service add-ons, like a care plan or a power hour

What doesn't go in it is anything to do with the work itself. No deliverables, no status updates, no review links. Those change constantly and belong wherever the project lives, which might be a separate portal or might be your project management tool.

See an example of an onboarding portal

We've built an onboarding portal as a working example, to give you some idea of what you could include in yours.

👉 Have a look at the client onboarding portal example

Take the parts that fit your process and ignore the rest. A small portal with six modules that you'll keep up to date is more use than a large one that impresses someone once and then goes stale, and most of what's in the example won't apply to you. Plenty of agencies skip the NDA, plenty don't use Slack.

 

Once you have an onboarding portal, what's next?

Add portals as the work calls for them rather than designing the whole system up front. A portal per project, or one per service if what you sell is productized enough for that to make sense.

Keep them lean. A project portal holds the deliverables, where things are up to, and the files, which is most of what a client opens a portal to find anyway.

When a client comes back for a second project, they get a new project portal and their onboarding portal stays exactly where it is, still holding their contract and their questionnaire answers. Nothing needs rebuilding.

So if you're not sure where to start, start with the portal that's the same for every client. It takes an afternoon, it never goes stale, and it's the one that gets used before anything else exists.