Sharing work with clients: what they should see

How to share a project with clients: what a free guest can see and change, how to keep internal work private, and when a client counts as a paid user.

Gareth Thurlow 8 min read

The invite dialog on a job: tom@northwind.co typed into Email addresses, a line saying someone new joins as a free guest who sees that project only, a preview marking Tom as new with an invitation to send and no change to the paid seats, and a Send invitation button.

Clients want to see how their work is going, and you want their feedback in one place rather than scattered across email and chat. What nobody wants is a client reading the team's half-formed ideas, or spotting another client's name on the board.

Sharing a project with clients comes down to where you draw the line. This article sets out what a client needs to see, what they don't, and how to set it up so the line holds without anyone having to police it.

Why client access goes wrong#

Most agencies end up at one of two extremes.

The first is too little access. The client gets a status email on Friday, a screenshot of the board, or a PDF report. They're always a week behind, and their feedback arrives in a reply that has lost its context.

The second is too much. The client gets a login that shows everything. They read the internal debate about their own brief, see rough work before it's ready, and learn which other brands the studio works with. The team notices, and starts writing comments for the client instead of for each other.

There's often a third problem underneath: cost. When every client login is a paid seat, clients get left out, or share one login between five people.

Decide what the client is there to do#

Before you invite anyone, be clear about what a client does on your project. In most client work it's three things:

  1. Give feedback on the work, where the work is.
  2. Approve what you send for sign-off, or say what needs to change.
  3. Supply what you need from them: content, logins, brand assets and answers.

They don't need to plan your team's week, reorder the board or see what else the studio is working on. Design the access around those three jobs and most of the decisions make themselves.

The four roles, and which one a client gets#

Skybase has four roles. The one you pick decides what someone sees, what they can change and whether they count as a paid user.

Role Who it's for Billing
Administrator Runs the workspace: people, billing, project settings and automations Counts as a user
Team member Your staff and regular freelancers Counts as a user
Single-project guest A client or freelancer on one project Free on every plan
Multi-project guest A guest on more than one project Counts as a user

For most clients the answer is a single-project guest, and they don't count on either plan, however many you invite: not towards the Free plan's 5 users, and not on a Pro bill of $3.99 per user per month. How each plan bills guests has the details.

What a guest can see#

A guest sees the projects they belong to, and nothing else in the workspace. Inside that project, they see:

  • every job on the board, not only the ones they're part of
  • the comments and files on those jobs
  • the same board, table and calendar views as the team
  • Reports, counting only the projects they belong to

They don't see other projects, or the project's automations.

The first point is the one to plan around. Guest access works by project, not by job. If a job is on the board, the client can open it and read its thread.

What a guest can do#

Guests can take part fully in the conversation. On any job in their project, they can:

  • comment, @mention people and react
  • upload files
  • approve, approve with changes or request changes when someone names them as an approver
  • raise new jobs

They can only change jobs they raised, are assigned to or were added to as a collaborator. On those jobs they can add or remove labels the project already uses, change the due date, tick off tasks and edit the description.

Guests can't invite anyone, even to a job they're on. They can't create projects or labels, or change the board's columns or other project settings.

Keep internal work out of the client's project#

Because a guest sees every job in their project, the project is your line. A few habits keep it in the right place:

  1. Run one project per client engagement, and invite the client to that project only.
  2. Give internal work its own project: pitches, studio admin, internal reviews and anything else the client shouldn't read. Never add a guest to it.
  3. Treat every comment in a client project as client-facing. Write it as though the client will read it, because they can, unless it's an internal comment on an approval review, which only your team sees.
  4. Keep private details in the job's Notes tab. Only you can see your notes, which makes them the place for a supplier's quote or a reminder to yourself. They aren't for team discussion: your colleagues can't see them either.
  5. If something lands in the wrong place, you can delete your own comment within five minutes. After that, an administrator can.

Three ways to invite a client#

Pick the route that matches the moment. The guide to inviting your team and clients has every step.

From a job. When you need the client's input on one piece of work, open the job, choose Collaborators, then Invite someone new. Enter their email address, plus a short message if you like, and choose Send invitation. They join the project as a single-project guest, already added to that job. Administrators and team members who can work on the job can do this.

From the project. Open Project settings and go to Members. Invite New lets an administrator choose A guest in this project, which is free, or A team member.

From the workspace. An administrator can open Account settings, then People, and choose Invite People. Under Invite them as, pick Single project guest and tick the one project they should join.

The invite dialog on a job: tom@northwind.co typed into Email addresses, a line saying someone new joins as a free guest who sees that project only, a preview marking Tom as new with an invitation to send and no change to the paid seats, and a Send invitation button.

The client gets an email with a link to your workspace. They can choose Accept with Google where it's offered, or add a name and password. Skybase signs them in and opens their project.

When a client starts to count as a user#

Add a single-project guest to a second project and they become a multi-project guest automatically. Skybase tells your administrators, because that person now counts as a user.

Sometimes that's the right call. A client contact who oversees two brands with you may well want both in one login. Sometimes it isn't: if the second piece of work is small, it can often run as more jobs on the existing board. Either way, it should be a decision you make on purpose, not one you find on the next invoice.

A worked example: how Harbour Studio shares Northwind#

Take a small studio, say Harbour Studio, rebranding a client called Northwind. Harbour and its people are made up: they're the example in Skybase's sample workspace.

Harbour runs two projects. Northwind Rebrand holds the client work, on a board with Brief, In progress, Client review and Done columns. Studio Website is Harbour's own site, and Northwind never sees it.

Tom Becker is Northwind's contact. Leo, a designer, invited Tom from the "Brand guidelines v3" job with Invite someone new, so Tom arrived as a single-project guest already on that job. Tom was later added as a collaborator on "Launch email sequence" too.

That gives Tom exactly the access the three client jobs need:

  • Feedback: Tom can comment on any job on the Northwind board, and the team treats every comment there as one Tom might read.
  • Approvals: when Harbour names Tom as an approver, Tom can review from the link in his email without signing in, and approve or request changes.
  • Changes: on the two jobs Tom is part of, Tom can move the due date and tick off tasks. Everywhere else, Tom can raise a new job but not change anyone else's.

Maya Chen, the studio lead, keeps the print supplier's quote in the Notes tab on "Brand guidelines v3", where nobody else can see it.

A comment thread on the Brand guidelines v3 job with messages from Leo, the client Tom, and Priya, including @mentions, an emoji reaction and a mention picker.

When Northwind's team asks for a darker navy for print, Tom chooses Request changes on the guidelines review and says so in his note. Leo adds Deep Harbour (#0B2545) and sends a new version to the same request, so the request, the change and the reply sit together. Client approvals without the email chain follows that file through to sign-off.

If Northwind later asks Harbour to take on a second project, the studio has a clear choice. Add Tom to it, and Tom becomes a multi-project guest who counts as a user. Or keep the new work on the existing board, and Tom stays free.

A checklist before you invite a client#

  • The client's project holds only work the client may see.
  • Internal work has its own project, with no guests on it.
  • The client joins as a single-project guest, ideally from the job where you first need them.
  • They're a collaborator on every job they need to change.
  • Private details go in the Notes tab, not in comments.
  • You've decided what happens if they need a second project.

The same setup works from either side. A freelancer can run every client this way from one workspace, as project management for freelancers shows. And a company working with several agencies and suppliers can give each one its own project: see managing agencies, freelancers and suppliers.

Written by

Gareth Thurlow

Founder, Skybase

Gareth founded Skybase to give agencies and client teams one place for client work, from the brief to the sign-off.