Sharing work with clients: what they should see

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 or reject what you send for sign-off.
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.

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. The pricing page 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 or reject files that someone else has posted for approval
• 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 change the status or 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 change the board's columns, statuses 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.
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 name and 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 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: Tom can approve or reject any file Harbour posts for approval in the project.
• 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.

When Northwind's team asks for a darker navy for print, Tom posts it as a comment on the guidelines job. Leo adds Deep Harbour (#0B2545) and answers in the same thread, so the request, the change and the reply sit together. The approvals article 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.

If you run client work across several accounts, the agencies page shows how studios put these pieces together.