How Should You Onboard an Invited Teammate?

How should you onboard someone who was invited rather than someone who signed up?

Differently, because they have almost none of the context the first user had. The person who signed up chose your product, read the pricing and understands the problem. The invited teammate got an email from a colleague and does not know what your product is or why they are here.

Almost every product we look at treats these two people identically. The invited user drops into an empty dashboard with a tour written for someone who chose to be there.

That is where team expansion quietly stalls, and it is one of the cheapest things in a product to fix.

Why is the second user's experience always worse?

Because the first user's flow gets all the attention. Signup is measured, optimised and argued over, since it is where the funnel is visible. The invite flow gets built in a sprint, tested by the team on their own accounts, and never looked at again.

Testing it honestly is also awkward. Everyone on your team already has an account, already knows the product, and cannot see the flow through the eyes of someone who does not. So it passes review while being genuinely confusing.

The result is a gap between the person who bought and everyone who has to use it. For a product sold per seat, that gap is the growth constraint.

What does the invited person actually need to know?

Four things, and all four in the first ten seconds. Who invited them, by name. What this product is, in one plain line. What they are expected to do here, specifically. And whether they are allowed to ignore all of it for now and come back another day.

That last one matters more than teams like. Plenty of invited people are being added because someone thought they should have access, not because they have a job to do. Telling them plainly that they can look around now and come back later is more respectful than a forced tour.

The inviter's name is the single highest value element on the page. It converts a message from an unfamiliar product into a message from a colleague, and it is usually the one piece of context products fail to carry through from the invite email.

What does the accessibility standard say about the invite link?

It constrains how you can ask them to authenticate. WCAG 2.2 added success criterion 3.3.8, Accessible Authentication at Minimum, at Level AA. It says a cognitive function test "such as remembering a password or solving a puzzle" must not be required at any authentication step unless that step offers one of four alternatives.

Those alternatives are another method that does not rely on a cognitive test, a mechanism to assist the user, object recognition, or identifying content the user provided. Most invite flows satisfy this by simply not getting in the way.

The note under that criterion is the practical instruction. It says qualifying mechanisms include "support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing." So an invite code field that blocks paste is not a minor annoyance. It is a Level AA accessibility failure.

That single detail is worth checking today. Splitting a code into six separate boxes, or stripping pasted whitespace so the paste silently fails, are both common and both break this.

Should an invite link expire?

Yes, but generously, and with a graceful recovery. An invite that never expires is a standing credential sitting in an inbox, which is a real security problem when people leave companies. An invite that expires in an hour is a support ticket.

A week or two is a reasonable default for most B2B products. The important part is not the duration, it is what happens afterwards. An expired link should land on a page that explains what happened and offers a one click request for a new one, sent to the same address.

What it must not do is show a generic error or a login screen. A person who clicks a colleague's invite and sees invalid token has no way to recover and will not email you about it. They will just not join.

What should the invited person see first?

The thing they were invited to, not your dashboard. If someone is added to a specific project, document or workspace, land them on it. The empty state of your main product is meaningless to a person who has never seen the full one.

This is the biggest single improvement available in most invite flows. It turns a confusing arrival into an obvious one, because the first screen answers why am I here by showing them.

Carry the reason through from the invite. If the inviter wrote a note, show it. If they were given a specific role, say what that role can do in plain words rather than a permission name. Our notes on designing onboarding flows cover the first user side of this.

How do you handle someone invited to the wrong place?

Make it easy to say so, and make it easy to leave. People get invited to the wrong workspace constantly, usually because of a mistyped email or a colleague with a similar name. The current default is that they either silently join something they should not see, or they give up.

Offer a decline action on the invite page itself, and tell the inviter it was declined. That closes the loop without anyone needing to send an awkward message.

Also handle the case where they are already in three of your workspaces. An invited person who belongs to several accounts needs to understand which one they just joined and how to move between them. We wrote about that in our notes on workspace switching.

What about an invite to an email that already has an account?

Join them, do not make them sign up again. This is the most common broken path we find. The product recognises the email, decides the flow is for new users, and pushes an existing customer through registration where they hit an account already exists error.

The right behaviour is to detect the existing account, authenticate them normally, and then add the new membership. The invite becomes an accept step rather than a signup step, and it should take one click.

If they are signed in already in another tab, use it. Asking a logged in user to log in again in order to accept an invite is a small thing that reads as a product that does not know who you are.

Does this change with passkeys?

It gets better, and it is worth designing for now. The WebAuthn specification lists passkey as a synonym for a client side discoverable credential, and notes in its consumer use case that a relying party can use the authenticator built into a user's devices "to provide phishing-resistant sign in."

The spec also states that once registered, a public key credential "can only be accessed by origins belonging to that Relying Party," which is what makes this resistant to a fake invite email pointing at a lookalike domain.

For an invited teammate that removes the worst part of the flow, which is inventing and remembering a password for a product they did not choose. It also sits neatly with the accessibility criterion above, since it removes the cognitive test entirely. Our notes on passkeys and web authentication cover the implementation side.

What would we build first?

Land them on the thing they were invited to, show who invited them by name, and allow paste in every single field. Those three changes cost very little to build and between them fix most of what is wrong with a typical invite flow, before you touch anything harder.

Then test it properly, which means with a real email address on a device that has never logged into your product. Everyone on your team is the wrong person to test this, and that is exactly why it stays broken.

If you are looking at expansion within existing accounts and suspect the invite flow is the constraint, we are happy to walk through it with you. You can find us at phoenix.studio.