— 10 min read
Building a Virtual Queue Application with Airkit
Queueing applications were everywhere the past few years to help with capacity constraints and social distancing in public areas. From Yelp Waitlist experiences companies like WaitWhile, they allowed customers to sign up using a QR code or a phone number, and the customer would get a text message when their turn in line was up. Pretty simple right?
In this tutorial, you will build a solution for this digital check-in and wait-less use case. The two applications you will build are: Join Waitlist, a customer waitlist where users can add or remove themselves to the digital waitlist and Waitlist Administration, where the admin can notify customers via SMS and check-in the customer.
To build along with this tutorial, you will need a few things to get started:
- Twilio Developer Account
- Two (2) SMS phone numbers from Twilio
- Access to Airkit Studio
Creating an Integration with Twilio
Let’s get started with setting up a Twilio integration. First, you will need to open up a Twilio developer account. Once that is established you will need to request two phone numbers which can send SMS messages. Please refer to the Twilio documentation on how to set up and create SMS messaging.
After the Twilio accounts and numbers have been created you will need to integrate them with Airkit. In order to do that you will go to the Console, click on Integrations, then Connected Accounts, select Twilio and then enter your Twilio account username and password. Once the Connected account is established, the phone numbers for SMS will be available with the Settings section of the application you are building.
Refer to the Airkit Documentation regarding Twilio integration for more in depth instructions on how to connect Twilio Numbers to Airkit.
Building the Airkit Applications
Now that you have the Twilio integration in place for SMS notifications, you will build the customer facing, AirWait (Join Waitlist), and an admin waitlist administration, AirWait Administration (Waitlist Administration), front-end applications and an AirData database which will be shared between the two applications.
Let’s build the first app AirWait (Join Waitlist). You will need to go to the Console and click on the New button and create a new app and name it Waitlist. From there, go to Journey Builder, and add a start from weblink. For this Waitlist app, you will have four components to complete.
You will build a web page for the customer to enter information to join the waitlist, AirData Table to store information about the customer, then set up the notification via SMS, and finally two webpages for the customer to check their position and notify the customer has left the waitlist.
The initial “Join Waitlist” page is a simple webpage that includes one title text control, two input text fields and text controls, and button control. You will create a webpage similar to the example shown below or follow along with the YouTube video:
The Join Waitlist button has a series of actions associated with it. You will add the following actions for when the button is clicked see the action list below.
The initial action “Insert Into Waitlist” is a Data Flow. You will need to create a new Data Flow in Connections module and an associated AirData Table called “waitlist”.
In order to create an AirData table you will need to go to the AirData module, create a new App Object and add the following variables to the “Waitist” App Object. See the screenshot below:
While you are in the AirData module, this gives you the opportunity to create a Custom Type App Object called “spot”, which you will use later in the “Insert Into Waitlist” Data Flow. See the screenshot below:.
Now that you have the AirData tables in place, next you can build the “Insert Into Waitlist” Data Flow. In this Data Flow, you will insert customer information into the “Waitlist” AirData App Object and figure out where the customer is in the line. The next steps will show you how to build this DataFlow or you can follow along with the YouTube Video.
The “Insert Into Waitlist” Data Flow will take in inputs of customer name and a phone number.
You will create an AirData Request to the App Object of “Waitlist” and perform an INSERT with the following keys and variables:
- name: <Customer Name>
- phone: <Customer’s Phone Number>
- sign_up_time: <current time and date>
- accepted: <true/false>
Next, you will create another AirData Request which will Query the list of check-in. See the screenshot below as an example:
Finally, you will create two Transform Data Operations which will find the user’s place in line. See the following two screenshots for the required AirScript:
The second Airscript uses the Custom Type Object “spot’ to return a value to the session variable “session.waitlist_spot”.
You have completed the first Data Flow which inserts customer information into the AirData Table and returns the customer’s spot in the waitlist line.
Now you have to send an SMS notification to the customer. You can proceed with the next set of steps or can follow along with the YouTube Video.
In order to create an SMS notification, go to the Notifications Module and add a new Notification called SMS notification. The SMS notification will contain a Text Message and a Link. See below screenshot to see an example of suggested text and Airscript which you could use to let the customer know via SMS what position in the waitlist they are.
Now you can insert the customer data and send a SMS notification to the user. You will need to create two web pages: “Waiting” (position in queue) and “Removed from waitlist”. You can proceed with the next set of steps or can follow along with the YouTube Video.
Create a webpage similar to the screenshot shown:
The “Remove from waitlist” button has the following action which it performs:
- Remove the user from the AirData Table, via Data Flow
- Sends a SMS message to the user that they are removed
- Open new webpage notifying user they have been removed from the waitlist
You will create a new Data Flow called “Remove from waitlist”. It will have an input of the database id and will have a single Data Operation of an AirData request which deletes the AirData record. See the screenshots below:
You will create a final webpage for the AirWait (Join Waitlist) application. If the user has chosen to remove themselves from the waitlist they will see a webpage like the example shown below:
Congrats! You have completed the first application for this AirWait (Join Waitlist) application! Next you will create the AirWait Administration application.
The AirWait Administration (Waitlist Administration) application will allow the store or restaurant to notify the customer via SMS that they are next in line and check-in the customer.
You will need to go to the Console and click on the New button and create a new app named: “Admin Waitlist”. From there go to Journey Builder, add a start from weblink.
The single webpage for the AirWait Administration application will contain several text controls, a container list control, and two buttons. You can continue with the next set of steps or follow along with the YouTube Video.
You will need to create an administration web page. Check out the screenshots below to see what the page looks like and add the necessary controls.
In order to get the list of customers in the queue, you will need to access the AirData table “waitlist” from the Join Waitlist Application. How can you do that? AirData has the ability to reference the same App Object Database across multiple apps. Once you have imported the App Object, you can now create two DataFlows to query and query then update the AirData App Object “waitlist”. The customer waitlist information from these DataFlows you will be creating will be the basis of the information which populates the Container list.
The DataFlow “Query AirData” is an AirData Request that will QUERY the App Object: “waitlist” for all customers which have not checked in yet. See the screenshot below to see the configuration settings:
The second DataFlow “Update and Query” will update the App Object “waitlist” via a PUT method then run the DataFlow “Query AirData” to get the last list of customers in the waitlist queue.
The “Update and Query” Data Flow will take an input of id, which is the __id identifier in the “waitlist” App Object.
You can create a PUT AirData request like the following which will update the record in the AirData table “waitlist” with accepted = TRUE. See the screenshot below:
This DataFlow will be called by the Check-in Button on the Administration Page.
Then you will add a data operation where you will run the “Query AirData” DataFlow to refresh the list of customers still in the queue.
The output of the Query AirData will be stored in the session variable: session.list_of_waiters.
Now that you have created the DataFlows to Query and Query and Update the waitlist, you will need to notify the customer to come and check-in. This notification is just a SMS notification similar to the one created before in the Join WaitList application.
You will need to create a “Notify to arrive” button in the container list which sends an SMS notification. The Actions will be the following:
You will create an SMS Notification within the Notification Module, add new SMS notifications, and send the text in the SMS similar to the screenshot.
At this point you have completed building the two applications. Test your applications out to see if they work as expected. If they work, congratulations you have created a Waitlist Queue and Check-in Application!
Hopefully the walkthrough of these two Waitlist applications have been a helpful guide on how to create a waitlist queue and check-in application. We have learned how to integrate Twilio for SMS notifications, share and access data from a common AirData table between apps, and common Airscript uses.
This use case can be built upon for additional use cases and other notification methods in Airkit. You could add email or voice notification using the Voice Bot or Notifications modules. You could even add in a marketing or loyalty sign up application within the journey to obtain more information about your patrons. The options are endless on additional use cases. Try adding some new use cases and let us know!