Kavi Help CenterKavi® Members Help
| Chapter 21. How to Schedule Email | ||
|---|---|---|
 |
Part I. Kavi Members Concepts and How-tos | 
|
Table of Contents
Here are some examples of how scheduled email and templates can be created to serve specific use cases. Adding a scheduled email is a two-step process of creating an email template, then scheduling the email so it is generated automatically when a specific event occurs. The template and the email have to be about the same thing in order to be compatible, and each scheduled email should have its own template. You may schedule email in advance of events where future dates are already stored in the system (e.g., membership term end dates), or after events if such notifications are still relevant.
This document assumes you are familiar with concepts introduced in Scheduled Email. You may also want to refer to the Appendix document Kavi Members Email Template Variables.
Super Admins can click here to go to the Manage Email Templates tool or Add an Email Template tool.
Super Admins can click here to go to the Manage Email Schedule tool or Schedule an Email tool.
Back to topThe selection of the appropriate About setting is the first step in adding a template or scheduled email. If the decision isn't immediately obvious, the Schedule an Email tool page displays the events associated with each entity. The most subtle example is a scheduled email that notifies a company representative that their company's membership is expiring so their account is going to be deactivated. In this case the correct About setting isn't Company or Company Representative, because the actual event trigger is 'Deactivation' and the entity affected by it is the User (the Status field in the user's record will be reset to 'inactive').
Once the About setting is selected, it cannot be changed. If the wrong setting was inadvertently selected when adding a , it will becomes apparent on the next step when you find that the event that you wanted to use to use as the message trigger isn't in the list of available events. If this happens to you, use the Back button to return to the first step and select the appropriate object.
Back to topEmail can be scheduled to go out to six months after a user's last login date to invite the user to participate in the organization. A user who hasn't logged in within the last six months isn't actively participating in the organization. This user might be responsive to an emailed invitation to participate more in the organization. Conversely, the organization may discover that the email address is invalid, so this type of tickler has a secondary goal of identifying users who should be removed from the database or contacted through alternate means. Messages sent to these addresses will bounce and can be tracked using the Kavi Mailing List Manager Bounce Report.
This template and schedule are about a 'User' and are usually addressed solely to the user.
The subject line has to be inviting enough make an inactive user want to open the email and read the message without making it sound like spam, something like: New $org_name Activities and Benefits for You.
The message can be personalized by addressing it to the user's full name ('$u_fullname'), then provide a short list of highlights of some new cool activities in the organization and an invitation to login and learn more about these activities. The message could also present some of the contact information currently on file for that user and a request that the user update their account information: While you're logged in, please verify and update your account information. To make it easy to do this, the email includes a login link that takes the user to the ('$u_edit_link'). It would also include variables for whatever contact information your organization wants to verify (such as email address fields, e.g., '$u_primary_email','$u_secondary_email'). There is always the possibility that the user isn't participating because of some perceived issue with the organization, so the message should close with an administrative alias.
The scheduled email has to be about 'User' because this is the only entity that offers 'Last Login Date'. In this example, the When value is set to '6' 'Months After' User is 'Last Login Date'.
The recipients could be restricted by User Type or Purpose if you only wanted this message to go to certain users. For example, you could send it to 'Individual Nonmembers' only to fish for invalid email addresses because your organization doesn't send regular membership messages to nonmembers, or to 'Company Representatives' who have the 'Member Representative' User Type because the participation of member representatives is especially important to your organization.
The only recipient available in the To: option for scheduled email about company representatives is 'User'. Unless the number of recipients is quite small, you probably don't want to CC administrators because the admin reflector could be flooded with messages. Let automated bounce handlers do most of the work for you by filtering out those who have valid email addresses from those who do not.
An email scheduled to go out before a membership enters the archived state is frequently used for "last chance" renewal reminders. When a membership is archived, the member is stripped of types to revoke access privileges, so this information can be included in the notice. You may opt to selectively withhold the notice based on the member's stated renewal intentions and whether the membership renewal process has already been initiated or not.
A membership entering the 'Archived' state is one of two events that support 'Before' notification in Kavi Members. The other is a membership entering the 'Expired' state, which is suitable for earlier renewal reminders.
The template and schedule are about an 'Individual Membership' or a 'Company Membership'. If this is about an 'Individual Membership', the template addresses the member directly. If this is about a 'Company Membership', the template addresses company representatives. For this example the template is about 'Company Membership' and is discretely addressed solely to the 'Primary Contact'.
Textual content in the message body might be repurposed from the organization's other renewal reminders, adding a blurb about the consequences of lapsed membership, and that if the membership is archived before being renewed, company representatives website access will be revoked.
The most important template variables include '$m_expiration_date' (the date that the membership actually expired), '$m_archive_date_predicted' (the date by which the membership needs to be renewed before online access will be revoked) and the '$m_status_link' (a link to the Membership Status Page where the user can click the Renew link to initiate membership renewal). The '$m_renewal_info' variable could be used to display the renewal intentions that are on record for this member. The company name ('$c_name') and Primary Contact name(s) ('$c_primary_contacts') could be included to personalize the message, along with company variables such as the Signup Date ('$c_signup_date') to highlight the company's relationship with the organization. As always, the message should be closed with an administrative contact email address (such as '$org_admin_email').
The Scheduled Email is also about 'Company Membership', and can be scheduled to go days, weeks or months before the membership is archived. The amount of advance warning should be based on the membership grace period. If grace periods vary between different membership types, type-specific last chance renewal reminders can be created. A two-week advanced warning gives just enough time to put a check in the mail. A shorter warning period would require a credit card.
When scheduling an email about a membership entering the archived state, options are displayed on the Details step that can be used to selectively withhold the notice based on the member's renewal intentions and whether the membership renewal process has been initiated. To prevent the last chance notice from annoying those who have already renewed, the option 'Do NOT send if Membership has been renewed, or is in the renewal process' is selected. To prevent this from being sent to companies that have indicated they do not wish to renew, the option 'Do NOT send if Membership is marked as NOT intending to renew' is also selected. There is a third option, 'Do NOT send if Membership is marked as intending to renew' that is more appropriate for early reminders or messages designed to woo members who may be undecided about renewal.
As mentioned, the message can be sent for all membership types or for select types only.
Primary Contact is selected as the only recipient for the 'To' line. As long as the number of messages that might be generated by this scheduled email is not excessive, one of the organization's administrative addresses can be CC'd.
An email can be scheduled to go out when a company representative application has been in the moderation queue for a week.
This template and schedule are about a 'Company Representative' and are aimed at the moderator.
The '$a_moderate_link' variable provides a link that the moderator can click to go to a tool where this company representative application can be moderated. It's a good idea to provide the applicant's full name ('$u_fullname') and the name of their company ('$c_name') for reference.
The Scheduled Email is also about 'Company Representative', and is scheduled for one week after the company representative application enters the moderation queue. If company representative applications are moderated on a website, the moment an application is received it enters the 'Pending Moderation' state, so the When value is set to '1' 'Weeks After' Company Rep is 'Pending Moderation'.
The only recipient available in the To: option for scheduled email about company representatives is 'Company Representative'. If you want this message to go to the moderator only, uncheck the box for 'Company Representative', then select the Administrative Email address (or whatever address your organization uses for company representative moderation requests) in the CC field. The first address in the CC field will be used to populate the To: field when email is sent.
As mentioned, the message can be sent for all membership types or for select types only.
Email can be used to keep administrators abreast of events as they are unfolding. In this example, an organization with billed memberships wants to be notified when members have completed the membership renewal process and paid their membership bills in full. An email triggered on the 'Pending Start Date' state, used in combination with the 'Send for renewing members only' condition, is sent when a renewed membership passes the billing step and is approved. Since most members renew before their current memberships elapse, there is usually a month or more between the date that the membership is approved and the date it goes current, so the 'Pending Start Date' state is used because it provides administrators with the earliest possible notice. For more information on workflow states, see the Membership Workflow Diagram.
When the Membership feature is enabled, some default renewal notifications and templates are installed automatically. You might be tempted to scour the default renewal templates for content that can be reused in this template, but these notices serve a very different purpose and are based on the old membership rather than the new one, so they probably won't be of much use in this scenario. The default renewal notifications are designed to remind members or administrators that a current membership is going to expire soon, so they are about the old membership, scheduled to go out on that membership's expiration date and all membership variables in the email template pertain to the old membership. The example notification is about the new membership, it is scheduled to go out on the date that the new membership is approved and enters the 'Pending Start Date' state, so membership variables in this template are filled with values from the new membership record.
The variables '$m_renewed_with' and '$m_renewed_from' are the best example of this. These fields are used to establish the membership history, and associate each membership in the history with the membership that comes before it (i.e., '$m_renewed_with') and the one that comes after it (i.e., '$m_renewed_from'). Of course, the first membership in the series only has a value in the '$m_renewed_with' field (assuming it was renewed). The most recent membership in the membership history hasn't yet been renewed, so it has a value in the '$m_renewed_from' field, but not in the '$m_renewed_with' field.
This notification was added to provide administrators with advance notice of successfully renewed memberships, so it would probably include the following variables: '$m_membership_type' (the new membership type), '$m_renewed_from' (the old membership type), '$m_amount_billed' (the amount paid), '$m_bill_state' (this information is relevant if memberships are allowed to go current regardless of whether membership bills are paid or not), '$m_start_date' (the date that the new membership will go current).
As mentioned, the successful renewal notice is triggered as memberships enter the 'Pending Start Date' state. All memberships enter this state as soon as they pass any billing and moderation steps and are approved. If the start date is in the future, memberships remain in this state until the start date. If the start date is the current date or even in the past, the membership passes through the 'Pending Start Date' state and becomes 'Current' immediately.
You can't schedule email in advance of the 'Pending Start Date' state, and since prompt notice is desired, you'd configure this email to go out exactly when the membership enters this state.
The Conditions option is set to 'Send for renewing members only' to prevent the auto-renewal notification email from being sent when new, first-time memberships enter the 'Pending Start Date' state.
|
|
 |
|
| Chapter 20. Scheduled Email |  |
Chapter 22. Using Website Tools to Send Email Manually |