As a regular feature our blog will include guest posts from different departments around Administrate including Account Management, Business Development, Customer Support, Development, Executives, and Account Executives, so you can get a real insight into how we work as a company.

Email is one of the most important parts of user experience. Whether you're a software company selling a service, or a training company selling education, communication with your customers is key to building strong relationships. The proof is in the pudding - we send over 50,000 emails each month on behalf of our clients, saving over 75,000 sheets of paper!

That being said, sometimes this is easier said than done. Many of our clients run multiple courses per week, with many students attending. Keeping track of who needs what information - and when - could be a nightmare of a task if you're armed with only an email client and a spreadsheet.

Communication Triggers are a simple and effective way to automate communication with your students. Much like the mail-merges that we all had to learn to do in high-school information technology class, they allow templated communications to be sent to students en-masse. It's the 'trigger' part that's our special sauce here though. In just a few clicks, you can set up communications to send automatically to students based on certain trigger points within their learning journey, including when they're initially added to an event, or a specified duration before or after the event start or end date.

The Journey

Initial Release

Many customers who have been with us for a while will remember the old event emails system. It had several particular shortfalls, with issues including:

  • Inability to define attachments at a template level,
  • No transparency on deliverability,
  • Manual process,
  • No standard use of merge fields.

Comms Trigger Screenshot

With our LMS, we found a need to be able to automate communications with students for a variety of reasons, including being able to automatically send out a registration link to set up a password for new students.

We built a brand new system for this - dubbed 'communication triggers.' It makes use of the latest technologies and became part of the building blocks of all of the newer parts of our application, including the sales opportunities system and the new events system.

Comms Trigger Screenshot

As an additional part of the work we carried out here, we were able to integrate much more tightly with our third-party email provider, Mandrill. By using an established provider for email instead of 'rolling our own,' it means we can send email confidently without having another internal sub-system to rely on - after all, communication is 'message sent,' 'message received.' It means that we can focus on the stuff that we're good at!

Using their API, we were able to push new emails to be sent, but additionally query their service to find out if those emails had been delivered, opened, or if any links contained within them had been clicked. We could then push this information right back into Administrate. This provided a level of transparency that we'd never have been able to achieve with the event email system.

Challenges and Improvements

There were several interesting challenges we faced when we were developing the triggers. The first was being able to accurately read through all of the student data stored in Administrate and work out exactly what emails were to be sent. This proved straightforward for triggers set up based 'on registration,' but triggers based on event start and event end were slightly trickier.

We referred to this internally as predicting the future. Given an Administrate instance which has a handful of start and end triggers, many events scheduled months in advance, and tons of students already registered, there rapidly becomes a huge number of permutations of who is to receive which email and when. We iterated through several possible methods of calculating this data, and ultimately came up with a solution which we were happy with, and certainly for the first few months ran well - every five minutes - without issue.

Mandrill Status Checking

One of the first ports of call was to take a look at how often we were asking Mandrill to report back on the status of the emails we had sent. Initially, every five minutes it dutifully checked every sent email which we hadn't yet seen being 'opened,' to see if there were any further updates on the status.

This was a neat idea, but in principle it wasn't scalable. With some clients having tens of thousands of emails sent at this point, something needed to be done. We instead re-worked this somewhat to define that an email should be checked a maximum of ten times, with the delay increasing on a fibbonacci scale (we're all geeks at heart!). As such the status is checked frequently to begin with, and the last few checks are days apart.

September 2015 Improvements

Earlier this year, we revisited the communication triggers again to attempt to solve a few specific problems. Our support desk found themselves frequently responding to many of the same questions, to the tune of around 20-30 support tickets per week:

  • Why do some triggers show as N/A?
  • Why do my triggers sometimes take hours to process and send?
  • Why can't I set up one trigger for a sub-set of courses?

The N/A triggers query was by far the most common. Generally, this occurred when a student was added to an event, and then the communication trigger was created after. That being said, we didn't have good visibility on this within the communication triggers themselves, and without digging through the documentation this was far from obvious.

Around the same time as this, we had a request from a customer who had created events for many of their 'old' events going back several years, and gone through the process of adding students to those events. They set up various communication triggers based hundreds of days after the event ends, to remind students that they had to re-certify. Aware we couldn't process these with the system as it was at that point - the 'historical' status was born, meaning that triggers were generated for these students, but could instead by sent 'manually' in just two clicks. Previously we were unable to calculate triggers in the past due to the sheer volume of data present with some customers, we were able to make several key performance improvements which made this possible.

Comms Trigger Screenshot

Additionally, we reduced the frequency of the event start and event end triggers to only run once an hour. As these were the more intensive triggers to calculate, this meant that we saw immediate improvements in how reliably the on registration triggers were able to run - comfortably back into every-five-minutes region.

The final key part of this improvement work was an improvement to how triggers can be set up with regard to filtering. Previously the only option was to filter to all events, a specific course, or an individual event. We added both the ability to filter by company, location, and region, but also satisfied one of our other 'most requested' features - the ability to select multiple courses. A customer who had 40 courses and required the same template for 35 of them would have previously needed to set up one trigger for every single course, as there was no way to select only the 35 that were required!

Comms Trigger Screenshot

We saw improvements from this almost immediately. Server load decreased, meaning our on-call team can sleep a little easier at night, and the volume of incoming support tickets on the subject dropped, meaning our customers were less confused!

Conclusion

The communication triggers have come a long way since their initial release. There are still more improvements to make, but we now have a stable platform which our customers can rely on to get the right information to the right students, exactly when they need to.