Add two people before you add twenty#
A rollout that starts with the whole company generates the same question forty times. Begin with two colleagues who do different jobs — one who will use the product daily, one who will only read its output. Whatever confuses them is what your internal note needs to explain.
Send the invitations#
- Open the member or team settings for your project.
- Invite by work email rather than a personal address. Leavers are easier to remove and access reviews are easier to pass.
- Choose the smallest role that lets the person do their job. Roles are easy to raise and awkward to lower.
- Tell them, outside the product, what the invitation is for. An unexplained invite email looks like phishing and gets deleted.
Fill this in: the real role names in docs and one line on what each may do. Mark any role that can delete data or change billing — those are the two people regret handing out.
Check that it arrived#
An invitation can fail quietly in three ordinary ways.
| Symptom | Usual cause | What to do |
|---|---|---|
| Nothing in the inbox after ten minutes | Filtered as spam, or held by the mail gateway | Ask them to search for the sender, and allow-list the domain |
| "This invitation has expired" | Invitations time out | Send a fresh one; do not reuse the old link |
| They land in a different workspace | They already had an account under another address | Invite the address they actually sign in with |
Checkpoint: each person can sign in, see the same project you do, and describe what they are allowed to change.
After the first week#
Review the member list once people have settled. Remove anyone added "just in case", and write down who owns access requests from now on. A named owner prevents the quiet drift where everybody ends up an administrator.
Next steps#
- Getting started — the setup your colleagues will land in.
- What docs can do — what to show them first.
- FAQ — the access questions people ask on day one.