1. iClassPro Support
  2. Knowledgebase
  3. Autopilot

Which Autopilot Workflows are Available?

IN THIS ARTICLE:
Learn about which automated workflows are available for iClassPro's Autopilot feature and what aspects of the workflow can be customized.

Choosing the Best Communication Type

There are three communication types that can be triggered for Autopilot workflows: Email, SMS/Text message, or Push notification.

Typically, you will want to choose a specific communication type at different times and for different reasons.  For example:

  1. Email: contrary to popular belief, emails should actually be the least common form of communication with your customers. Emails typically see between a 20-40% open rate. The more emails a customer receives, the less likely they are to open it. Therefore, the open rate will actually increase the fewer emails you send.
    • Use emails for Marketing, reminders, or as a Final Notice. As a general rule, use email for things that are not urgent, messages that are not as important if they aren’t opened, or where you’ve already tried to contact the customer another way.
  2. SMS/Text message: SMS messages typically drive action. When a customer receives an SMS message, they typically look at it immediately. Use SMS messages when you want the customer to take immediate action on a matter, or if you are relaying information that is urgent.
  3. Push notification: most customers who will take action on a Push notification are customers who are already actively engaged with your business. Push notifications are the least intrusive communication type and therefore can be used the most often (although we still only recommend sending them about once a day). It is recommended that you use Push notifications for notifications, reminders, and updates.

If options for SMS or Push notifications are selected, templates for these communication types must be created for the workflow to complete. (Note that Push notifications are not guardian-specific and are sent to all devices linked to a specific family.)

Unless specified otherwise, all communication templates used for Autopilot can be customized under SETTINGS>SETUP>GENERAL SETTINGS>COMMUNICATION TEMPLATES>"Autopilot" tab.

Event-driven workflows are triggered if a specific event occurs. (e.g., an enrollment action, family creation, etc.).

Schedule-driven workflows are triggered on a specific day or date/time. (e.g., on the Nth day of the month, on a specific day of the week, etc.)

Available workflows are:

Check for policy acceptance upon enrollment

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • When an enrollment is created, detects whether the student and family have accepted required policies. If "No Activity" is detected, it sends a notification immediately with links to accept the policies.
      • NOTE: This workflow will check for missing acceptance of both required Student policies AND Family policies.
  • Which communication template is used?
    • Family Required Policy Acceptance Link
  • Which criteria can be customized?
    • Send Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

As this workflow is event-triggered and communications are sent immediately, there should only ever be one instance of this workflow running. Otherwise, the customer will receive multiple communications as the event will trigger all instances of the workflow.

 

 

Dropped enrollment follow-up

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a notification to students who have dropped a previous enrollment who do not have a current or future enrollment within "X" days of the drop.
  • Which communication template is used?
    • Dropped Enrollment with No Follow Up
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the enrollment has ended to check for a current or future enrollment.
        • NOTE: This period defaults to three (3) days.
          • When the workflow is triggered, the system WILL NOT count any enrollments for classes that have already occurred for the day. However, if the class has not yet met as of the time the workflow is triggered, these enrollments WILL be counted.
    • Send Communication
      • Send by
        • Family - sends one email per family.
        • Student - sends one email per student (therefore, families with multiple students will receive multiple emails).
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This event-triggered workflow could have multiple workflows depending on your needs:

  • 03 days: "We are sad to see you go!" (Push notification / SMS)
  • 14 days: "Can we get feedback on why you left?" (Email)

 

Expire Makeup Tokens

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • If enabled, the workflow will wait a specified number of days after an enrollment drops. At that time, the system will check to see whether the student has any current or future class enrollments. If no class enrollments are found, all makeup tokens linked to the student will be updated to expire as of the current date.
      • NOTE: This workflow will only be triggered by enrollments that are dropped AFTER it has been enabled. It will not retroactively consider previously dropped enrollments.
  • Which communication template is used?
    • Unlike other Autopilot workflows, this workflow does not trigger any communication with the customer. It simply just sets an immediate expiration date on any remaining makeup tokens.
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the enrollment has ended to check for a current or future enrollment.
    • Count Class Enrollments
      • Defines which Enrollment Types should be considered when checking for a current or future enrollment.
        • Active (default)
        • Trial
        • Wait
        • Makeup

  [+] Best Practice Recommendations (click to expand)

