Learn to implement appointment reminders in your web app with Twilio. Appointment reminders allow you to automate the process of reaching out to your customers in advance of an upcoming appointment.Start Tutorial
Ready to implement appointment reminders in your application? Here's how it works at a high level:
Here are the technologies we'll use to get this done:
To implement appointment reminders, we will be working through a series of user stories that describe how to fully implement appointment reminders in a web application. We'll walk through the code required to satisfy each story, and explore what we needed to add at each step.
Let's get started! Click the right arrow to move on to the next step of the tutorial.
In this tutorial, we will be working through a series of user stories that describe how to fully implement account verification in a web application. Our team implemented this example application in about 12 story points (roughly equivalent to 12 working hours).
Let's get started with our first user story around creating a new user account.
As a user, I want to create an appointment with a name, guest phone numbers, and a time in the future.
In order to build an automated appointment reminder app, we probably should start with an appointment. This story requires that we create a bit of UI and a model object to create and save a new
Appointment in our system. At a high level, here's what we will need to add:
Appointmentmodel object to store information about the user
Let's start by looking at the model, where we decide what information we want to store with the appointment.
Usually at this point in the tutorial we would build our model, view and controller from scratch (see account verification as an example). But since the appointment model is so straight-forward, and we really just want the basic CRUD scaffolding, we're going to use the Rails generator for once.
A Note about Tools
In this app we're using Rails 4, but it will be very similar for 3 and below. We will also be using the twilio-ruby helper library. Lastly we use bootstrap to simplify design, and in this case there is a gem that will generate bootstrap-themed views called twitter-bootstrap-rails. Please check out these tools when you have a chance, now let's move on to generating our scaffolding.
Generate a Model, View and Controller
Rails generate is a command-line tool that generates rails components like models, views, tests and more. For our purposes we are going to use the big kahuna generator,
scaffold to generate everything at once.
Here's how we did it. From inside our rails app, we ran:
$ bin/rails generate scaffold Appointment name:string phone_number:string time:datetime
This tells our generator to create the 'scaffolding' for a resource called Appointment, which has the properties name, phone_number and time. Now let's go to the model that was generated and add some stuff to it.
The appointment model is pretty simple out of the box, but since humans will be interacting with it let's make sure we add some data validation.
Validations are important since we want to make sure only accurate data is being saved into our database. In this case, we only want to validate that all of our required fields are present. We can do this by creating a
validates statement with
It is likely that our Appointment Model would be created by an admin person at the site of the appointment. Well it would be great if we could give our admin user some feedback when they create the appointment. Luckily in Rails if we add validations to our models we get error reporting for free with the session's
One note: in order to run this demo you would need to run
rake db:migrate which would run the migrations in our db/migrate folder. For this tutorial we're gonna focus on the core concepts but if you want to learn more about migrations you can read the Rails guide on the subject.
Now we're ready to move up to the controller level of the application, starting with the HTTP request routes we'll need.
In a Rails application, Resource Routing automatically maps a resource's CRUD capabilities to its controller. Since our
Appointment is an ActiveRecord resource, we can simply tell Rails that we want to use these routes, which will save us some lines of code.
This means that in this one line of code we automatically have an
appointment/new route which will automatically render our
appointment/new.html.erb file. Let's take a look at this form up close.
When we create a new appointment, we need a guest name, a phone number and a time. By using the rails
form_for tag we can bind the form to the model object. This will generate the necessary html markup that will create a new Appointment on submit.
Let's point out one specific helper tag that Rails gives us for model-bound forms.
One potential time-suck is figuring out how to handle the date and time of the appointment. In reality this is two separate user inputs, one for the day and one for the time of the appointment. We need a way to combine these two separate inputs into one paramater on the server-side. Again Rails handles this by giving us the
select_time tags which the server automatically gathers into one paramater that maps to the
Let's jump back over to the controller to see what happens when we create this appointment.
One of the other handy controllers created by our
Appointment resource route was
appointment/create which handles the POST from our form.
In our controller we take the input from our form and create a new
Appointment model. If the appointment is saved to the database successfully, we redirect to the appointment details view which will show the creator the new appointment and allow them to edit or delete it.
Next we're going to take a look at the generated controllers for edit and delete.
As a user, I want to view a list of all future appointments, and be able to delete those appointments.
If you're an organization that handles a lot of appointments, you probably want to be able to view and manage them in a single interface. That's what we'll tackle in this user story. We'll create a UI to:
Let's start by looking at the controller.
At the controller level, all we'll do is get a list of all the appointments in the database and rendering them with a view. We should also add a prompt if there aren't any appointments, since this demo relies on there being at least one appointment in the future.
Let's go back to the template to see our list of appointments.
The index view lists all of the appointments which are automatically ordered by
date_created. The only thing we need to add to fulfill our user story is a delete button. We'll add the edit button just for kicks.
You may notice that instead of hard-coding the urls for Edit and Delete we are using a Rails URL helper. If you view the rendered markup you will see these paths:
/appointments/(some ID)/editfor edit
/appointments/(some ID)for delete, with an HTTP DELETE method appended to the query
These URL helpers can take either an appointment object, or an ID.
There are some other helpers in this code that Rails generates for us. The one I want to point out is the
:confirm tag. The confirm tag is a data attribute that interrupts the actual
Now let's take a look at what happens when an appointment is actually deleted.
In this controller we need to pull up an appointment record and then delete it. Let's take a look at how we're grabbing the appointment first.
Since we're probably going to need an appointment record in most of our views, we should just create a private instance method that can be shared across multiple controllers.
set_appointment we use the id paramater, passed through from the route, to look up the appointment. Then at the top of our controller we use the
before_action filter like so:
before_action :set_appointment, only: [:show, :edit, :update, :destroy]
This tells our application which controllers to apply this filter to. In this case we only need an appointment when the controller deals with a single appointment.
Now that we have the appointment, we simply need to call
.destroy on it. In a production app you may want to evaluate whether to use
.delete instead of destroy, since both are valid ways to delete a database row in Rails. For our purposes we will use the less-eficient destroy for two reasons:
Appointmentin memory, so that we can flash a success message to the user.
Now that we can interact with our appointments, let's dive into sending out reminders when one of these appointments is coming up.
As an appointment system, I want to notify a user via SMS an arbitrary interval before a future appointment.
There are a lot of ways to build this part of our application, but no matter how you implement it there should be two moving parts:
Let's take a look at how we decided to implement the latter with Delayed::Job.
As we mentioned before, there are a lot of ways to implement a scheduler/worker, but in Rails
Delayed::Job is the most established. If you have found a better way to schedule jobs in Rails please let us know.
Delayed Job needs a backend of some kind to queue the upcoming jobs. Here we have added the ActiveRecord adapter for delayed_job, which uses our database to store the 'Jobs' database. There are plenty of backends supported, so use the correct gem for your application.
Once we included the gem, we need to run
bundle install and run the rake task to create the database.
rails g delayed_job:active_record
You can see all of these steps in the github repo for this project.
Now we're ready to create the actual job.
The next step in sending a reminder to our user is creating the script that we'll fire at some interval before the appointment time. We will end up wanting to schedule this reminder when the appointment is created, so it makes sense to write it as a method on the Appointment model.
The first thing we do is create a Twilio client that will send our SMS via the Twilio REST API. We'll need three things to create the Twilio client:
All of these can be found in your dashboard.
Then all we need to do to send an sms is use the built in
messages.create() to send an SMS to the user's phone.
Because we made our reminder script a method on the model we get one very handy tool; a callback. By using the
before_create callback we ensure that the :reminder gets called whenever an Appointment is created. The last step is making sure this callback always ends up being scheduled by Delayed Job.
Well we're almost done, now all we need to do is write an extremely complicated schedule controller that does the following:
Oh wait, Delayed Job does this for free in one handy method called
handle_asynchronously which tells Delayed Job to schedule this job whenever this method is fired. Since our job time is dependent on the individual Appointment
instance we need to pass the
handle_asynchronously method a function that will calculate the time. In this case
@@REMINDER_TIME is set to 30 minutes, but you can use any
Time interval here.
Now when we create an appointment we will see a new row in the Jobs table, with a time and a method that needs to be fired. Additionally, delayed_job saves errors, and attempts so we can debug any weirdness before it fails. Once it fires a job it removes it from the database, so on a good day we should see an empty database.
Wow, that was quite an undertaking, but in reality we had to write very little code to get automated appointment reminders firing with Twilio. Be sure to check out the project buttons above to download the source for this application, view it on GitHub, or deploy it to Heroku to see it in action for yourself.
We'd also love to hear your feedback on this tutorial - please reach out to us with any questions you might have. Thanks for checking out the tutorial!