Keep Your Christmas Party Organized with Some Twilio Magic

Keep Your Christmas Party Organized with Some Twilio Magic

If you have ever tried to keep over a hundred people organized for a Christmas party, you will already know how much of a nightmare it can be!

Tarik Zawia and Adam King from Twilio’s London office decided to add a little Twilio Magic to make this year's event a success.

Defining Christmas Party Organizational Challenges

Tarik Zawia - Account Executive - EMEA

Working for Twilio, I knew that communications could be used to help keep things on track. This winter, I decided to have some fun with Twilio to make our US Alumni Club annual London pub-crawl (co-hosted by Cornell, GW, and UChicago) a little more hi-tech than in previous years.

So, as with most (highly important and serious) engineering projects, we started with a problem to solve...

Problem Statement: Keeping over a hundred people in the right place at the right time for an organized pub crawl can be difficult.

Pain Points:

• Late-comers not knowing where the party has moved onto.
• People not knowing how long until the party moves on – and not being sure if they have time to finish their drinks and conversations before moving on.
• People get split up during movement between venues, so we need a way for people to be sent location information.

Here at Twilio, we often speak with customers who know that they need to add real-time communications to solve their problem – and they know that Twilio is the market leader when it comes to making that happen. When customers need some help in aligning their vision to the Twilio stack, that is where the Twilio Solutions Engineering team comes into play.

And that’s exactly what happened here. I reached out to Adam King from the Twilio Solutions Engineering team here in London to talk through the problem.

After a short technical discovery, Adam identified a few crucial bits of information that guided us towards the Twilio products we could use to help solve this problem.

1. Tarik estimated that there would be approximately 100 people attending.
2. Tarik was unclear on exact timings for the event, so scheduled sending would not be appropriate.
3. Tarik wanted to be able to send ad-hoc messages on the night (trivia, shout-outs, lost and founds, etc.).
4. Tarik did not want people to be able to respond to the broadcast messages.

Adam King - Senior Solutions Engineer - EMEA

Given Tarik’s requirements, and the desire to get something up and running quickly, Twilio Studio seemed like the right place to start to handle user opt-in.

Sync would be used to store the user list, Functions to get data in and out of Sync, a Messaging Service to handle sending messages out reliably over the Twilio Super Network, and finally, the Notify service to reduce the complexity of the code needed to send a hundred SMS in a timely fashion.

One of the Twilio Values is “Write it Down.” So before jumping into writing the Proof-of-Concept solution Tarik and I decided to draw out the use cases.

Communications Use Cases

Use Case 1: Attendee sign-up via SMS

Steps:

1. Attendee messages a ‘Sign up’ phone number to consent to us messaging them and sign them up to receive updates throughout the event.
2. This phone number is configured with a Studio flow to handle the incoming message
3. The Studio flow runs a Function passing in the phone number of the new participant.
4. The Function adds the new phone number to the Sync object storing the list of event participants.
5. The Function returns a success (hopefully), and control is passed back to the Studio Flow.  
6. A message is sent via the Programmable Messaging Service.
7. The attendee gets a message from the Alphanumeric Sender.

Use Case 2: Moderator broadcast message

Steps:

1. The organizer wishes to send a message to everybody in the group. They text their message to a Twilio number.
2. That phone number is configured to hand-off the incoming message to a Studio flow.
3. The Studio Flow fires a Function which is responsible for retrieval of phone numbers from Sync.
4. The SyncMap is queried for all of the phone numbers of people who subscribed.
5. Notify will be used to simplify the bulk sending based on the numbers returned from Sync.
6. Notify uses the underlying Programmable Messaging Service to send the messages out with an Alphanumeric Sender.

Building the prototype

The core of the solution was going to be the Studio flow(s). We decided that the same Studio flow could handle both use-cases, splitting the functionality based on the detection of the incoming number as a moderator's. 

Once a message triggers the Studio flow, a "Split based on..." widget is used to determine if the person who messaged in is a moderator or not. In our case, we only had one moderator, so the transitions for this block look something like this (number masked):

If the incoming number does not match one in the comma-separated field, we know they aren't a moderator. In that case, we will proceed with the Use Case 1 flow. 

The next part of this side of the flow, therefore, is to call a Twilio Function to add the incoming phone number to our Sync data store. 

You will notice that we are passing in {{trigger.message.From}} as a function parameter. Later, we'll be able to use this variable in our Function code. 

This function code assumes that a Sync service and SyncMap have already been created – then all we need to do is add the new key to it. For the simplicity of this proof of concept, we are using the event.Number (which we passed in above) as the Key. The data object is empty right now, but we could add additional meta-data about the user here if we wanted.

If we cannot add the user to the map, this usually means that they have already been added. In this case, we will return an error code so that we can handle the issue back in the Studio flow. 

Here you can see the simple messages that we send back to the attendee to let them know if they have been onboarded successfully or if onboarding failed. 

And, that's it for Use Case 1. Let's jump back to Use Case 2, where our moderator (Tarik) can send out a message to all of the members of his Sync Map in one go! 

A couple of status messages get passed back to Tarik during a broadcast. This lets him know things are up and running, and the messages are being sent out. 

The fun part is in the associated Function (again, the real URL is redacted here)

This perhaps looks more complicated than it is.

Essentially, we go to the Sync Map and grab every item from it (max 100 items for this demo) and put them into a list. We grab our Notify service, which is, in turn, connected to a Messaging Service and map the entire list into bindings as needed by Notify (lines 12-14). 

Finally, we create the notification you see on line 15, and handle either success or error response by logging out the resulting Sid or error code. 

Summary

Tarik is now able to message his Twilio number, and have the message forwarded to anyone who opted into notifications via SMS.

After some brief testing, Tarik decided to put the flow to the test on the night... I'm told it went well!

Are you considering adding real-time communications to your projects for next year? If so Twilio can help. Talk to the experts or sign up for a free trial to see how Twilio can fuel your communications in 2020 and beyond.

Adam King is a Senior Solutions Engineer for Twilio, based in our London office. He is currently working with EMEA customers on best practices for using Twilio APIs, whilst also trying to plan his wedding! He can be reached at aking [at] twilio.com

Tarik Zawia is a Commercial Account Executive for Twilio, originally from Boston MA, he is currently working in London helping UK businesses tap into the Twilio magic. He can be reached at tzawia [at] twilio.com