As this workflow does not trigger communication with customers letting them know that Makeup Tokens will automatically expire "X" many days after a drop if no current or future enrollments exist, we recommend updating any policies related to Makeups/Makeup Tokens to explain this updated behavior. This will create a new policy version, which families will be required to read and accept.

 

First class enrollment follow-up

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a notification to families 'X' many days after the start date of their first-ever class enrollment for which they were marked "Present."
      • NOTE: at this time, the workflow only looks for class-related enrollments, not camp enrollments or appointment bookings.
  • Which communication template is used?
    • First Class Enrollment Follow Up
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the start date of the first class enrollment to send follow-up communication.
        • NOTE: This period defaults to three (3) days.
          • When the workflow is triggered, the system WILL NOT count any enrollments for classes that have already occurred for the day. However, if the class has not yet met as of the time the workflow is triggered, these enrollments WILL be counted.
    • Send Communication
      • Send by
        • Family - sends one email per family.
        • Student - sends one email per student (therefore, families with multiple students will receive multiple emails).
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow could have multiple instances running depending on your needs:

  • 01 day: “We loved having you in class, thanks for joining us!” (Push notification / SMS)
  • 28 days: "How you are enjoying your lessons? We would love your feedback!" (Email)

 

Invalid payment information

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a notification to customers when their payment method is marked "invalid" in the database.
  • Which communication template is used?
    • Invalid Payment Information
  • Which criteria can be customized?
    • Send Communication by Family
      • Reply To Email
        • As this email is not limited to families with an active or future enrollment, this will default to the Primary Contact email if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

As this workflow is event-triggered and communications are sent immediately, there should only ever be one instance of this workflow running. Otherwise, the customer will receive multiple communications as the event will trigger all instances of the workflow.

 

Missing policy acceptance

  • How is it triggered?
    • This is an Schedule-driven workflow.
  • What does it do?
    • On 'X' day of the month, detects whether a family has accepted required policies. If "No Activity" is detected, it sends a notification with links to accept the policies.
      • NOTE: This workflow only checks families with a current or future enrollment.  The system only checks for missing acceptance of Family policies (not Student policies).
  • Which communication template is used?
    • Family Required Policy Acceptance Link
  • Which criteria can be customized?
    • Scheduled Event
      • Nth day of the month
        • Defines the day of the month on which the system should check for families that have not accepted all required policies.
      • Time
        • Defines the time of day at which the system should check for families that have not accepted all required policies.
    • Send Bulk Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow would usually be triggered before a student's enrollment begins (prior to the first day of class). This could be duplicated depending on your business needs (for example, sending notifications twice a month for those with fortnightly billing scenarios where a student's enrollment might begin in the middle of the month)..

If more than two instances of the workflow are configured, we recommend using Push notifications as the communication method for any additional instances.

 

Mobile app not downloaded after enrollment

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • If a family has not downloaded the mobile app "X" many days after the start date of their first-ever enrollment, it sends them a notification with a link to do so.
  • Which communication template is used?
    • We Have a Mobile App!
      • NOTE: This template is located under SETTINGS>SETUP>GENERAL SETTINGS>COMMUNICATION TEMPLATES>"Custom" tab.
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the enrollment start date to check for any mobile app downloads connected with the family.
        • NOTE: This period defaults to three (3) days.
          • When the workflow is triggered, the system WILL NOT count any enrollments for classes that have already occurred for the day. However, if the class has not yet met as of the time the workflow is triggered, these enrollments WILL be counted.
    • Send Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
        • NOTE: Due to the nature of this communication, emails will only be sent to email addresses that have opted in for Email Blasts/marketing emails.
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow is likely to have multiple instances to serve as a regular reminder throughout the student's first month to download the mobile app. The best practice would be to have this workflow configured to run three times.

  • 01 day: “Don’t forget to download our mobile app!” (SMS)
  • 14 days: “Did you know we have a mobile app? It's a great way to keep up with your child's progress!” (Email)
  • 30 days: Email again

