Guests Should Not Take a Seat
Most tools solve client access by shrinking the internal member role until it fits a stranger. That's the wrong shape, and it costs you either money or trust.
Here is the orthodox move, and it is almost always the first thing a product team ships: take the internal member role, strip out a few permissions, and call the result a 'client' or 'guest' role. Same list view. Same board. Same notification settings, just fewer buttons. Ship it, write a blog post about how flexible your permissions are, move on.
It feels generous. It is cheap to build, because you're reusing the member data model and just hiding UI elements behind a flag. And it looks, on a feature comparison page, exactly as capable as anything a competitor offers. The cost shows up later, and it shows up on the client's side of the relationship, not yours.
A smaller member role is still a member role
The problem with 'member, but fewer checkboxes' is that it inherits everything about membership that was never meant for a stranger. A member role assumes the person belongs in your team directory. It assumes they should be discoverable when someone searches for who's on the account. It assumes, by default, that visibility leans open rather than closed, because that's the right default for people you hired and trust with the whole operation.
None of those assumptions hold for a client reviewing a single deliverable, a contractor dropping in for one task, or a vendor who needs to see one invoice thread and nothing else. Give them the shrunk-down member role and you've handed them a smaller window into a house they were never meant to walk through. Most of the time nothing bad happens. Occasionally someone's client sees a teammate's name attached to an unrelated project, or sees that another agency account exists at all, and you spend an afternoon explaining that it was an accident of the permission model, not a decision anyone made on purpose.
Who the member-role shortcut is actually right for
It's worth naming who this shortcut genuinely serves, because the refusal isn't free either. If your 'external' people are really just contractors who'll be embedded for six months, who should know the team, sit in standups, and get assigned real work — give them a real seat. Paying for a seat is correct there. The shortcut breaks down specifically at the edge: the client who logs in twice a month, the vendor who needs one answer, the reviewer who approves one thing and disappears. Those are not under-provisioned members. They are a different category of person, and treating them as a cheap member is solving the wrong problem well.
The two things external access actually has to answer
External collaboration isn't internal collaboration with the volume turned down. It has to answer two questions a member role was never designed to answer: what exactly can this person see, and how do they ask for something without you having to hand them a whole workspace.
On the first question, visibility for an outsider should be opt-in per person, not a role template you apply and forget. A guest should see the projects or tasks you specifically granted — nothing more, not even the fact that other projects exist. Whether they can read or write comments, use the AI teammate, or see who's on your team should each be a separate decision, off until you turn it on, because a client you're meeting for the first time doesn't need the same defaults as a long-running vendor you trust.
On the second question: a guest's main verb shouldn't be 'edit.' It should be 'ask.' Clients don't want to learn your task board — they want to get a decision, a file, or an approval out of you, and they want it to land somewhere specific instead of evaporating into an email thread or a Slack DM nobody can find three weeks later. That's a different interaction shape than a task, which assumes someone owns the work and will do it. A request assumes the opposite: the person raising it owns the asking, not the doing.
What this costs you, named honestly
The honest cost of refusing the shrunk-member shortcut is that you have to build and maintain two shapes instead of one. A member permission matrix is one axis: more or less access to the same kind of thing. A real guest model needs per-person grants, defaults that lean closed, and a parallel path for the thing guests actually want to do, which is ask rather than edit. That's more surface area, not less. It's also the reason most tools don't bother and just ship the smaller checkbox list instead — it's faster to build and it demos fine.
In Team and Tricks, a guest never appears in the Members list, is never assigned work, and doesn't take a paid seat — because they're not a smaller teammate, they're a different relationship. Free includes 25 guests; Pro includes unlimited guests. What they can see is granted project by project or task by task. Reading or writing comments, using TAI, and seeing the team roster are each off until an admin turns them on for that specific guest. And when a guest needs something, they raise a request, which routes automatically to the organisation's owners, admins, and managers — they don't have to guess who to bother, and you don't have to hand them a form to figure out your org chart first.
If you run an agency, this distinction isn't academic. It's the difference between a client who trusts the portal enough to use it and one who emails you anyway because the portal felt like it was built for your team and merely tolerates them. One costs you a seat line item you didn't need. The other costs you the client's confidence that anything in the system is actually meant for them.
