Guest Post: Implementing Daily, Weekly and Monthly Email Limits

The following post is printed with permission from one of our Certified Professionals, Terri Stephan. Terri can be contacted at tstephan@ecuityedge.com

IMPORTANT NOTE: This solution relies heavily on the use of complex CRM workflows to increment and clear email counts.  For large marketing campaigns involving tens of thousands of emails, CRM performance can be adversely affected by running thousands of workflows. For those situations, we recommend using a different approach such as creating an external application or using a third-party integration tool that utilizes the CRM web services to increment and clear counts more efficiently.  Note that ClickDimensions does not provide technical support for creating or maintaining a system of workflows as described below.

 

Since we utilize ClickDimensions for a wide variety of purposes (e.g., one-to-one ecommerce abandoned cart remarketing campaigns, replenishment, up-sell, cross-sell, nurture campaigns, auto-responders on landing pages), our company needed a way to limit the number of emails any particular customer would receive in a day, a week and a month.  Furthermore, we needed a solution that would work with marketing lists (used for nurture campaigns) as well as our highly-targeted one-to-one emails.

Although not available out-of-the-box, the limits can be achieved with a few enhancements to CRM.  The solution requires the following components:

  • A System Settings entity to define the email limits
  • A way to increment the counts
  • A way to check the counts (and of course prevent email sends if limits have been reached)
  • A way to clear the counts (each time a new day, week or month starts)
  • A way to override the limit for auto-responders (for anything specifically requested by a customer)

The System Settings entity is simple enough, and has a 1:N relationship to Contacts, so that each Contact can have a relationship back to the one System Settings record. (Tip: You can use a workflow to associate the System Settings record with each Contact record.)

St1

To increment the counts, we created fields on the Contact entity to house the counts.  We also added “Limit Hit” fields to show the user when a particular limit is reached (since the limit settings are on the System Settings entity and not otherwise visible).  The counts are incremented by a workflow triggered by the create event on the Sent Email record where the Deliveries count is greater than zero.  Every time a count is incremented, a workflow checks the count against the system settings limit.  If the system limit is reached, the “Limit Hit” field is marked.  Finally, if any of the limit fields are marked, a workflow automatically sets the “Do not allow emails” field on the Contact entity.  ClickDimensions will not send emails if the field is marked “Do not allow.”  (Note: we chose not to use the “Bulk Email” field because it is linked to Unsubscribe logic.  Also we don’t need to worry about interfering with any existing usage of “Do not allow emails” because it will never be unset by our logic if already set.)

St2
 

To check the counts, we really don’t need to do anything!  Setting the “Do not allow emails” field does the work for us by preventing emails from being sent. 

To clear the counts, we utilized the clever trick presented in another blog: http://blog.clickdimensions.com/2013/01/how-to-schedule-workflows-in-microsoft-crm-online.html.  We created a custom entity for our timed trigger and created related records when we incremented counts.  We can run bulk delete jobs daily, weekly and monthly to clear the respective counts.

To override the limits (for auto-responders), we needed some trigger to temporarily clear the “Do not allow emails” flag on the Contact record.  To accomplish this, our options were somewhat limited.  We decided to create a “Follow-up” task before the auto-respond email, and trigger a workflow on the create event of the Task activity that would clear the flag.  Then after the next email goes out, the Email Event trigger will increment the count and cause the “Do not allow emails” flag to be set once again–preventing further emails.

Finally, we implemented charts and dashboards to give us immediate insight into how many customers were hitting limits.  Based on that data, we could effectively change our limit settings or the cadence of our various programs.

St3

 

Interested in learning more about how this was implemented, and if it is suitable for your usage? Contact tstephan@ecuityedge.com

Powered by WPeMatico