(As Push notifications require the mobile app to be received, there is no reason to enable Push notifications for this workflow.)

 

New family account created with no enrollments

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a notification to customers who have created a family account via the Customer Portal/Mobile App, but have not created any class enrollments.
      • NOTE: at this time, the workflow looks for class-related enrollments of all types (including Waitlisted enrollments). It does not check for camp enrollments or appointment bookings.
  • Which communication template is used?
    • Family Account Created with No Enrollments
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the account has been created to check for class enrollments.
        • NOTE: This period defaults to three (3) days. Due to the way iClassPro handles enrollment start/drop times, the defined timeframe cannot be less than one (1) day.
    • Send Communication by Family
      • Reply To Email
        • As this email is not limited to families with an active or future enrollment, this will default to the Primary Contact email if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow could have multiple instances running depending on your needs:

  • 07 day: Gentle reminder to complete enrollment (SMS)
  • 14 days: Stronger reminder to complete enrollment (Email)
  • 28 days: Stronger reminder to complete enrollment (Email again)

 

Overdue balance

  • How is it triggered?
    • This is an Schedule-driven workflow.
  • What does it do?
    • Sends a notification on the Xth of every month to customers with an overdue balance.
  • Which communication template is used?
    • Overdue Balance Notification
  • Which criteria can be customized?
    • Scheduled Event
      • Nth day of the month
        • Defines the day of the month on which the system should check for overdue charges.
      • Time
        • Defines the time of day at which the system should check for overdue charges.
    • Send Bulk Communication by Family
      • Reply To Email
        • As this email is not limited to families with an active or future enrollment, this will default to the Primary Contact email if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification
      • Search by Days Overdue
        • Limits results only to families who have charges where the charge due date falls within the chosen range.
          • 1-15 Days (selected by default)
          • 16-30 Days (selected by default)
          • 31-60 Days
          • 61-90 Days
          • Over 90 Days

  [+] Best Practice Recommendations (click to expand)

This workflow has the highest chance of getting reported as Spam, since overduplication could lead the workflow to trigger communications every day. This is a great task for all three communication methods. (depending on whether the business is actively using the class drops task, you would want to trigger this before running the class drops task.)

Recommendation: Schedule these to run a defined number days AFTER you usually run the payments task. (For example, if you generally run payments on the 5th of the month and run drops on the 15th, you might want to schedule these workflows to run on the 10th day of the month.)

  • 01-15 days past due: Push notification
  • 16-30 days past due: SMS (NOTE: this may take the place of 0-15 if using the class drops task)
  • 30-90 days past due: Email

 

Party Follow Up

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a communication to families a certain number of days after their party has occurred.
  • Which communication template is used?
    • Party Followup
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the party was scheduled to occur to ensure that the booking still exists.
        • NOTE: This period defaults to three (3) days.
    • Send Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow could have multiple instances running depending on your needs:

  • 01 day: “Thank you for letting us be part of your special day! We hope you will consider us for any of your party needs in the future.” (Push notification / SMS)
  • 28 days: "Did you enjoy your party with us? We would love your feedback!" (Email)

 

Payment method expiring

  • How is it triggered?
    • This is an Schedule-driven workflow.
  • What does it do?
    • Sends a notification to customers with a current or future enrollment when their payment method is due to expire in the current month.
      • NOTE: Currently, this workflow will only check the default payment method linked to the Primary Guardian on the family account.
  • Which communication template is used?
    • Payment Method Expiring
  • Which criteria can be customized?
    • Scheduled Event
      • Nth day of the month
        • Defines the day of the month on which the system should check for payment methods that will expire in the current month.
      • Time
        • Defines the time of day at which the system should check for payment methods that will expire in the current month.
    • Send Bulk Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
        • NOTE: As the system only checks payment methods linked to the Primary Guardian, this is the only guardian that will be notified. If "Send Email" is selected, email will only be sent to the primary email linked to the Primary Guardian.  If "Send to All Emails" is selected, the system will send email to all email methods linked to the Primary Guardian. Secondary guardians will not receive any emails.
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

This workflow should be run twice a month:

  • Between 1st and 5th of the month: to notify customers of expiring cards (Email/SMS)
  • Prior to billing date: reminder (SMS/Push notification)

 

