One of the more abstract concepts you'll handle when building your business is what the workflow will look like.
At its core, setting up a standardized workflow is about enabling your service providers (agents, hosts, customer service reps, administrators, and the rest of the gang) to better serve your customers.
To illustrate a very real-world example, today we'll build a PHP and Laravel webapp for finding and booking vacation properties — tentatively called Airtng.
Here's how it'll work:
- A host creates a vacation property listing
- A guest requests a reservation for a property
- The host receives an SMS notifying them of the reservation request. The host can either Accept or Reject the reservation
- The guest is notified whether a request was rejected or accepted
We'll be using the Twilio REST API to send our users messages at important junctures. Here's a bit more on our API:
Let's boldly go to the next step! Hit the button below to begin.
Our workflow will require allowing users to create accounts and log-in in order to attempt to reserve properties.
User will need to have a
phone_number which will be required to send SMS notifications later.
Next up, we will create a table that represents a Vacation Rental property.
We're going to need a way to create the property listings for Airtng to be a success.
VacationProperty model belongs to a
User who created it (we'll call this user the host moving forward) and contains only two properties: a
description and an
It has two associations: it has many reservations and many users through those reservations.
Next at the plate: how we will model a reservation.
Reservation model is at the center of the workflow for this application. It is responsible for keeping track of:
guestwho performed the reservation
vacation_propertythe guest is requesting (and associated host)
statusof the reservation:
Since the reservation can only have one guest in this example, we simplified the model by assigning
phone_number directly to the model (but you'll want to move it out).
Our tables are ready, now let's see how we would create a reservation.
The reservation creation form holds only a single field: the message that will be sent to the host user when reserving one of her properties.
The rest of the information necessary to create a reservation is taken from the user that is logged into the system and the relationship between a property and its owner.
A reservation is created with a default status
pending, so when the host replies with a
reject response the system knows which reservation to update.
Let's take a look at how the SMS notification is sent to the host when the reservation is created.
When a reservation is created for a property, we want to notify the owner of that property that someone has requested a reservation.
Now we just have to wait for the host to send an SMS response to 'accept' or 'reject', notify the guest, and update the reservation.
Let's see how we would handle incoming messages from Twilio and accept or reject reservations.
We're zoomed in for a closer look at the
acceptReject method. This method handles our incoming Twilio request and does three things:
- Checks for a pending reservation from the incoming user
- Updates the status of the reservation
- Responds to the host and sends a notification to the guest
In order to route an SMS messages to and from the host, we need to setup Twilio webhooks. The next pane will show you the way.
This method handles the Twilio request triggered by the host's SMS and does three things:
- Checks for a pending reservation from a user
- Updates the status of the reservation
- Responds to the host and sends a notification to the user
In the Twilio console, you should change the 'A Message Comes In' webhook to call your application's endpoint in the route
One way to expose your machine to the world during development is to use ngrok. Your URL for the SMS web hook on your phone number should look something like this:
An incoming request from Twilio comes with some helpful parameters. These include the
From phone number and the message
We'll use the
From parameter to look up the host and check if he or she has any pending reservations. If she does, we'll use the message body to check for the message 'accepted' or 'rejected'. Finally, we update the reservation status and send an SMS to the guest telling them the host accepted or rejected their reservation request.
In our response to Twilio, we'll use Twilio's TwiML to command Twilio to send an SMS notification message to the host.
In the last step, we'll respond to Twilio's request with some TwiML instructing it to send an SMS to both the host and guest.
After updating the reservation status, we must notify the host that he or she has successfully confirmed or rejected the reservation. If the host has no pending reservation, we'll instead return an error message.
If we're modifying a reservation, we'll also send a message to the user who requested the rental delivering the happy or sad news.
We use the Message verb from TwiML to instruct Twilio to send two SMS messages.
Congratulations! We've just automated a rental workflow with Twilio's Programmable SMS, and now you're ready to add it to your own application.
Next, let's take a look at some other easy to add features you might like to add.
PHP + Twilio? Excellent choice! Here are a couple other tutorials for you to try:
Put a button on your web page that connects visitors to live support or salespeople via telephone.
Instantly collect structured data from your users with a survey conducted over a voice call or SMS text messages.
Thanks for checking this tutorial out! If you have any feedback to share with us, please hit us up on Twitter and let us know what you're building!