Twilio and “Friend-to-Friend Invitations”

Many apps nowadays send out invite messages to a user’s contacts in order to get that user’s friends on the platform — I mean, hey, if your user thinks your product is cool, why not encourage them to tell their friends about it? Apps that do friend-to-friend invites typically access the end user’s contact list to find phone numbers of  their friends and partially or fully automate the process of sending out the invitations to those friends as text messages. In a lot of cases (and certainly if you’re using a platform like Twilio to send these), the friend will receive the text messages from a phone number provided by the app, rather than directly from the end user’s phone number. As a result, these messages may be perceived as spam by the user’s friends. Uh oh.
Let’s dive into how you avoid this conundrum, and send friend-to-friend-invites the right way. We’ll also give you our pro-tips.
Friends seeing these messages as spam leads to a sticky situation — spam is bad and you, as the app developer, do not want to be viewed as a spammer. Nor do you want to make your original happy end user look bad in front of all their friends. Aside from the poor reception you might get from your end users and their friends, your friend-to-friend invitations might get a poor reception under the law, because, if done wrong, they arguably violate the Telephone Consumer Protection Act (TCPA). The purpose of the TCPA is to stop consumers from receiving unwanted calls and text messages.
So, it requires you to have the consent from the friends before you send them a message. Depending on whether the message is viewed as coming from your  user or your app, the friends may not have unambiguously consented to receiving  the messages. And while Twilio supports innovators in their endeavors, at the same time we need to protect consumers from spam — because, remember, SPAM IS BAD. Oh … almost forgot to mention that penalties under the TCPA can run as high as $1,500 per text message! Doing that math, that calculation gets really scary really fast.
First, the FCC has provided some partial guidance on this matter. In a July 2015 Declaratory Ruling and Order, the FCC took up this issue, saying, in essence, that the issue of whether a friend-to-friend invitation violates the TCPA depends on “1) who took the steps necessary to physically place the call [you or your end user]; and 2) whether [you, the app developer are] so involved in placing the call as to be deemed to have initiated it, considering the goals and purposes of the TCPA”  (See FCC Order, ¶ 30.)
The FCC then considered the friend-to-friend invite flows of a couple of different app providers.  One app provider set forth evidence that when a user decided to invite friends to download the app, the user had to first tap a button that read “invite your friends,” then choose whether to invite all friends or select friends individually, and finally actually send the invitation by hitting another button. The FCC expressed concern that the app provider determined the language of the actual text message that was sent to the friend(s), but determined, that taken as a whole, it was the user of the app, not the app provider, that initiated the invitation.  And, so, the app provider did not violate the TCPA.  (See FCC Order, ¶¶ 36-37.)
In contrast, the FCC considered another app provider’s invitation flow that allegedly automatically sent invitational text messages to all of the user’s contacts automatically when the user signed up for the service without requiring any further affirmative steps by the user to send the invites.  In that case, the FCC said it was the app provider, not the user, that initiated the messages for purposes of liability under the TCPA.  (See FCC Order, ¶ 35..)
Alright, now that we’ve got that covered, we can get to the meat and potatoes. Here are some best practices we recommend for our customers based on the FCC’s guidance (they are the rulemakers, after all) and our own experience seeing how other customers have successfully and unsuccessfully done friend-to-friend invitations.

Twilio’s Recommended Best Practices

Based on FCC guidance and our experience, we recommend the following with respect to friend-to-friend invitations:


  1. You, the application provider, must obtain explicit affirmative and knowing consent from your end user to access your end user’s contact list. This consent must be recorded. (Trust us, you’ll want this if you ever have to defend yourself.)

  3. Your app must obtain explicit affirmative and knowing consent from the end user to send invitation text messages to their contacts on their behalf. This consent must be recorded.

  5. Your end user must knowingly, affirmatively, and explicitly select each contact or friend who will receive a text invitation. In other words, avoid a “Select All” button to send out messages.  (Think about all the people who might be in the contacts list on your end user’s phone… their doctor, their boss, their Great Aunt Tillie. Do you think your end user really wants them all to get an invitation from them to sign up for your app? That could lead to some embarrassing situations.)

  7. The end user must have the opportunity to view and modify the content of the invitation, except for the “sent by” language set forth in the next requirement, so that the end user can preview what their invitees will see.  Again, let’s make sure your end user doesn’t end up embarrassed by something here. Our support team assures us that embarrassing your end users is generally considered a bad thing in the industry.

  9. Each invitation must be sent with language that indicates the message is being sent by your app on behalf of the end user and the end user’s phone number. For example, “Sent by XYZ App on behalf of John Smith 555.555.1234.” The end user must be clearly informed that this “sent by” language will be included in each message.

  11. The call to action to initiate the actual sending of the message should be separate from other actions in the process of creating the message, and it should be clear to the end user that their action is initiating the sending of the text message. You don’t want your end users to be staring at their phones thinking to themselves “Doh! Did I just send that message?! Is there an unsend button?!”

  13. The end user should be permitted to cancel or close out of the invitation process at any step up until the communication is actually sent.  Not letting your end user change their mind during the invitation process is, well, just mean. (Some might say evil.)

  15. Your app must not send any additional messages to the end user’s contacts or friends unless and until that contact or friend knowingly and explicitly agrees to receive additional messages from your app.

  17. You should closely monitor the percentage of invitees who respond with STOP or otherwise indicate that the invitation is unwanted (e.g., “Who is this?”, “Why are you contacting me?”). You should take any additional steps as necessary to ensure that this percentage remains low because each such response raises the risk that invitees will contact their carriers to complain (or their lawyers to sue). There is no industry or legal “acceptable percentage”; therefore, we cannot offer explicit guidance on an appropriate percentage. However, solely as a non-binding, rule of thumb, Twilio recommends maintaining this percentage well below 0.5%. Remember that $1,500 penalty under the TCPA per text message?


And… here comes the disclaimer. Please note that these best practices do not constitute legal advice. Moreover, following these best practices will not necessarily ensure compliance with applicable law, including but not limited to the TCPA and similar consumer protection and privacy laws, and/or with Twilio’s Acceptable Use Policy. Accordingly, Twilio expressly reserves the right to limit or suspend service if (1) Twilio receives complaints from end users and/or carriers regarding use cases involving friend-to-friend invitations or (2) the recipients of these messages respond with a large quantity of stop messages or the equivalent, thereby indicating that these messages are unwanted.


Thanks for reading!

This post was authored by Mike Huskins and Victoria Hu, Product Operations, and Sheila Jambekar