Aller directement à la fin des métadonnées
Aller au début des métadonnées

This page has been initiated by https://issues.civicrm.org/jira/browse/CRM-15461 which highlights some shortcomings in the current set up of Scheduled Reminders.

The aim here is to identify useful user stories that can aid in defining the logic that needs to underpin the handling of scheduled Reminders such that they can be more effectively used.

Scenarios

Please feel free to add details to the scenarios where it makes sense, but if you're describing a variation that makes it a new situation (e.g. extra reminders, date changes, Acts of God), please add it as a new scenario.

A. Basic renewal, annual membership (rolling or fixed)

The organization has rolling one-year memberships with a scheduled reminder that goes out one month in advance.

Alice joins in January 2013, gets a renewal reminder in December 2013 and renews, and expects she should get a reminder in December 2014.

B. Membership with freebie period

Bob joins in September 2013.  He wants to renew in 2014 but is unemployed, and the organization gives him a free extension for four months, until January 2014.  He should have gotten a reminder to renew back in August 2014, and he should get a new reminder to renew in December 2014.

C. Activity reminder

Charlie is assigned to have a meeting tomorrow.  A reminder is set up to go out to assignees a day before each meeting.  He gets the reminder and has to reschedule for next week.  He expects to get a new reminder a day before the new meeting time.

D. Contact date field reminder

The organization has staff maintain CPR certifications and records on each contact's record the date his or her certification expires.

Dawn's CPR certification expires in January 2015, and she got a reminder in October 2014 to recertify.  She's all set, and her record is now updated to expire in January 2018.  She should get a new reminder in October 2017.

E. Contact date field reminder - with repeat

Same organization as Scenario D, but they implement a monthly repeat for the reminder.

Eddie's CPR certification expires in January 2015, and he got a reminder in October 2014, and again in November and December.  He finally gets around to getting recertified, and his record is now updated to expire in January 2018.  The reminders should stop coming for now, but they should start back up in October 2017 coming each month until he recertifies again.

F. Activity reminder - with repeat

An organization reminds staff daily about phone calls that are in Scheduled status and are due that day or earlier.

Fatima has a phone call today she's scheduled for.  She should get a reminder daily until she changes the status to completed.

G. Event reminders when rescheduled

An organization has a reminder the day before an event as well as follow-up messages two days after the event.

Gwen is attending an event tomorrow and gets a reminder for it.  There's a blizzard, and it's postponed until January.  She should get a new reminder for it in January, and she should get the follow-up a couple days after the event, but she shouldn't have received any follow-up after the originally-scheduled date.

H. Event reminders when rescheduled a minor amount on the day the reminders went out.

Same setup as Scenario G.  The reminders job goes off hourly.

Hans is attending an event tomorrow and gets a reminder for it.  Staff at the organization are sticklers for precision, and they alter the start time from 8:30 to 8:35.  Hans shouldn't get a new reminder just because the date has been adjusted a little bit.

I. Alternate membership extension (re: Scenario B).

Same setup as Scenario B.  .

But in this case Bob is starting a new job and just needs a short extension to his membership of a couple of weeks so that we can afford the renewal and not lose the benefit of the fact that he's been a member continuously for 10 years. He calls to explain and is granted a 14 day extension. In this case the staffer who took the call agrees with Bob that they will call him after 13 days to take his credit card details and renew the membership personally. Great customer service. Neither of them want or expect Bob to be sent an automated reminder in the intervening period.

J. VIP shouldn't get auto reminders

Same setup as Scenario A.

Jill is a board member and busy high-profile person who should get personal communications or none at all.  She should be excluded from automatic renewal reminders.

K. Subscribe / unsubscribe events

The organization has a subscription page for public groups.  They want to welcome new subscribers automatically with emails 1, 2, and 3 weeks after subscription.

Karen just subscribed to the Newsletter group.  She should get that welcome series without anyone having to record an activity.

L. Limit to and also include required

Jane has opted out of bulk emails and should not be sent scheduled reminders even if they are reminders for events she has registered for or for memberships she holds. The organisation wants to send  a reminder 5 days before an event to all participants and also to the office manager who isn't registered for the event. Currently the only way to do this is to use the 'limit to functionality' with an "OK to bulk email" smart group.  That effectively means that "Also include" can never be used participant or membership reminders.

Proposed Changes

(and how they would affect the scenarios)

Adding reference date to civicrm_action_log entries

This would record the date (activity date, event end date, membership end date, etc.) by which the reminder is triggered.  When evaluating whether a reminder has been sent, the system would not only check for the actionSchedule ID and entity ID, but also it would check that the reference date is the same.  If all three match, the reminder is considered already sent.  If the reference date differs (e.g. the reminder was for the previous membership end date in Scenario A), it's as if there never was a reminder for that entity.

This would solve the issues in Scenarios A, B, C, D, E, F, and G when the date is altered by renewal or rescheduling.  It would result in a new set of reminders going out in Scenario H.  That would be unfortunate, but it's tempered by the fact that it would only happen if

  • there's an inconsequential change in the time and
  • that change is made after reminders have gone out, but
  • that change is made while it's still a valid time to send out that reminder that just went out

Add the "exclude" option for groups

In addition to the ability to limit recipients of a reminder to contacts in a group and the ability to add a group to the recipients of a reminder, this would exclude people in a group from receiving a reminder.  This would be very useful for Scenario J, and it would be an option for Scenario I.

Add a "suppress reminders" option for memberships (and possibly activities)

On a per-membership basis, you could check a box that would prevent reminders from going out regarding the membership.  This would be the simplest solution for Scenario I, and it would be an option for Scenario J.

Scheduled reminders based on subscription history

Contacts could get messages upon joining or leaving a group.  This addresses Scenario K.

Allow both "Limit to" and "Also include" for the same reminder.

These would not be mutually exclusive options in an dropdown list, but would be independent tick boxes each with its own set of fields for limiting or adding to the basic list of recipients.  This addresses Scenario L.  If the "exclude" option for groups is added then this may also need to be created as a third tick box with another set of fields. (https://issues.civicrm.org/jira/browse/CRM-16094)

 

Étiquette
  • Aucun
  1. Mar 13, 2015

    Peter Davis dit :

    If it isn't already possible, it seems like a scheduled reminder to an 'event owner' would be useful. But currently there is no 'owner' concept afaik. That could be another 'participant role' but in the use case I am exploring this is for repeating events, and it would be a pain to have to add the 'owner' each time the event is created. Guess a 'trigger' would suffice as this is probably an edge case and I just talked myself out of posting this (clin d'œil)

  2. Mar 13, 2015

    I created https://issues.civicrm.org/jira/browse/CRM-16094 which is a solution for scenario L before I found this page.  I intend to pursue it at my usual snail's pace which means perhaps in 12 months there will be a PR.