Calendly Made the Recipient the Growth Channel

The recipient gets a vote

In my February 2021 Calendly case, I described Tope Awotona studying competing scheduling products and focusing on the recipient’s experience. The person paying for a scheduler wants a booked meeting. The person receiving the link wants to choose a time without unnecessary work.

The first ten users in that account were customer-success staff at BrightBytes, introduced through a shared development shop. They used Calendly with parents; some parents then used it for school meetings. The product traveled through a useful interaction.

Design the invitation as a first session

If I were reviewing a product with this kind of loop, I would start on the other side of the link. Open it with no account and no knowledge of the sender’s software. Write down what the recipient has to understand, decide, or provide before the task is done.

Every extra step asks the sender to spend a little of their relationship with the recipient. An unexplained permission, a forced account, or a confusing time zone can make the sender less willing to share the next link. The product team should treat those moments as part of acquisition.

I would keep the recipient’s immediate task ahead of the signup pitch. After somebody completes the task, an invitation to use the product has context: they have just seen what it does. The appropriate placement still needs testing; the historical case does not supply an experiment that settles it.

Learn where the loop repeats

My original account also described Awotona calling people who requested features to understand their use cases. Those conversations helped identify customers getting value and where direct sales might be useful.

A feature request is a good opening for a conversation. It is a poor substitute for a customer segment. I would ask what happened before the request, how often the job occurs, and who else participates. Then compare that answer with the person’s actual repeated use.

For a scheduling product, one person planning a once-a-year event and another booking calls every day can ask for the same feature. They create very different opportunities for repeat exposure.

Measure the whole invitation

I would separate links sent, links opened, tasks completed, recipients who become users, and those new users sending their own successful invitations. Counting the first step alone can reward spam or low-value sharing.

The useful unit is a completed job that creates another reason to use the product. Before adding a referral reward, inspect whether that unit already works.

What I would keep

• Open the shared experience as a first-time recipient.
• Remove steps that do not help the recipient finish the job.
• Use feature requests to investigate repeated use cases.
• Track completed tasks and subsequent use separately from links sent.

Sources and original research

• Original First 1000 case study, February 16, 2021

Adapted from my February 16, 2021 case study. Historical company claims come from that issue; the review questions are editorial guidance. This is not a current product audit or a measured causal growth result.