Send Waitlist Offer

 

Trial enrollment follow-up

  • How is it triggered?
    • This is an Event-driven workflow.
  • What does it do?
    • Sends a notification to customers who have had a trial enrollment, but do not have a current or future enrollment within "X" days of the trial.
  • Which communication template is used?
    • Trial Enrollment Follow-Up
  • Which criteria can be customized?
    • Wait for Action
      • Defines how many days/hours/minutes the system should wait after the trial enrollment to check for a current or future enrollment.
        • NOTE: This period defaults to five (5) days.
          • When the workflow is triggered, the system WILL NOT count any enrollments for classes that have already occurred for the day. However, if the class has not yet met as of the time the workflow is triggered, these enrollments WILL be counted.
    • Send Communication
      • Send by
        • Family - sends one email per family.
        • Student - sends one email per student (therefore, families with multiple students will receive multiple emails).
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification

  [+] Best Practice Recommendations (click to expand)

For the most effective communication, this workflow should be duplicated. Once again, we recommend using three instances:

  • 01 day: “Thank you for your Trial! Please sign up for a recurring enrollment!” (Push notification)
  • 14 days: Stronger suggestion to sign up for an ongoing enrollment (SMS)
  • 28 days: Feedback request for the trial enrollment (e.g., why didn’t you continue?) (Email)

 

Upcoming birthday

  • How is it triggered?
    • This is an Schedule-driven workflow.
  • What does it do?
    • Sends a notification to families who have one or more student(s) with a birthday exactly 'X' days from the current date.
  • Which communication template is used?
    • Future Birthday Notification
  • Which criteria can be customized?
    • Scheduled Event
      • Select days of each week
        • Defines the day(s) of the week on which the system should check for students who will have a birthday exactly 'X' days from the selected day.
      • Time
        • Defines the time of day at which the system should check for students who will have a birthday exactly 'X' days from the selected day.
    • Send Communication
      • Reply To Email
        • As this workflow can be configured to send to Inactive families/students, this will default to the Primary Contact email if none is provided.
      • Send Email / Send To All Emails
        • NOTE: Due to the nature of this communication, emails will only be sent to email addresses that have opted in for Email Blasts/marketing emails.
      • Send SMS / Send To All SMS
      • Send Push Notification
      • Ages
      • Birthday in X Days
        • Defines how many days from the current date a student's birthday must be in order for the family to be included in the communication.
      • Enrollment Types

  [+] Best Practice Recommendations (click to expand)

This workflow could have multiple instances running depending on your needs:

  • 60-90 days before birthday: Marketing email to promote hosting a birthday party at your facility (Email)
  • 0-1 days before birthday: "Happy birthday!" (SMS/Push notification)

 

Upcoming charge due

  • How is it triggered?
    • This is an Schedule-driven workflow.
  • What does it do?
    • Sends a notification to customers who have an upcoming charge due in the next 'X' days.
  • Which communication template is used?
    • Charge Due in X Days Notification
  • Which criteria can be customized?
    • Scheduled Event
      • Nth day of the month
        • Defines the day of the month on which the system should check for charges that will be due based on the "Balance Due in X Days" criteria specified below.
      • Time
        • Defines the time of day at which the system should check for charges that will be due based on the "Balance Due in X Days" criteria specified below.
    • Send Bulk Communication by Family
      • Reply To Email
        • Defaults to the Location email address if none is provided.
      • Send Email / Send To All Emails
      • Send SMS / Send To All SMS
      • Send Push Notification
      • Balance Due in X Days
        • Defines how many days from the current date charge(s) must be due in order for the family to be included in the communication.
          • NOTE: This period defaults to fifteen (15) days.

  [+] Best Practice Recommendations (click to expand)

This workflow should only be used once, and only if there is a delay between running the charges task and the payment task.

For example:

  • Run charges task on the 25th of the month.
  • Schedule this workflow to run on the 26th of the month.
  • Run payments task on the first of the following month.

Need more assistance?

Customer support is available at 1-877-554-6776 Mon - Fri, 9 am to 9 pm (CT) and Sat, 9 am to 6 pm (CT).