Invite Flow

The term came out of watching invite features sit there doing nothing. The button existed, a reward was attached, and the month produced forty invites. The usual response was to make the reward bigger. One free month became two, and forty invites became forty-three.

What produced the term was moving the button in that same product and getting 400. The invite action had been living inside the third tab of the settings screen; it moved to the top of the screen for users who had a document open that nobody else had seen. The reward didn't change. Neither did the wording.

That separated two things people had been treating as one. The reason to invite comes from the reward; the path to inviting comes from the order of the screens. A good reason doesn't survive a long path — people stop partway. Invite flow is the name for the path half on its own.

An invite flow runs in five beats — trigger, entry point, choosing recipients, delivery, and the first screen the recipient sees — and people drop out at each one.

1. Trigger. When the invite prompt appears. Show it right after signup and you're asking someone who doesn't yet know whether the product is any good to go recruit for it. Show it when the user hits something they can't do alone and inviting is in their own interest. Wanting to leave a comment on a document nobody else can open is that kind of moment.
2. Entry point. Where the button lives. Whether it sits in a permanently visible bar or three levels into settings moves the result by multiples. People who drop out here aren't unwilling — they never saw the button, which is why this beat is usually the cheapest one to fix.
3. Choosing recipients. The screen for picking who gets invited. Type an address, import a contact list, or copy a link and send it however you like. Typing runs about 20 seconds per person; copying a link takes one action but leaves the product with no idea who received it.
4. Delivery. How the invite actually reaches the other person. Email, text, and pasting into a chat app have different arrival rates, and a steady share of emailed invites land in spam and never get opened.
5. The recipient's first screen. What someone sees after clicking the link. Put a signup form first and a large share close the tab; show the inviter's name next to whatever they came to look at and they stay. Empty-state onboarding, the screen that suggests a first action when there's no data to show, often sits here.

Counting the drop-off at each of the five beats shows you where to work. If 1,000 people see the button, 180 click, 90 finish entering an address and 27 recipients accept, the worst funnel leak is between seeing and clicking. Raising the reward at that point only speaks to the 180 who already clicked, which is why the overall number barely moves.

You tune this hardest in products that only pay off with more than one person in them. When a product has a network effect — each additional user making the product more valuable to everyone else — inviting is already in the user's own interest, so shortening the path alone moves the count.

1. Collaboration tools. Documents, calendars, code repositories: things that don't work until a colleague is inside. Their advantage is that triggers are easy to find. Pressing share is itself the moment a reason to invite appeared, so the prompt rarely has to interrupt anything.
2. Consumer apps. Delivery, payments, resale marketplaces — products one person can use alone. Since the reason to invite isn't inside the product, these usually pair the flow with a double-sided incentive, a reward that goes to both the inviter and the person invited.
3. Marketplaces. Sellers and buyers have to be recruited separately, so the product ends up with two invite flows whose screens read differently. What convinces a seller to bring in another seller is rarely what convinces a buyer.

There are also products where this is the wrong thing to work on. If using the product alone is the normal case, no amount of flow tuning raises the count. A personal budgeting app never grows a reason to bring a friend in. The work there isn't the flow — it's building a reason to use the thing together in the first place, such as letting someone else see a shared record or giving two people a goal they hold jointly.

"The invite flow is five screens. Cut it to three and I'd expect accepted invites to roughly double."

The screen count itself is being named as the cause of the drop-off.

"Before we raise the reward, let's look at the invite flow. Click-through is 18 percent."

The leak is early in the flow, so a bigger reward won't reach it.

"The recipient lands on a signup form, and half of them leave right there."

A reminder that the flow doesn't end when the sender presses send — the recipient's side counts as part of it.

At Pagedeck this work was done by Ravi and Noa together. Ravi pulled the numbers for all five beats, the gap between seeing and clicking dwarfed everything else, and Noa changed the trigger rather than the button. If a document was a day old and still had only one viewer, a line appeared above it suggesting someone to bring in.

Click-through went from 18 to 41 percent. Noa then pulled the signup form off the recipient's first screen and showed the document contents instead, and the acceptance rate rose again. Neither change touched the reward.

The most common mistake is treating invite flow and reward design as one piece of work. Both exist to raise invite counts and the same person usually owns both, so they get filed together. But they stop leaks in different places. A reward moves someone who wasn't planning to invite anyone; a flow keeps someone who already decided from stalling on the way. Blur them and you end up doubling the free trial while click-through sits at 18 percent — the cost doubles and the count doesn't move.

Reading invites sent as the measure of the flow is nearly as common. It's the first number to react when the flow gets shorter, so the assumption is natural. But sent invites only count how many times an address was entered; whether anyone arrived and stayed is a separate question. Let users import a whole contact list and blast fifty invites at once and the count goes up tenfold while the acceptance rate falls. That's why flow changes get read alongside acceptance rate and conversion rate, never on sent count alone.