If this process could encompass PayPal as well as Ingenico that would be great. Also the question of whether these automated followups would happen in a monthly batch, or could be a more or less continuous process, is worth looking at in terms of debt to build and efficacy in terms of getting donors to re-up with us.

@DStrine If it makes sense for this task to supersede {T200529} I would be all for that! T200529 was partly a tool to enable manual followups, but automated followups are a great deal better.

Multilingual support for this email would be super helpful, and directly increase the rate of donors re-upping. When DS follows up manually with those whose cards expired, we send this messaging, which we also have versions of in Dutch French German Italian Japanese Norwegian Polish Portuguese Romanian Spanish and Swedish.

The last time we measured renewal rates, I think it was around 12-15% renewing after we reached out. It would be neat to make a way in Civi to easily measure the success of these emails.

One feature request: if the text of the Civi email template could contain a unique tag, it would help us to automate responding to any replies we receive in Zendesk. Something like CiviRec, would be great. Even better would be if the ISO code for language was appended, like CiviRecEN, CiviRecFR.

One other note: the timing of this email send would ideally be after any automated retries had been completed ( T244945: Civi: Enable UI to cancel 'failed' recurring Ingenico got me thinking about that).

Also, a continuous or daily send schedule might be better from the donor's point of view: if your recurring donation which processes on the 12th fails, getting an email on the 14th or 15th would make more sense than one at the end of the calendar month.

I just updated the url for "starter text" in the task description. The copy is actually the same as it was in the original link, but I've stripped out some confusing bits from the OG doc.

The copy we're proposing was our standard content when I used to send these manually back in... 2015? We tested it a bit and generally saw about a 45% conversion rate. This copy could probably be further refined, but given its strong performance in the past, it makes sense to me to not reengineer the wheel here. Feel free to move forward with this.

Hi David/FRTech. We have several recurring donations cropping ups that need some messaging around failed donations. It would be really good to have this messaging for Donor Services to have as a tool. Since Paypal has shut off their messaging, we are getting inquires from Donors about this and we need a way to send out a message. Is this anywhere near close to being prioritized? Many thanks

This is in the current sprint and Eileen is looking at it.

@Eileenmcnaughton it looks like you moved this to doing in the last sprint. Where did you get with this? I'm just curious about the approach and if I can help talk it out :).

I have put up a patch for review - it relies on us doing a minor Civi update first - ie https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/civicrm/+/597415/ & putting it onto staging for some testing.

I have a couple of requests

1. should this email be sent after we have retried 3 times & given up ? Or on one of more of the 3 attempts (currently set to the former)
2. Have we got some text in one other language I can set up to test that language too?

Change 598905 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] Temporary hobble on non-English

https://gerrit.wikimedia.org/r/598905

Today @Eileenmcnaughton will work on pulling out the message rendering and tomorrow, I can work on adding a button for recurring contributions so that the email can be previewed and sent.

Change 601578 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm/civicrm@master] Backport Apiv4 ContributionRecur

https://gerrit.wikimedia.org/r/601578

So far, I've added a link to recurring selectors, and then I'm thinking about the best approach for the form. I've looked at how wmf-thank you and eoy_receipts does it. I also wondered if there's any existing civi functionality worth hooking into? I'm getting a little slowed down by indecision and I think I need to just try it with a basic civix generated form. I was also considering how generic to make the form itself, if it might be used for other translated messages in the future..

@mepps I think the recurring selectors might be enough - we don't want to make it hard to maintain for something that might not make much difference, Re the form - yes - I feel like we need to figure out how to define what message templates can be used for what entities - some sort of metadata. I don't think we will nail that this round but we can start thinking about it.

Change 601921 had a related patch set uploaded (by Mepps; owner: Mepps):
[wikimedia/fundraising/crm@master] WIP: Begin link for previewing and sending failed recurring

https://gerrit.wikimedia.org/r/601921

@mepps sorry re-read that - yeah - I would love to use angular rather than quickform but I think the modal thing might make qf a better bet

Change 601578 merged by Eileen:
[wikimedia/fundraising/crm/civicrm@master] Backport Apiv4 ContributionRecur

https://gerrit.wikimedia.org/r/601578

Change 598905 abandoned by Eileen:
Temporary hobble on non-English

Reason:
commits repackaged

https://gerrit.wikimedia.org/r/598905

From our call today, the api calls can live in preProcess and postProcess for the form.

We will also want to change the cancel email method to failure email.

first thing tomorrow i need to get the patches rebased.

Change 602204 had a related patch set uploaded (by Mepps; owner: Mepps):
[wikimedia/fundraising/crm@master] Fix msg_text in template file

https://gerrit.wikimedia.org/r/602204

Okay, getting closer! Final steps on my patch:

• confirm sending is working
• handle errors
• improve status notice message

I'm also wondering if there's an easy way to convert a \n to a <br> either in php or a smarty template.

@mepps I *think* that is we populated msg_text not msg_html the underlying stuff will handle it. Otherwise we could convert to html on the way into the DB - I'm pretty sure there is a handling function of some sort

Change 602550 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] My WIP on the form

https://gerrit.wikimedia.org/r/602550

I just tested the patch from Maggie & added a few fixes. I think that this code could out now & in the current state it adds a new button to the recur allowing a mail to be sent, but it 's not automated until we agree it in conjunction with DS etc. So in the current state it adds a minor feature without changing the main workflow.

Note that for testing on staging I altered the email address of contact 40950658 to be my own and I also set outbound mail to 'mail' for the duration of my testing here - civicrm/admin/setting/smtp?reset=1 (we leave that disabled on staging to avoid mishaps). I will forward the resulting mail to you mepps

This looks like it got most of it @Eileenmcnaughton! Should we add error handling on the form too?

@mepps what handling should we add? Catching exceptions? Although the form probably already does something - Or perhaps if no text is returned a message explaining no email can be sent because there is no usable email? I'm not sure how blocked languages would play in here - I think they can still be sent it's just in SmashPig they won't be

Good questions, @eileen! I was thinking about what to do in the event of an api error but those are also good points.

• api error
• no text
• blocked language?

mepps all of the above looks useful - for an api error the form will already 'do something' - so we only need to handle if we can do something better. But a meaningful message about the contact not having an email or a sendable language might help.

I also think this error handling doesn't block the first iteration & could depend on user feedback

Change 602204 abandoned by Eileen:
Fix msg_text in template file

Reason:
squishy-squash-squashed

https://gerrit.wikimedia.org/r/602204

Change 602550 abandoned by Eileen:
My WIP on the form

Reason:
squished

https://gerrit.wikimedia.org/r/602550

Change 601921 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] Link and form for sending recurring failure messages manually

https://gerrit.wikimedia.org/r/601921

It should now be possible to send these from live - you will see an activity created on any that have been sent

We can enable this with a drush command once it is acceptable. Note we can still improve it further later as required

Change 603763 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] Fix SmashPig form using CRM_Admin_Form_Generic

https://gerrit.wikimedia.org/r/603763

I added a patch to fix the settings form

Thank you @Eileenmcnaughton!

a new button to the recur allowing a mail to be sent

I tested the button, which generated a preview of the email that will go out. There was no final 'send' button but I'm assuming that may have been because I was looking at an active recurring donation.

I appreciate your staging approach to this, and wanted to ask about some next steps:

1. I'd like to suggest that the donation URL be https://donate.wikimedia.org/wiki/Ways_to_Give#Monthly_gift which may be a simpler deploy than trying to force the recurring donation and / or country in the URL. @CCogdill_WMF and other stakeholders it sounds like adding that extra click for donors may be worth a slight dip in conversions if it is less complicated to get done? Let me know if you see a better path!

2. I changed the sender in the copy doc to the DS team, which makes more sense than an individual. Donors can reply to donate@ if they need help, and it seemd silly to make it look like Katherine is sending these.

3. For translations, we're going to modify the existing DS messaging we have for non-EN languages into a document. Is this worth a separate Phab task to add, when they are ready?

4. After another round of review of copy, and the adding of the translations, then it will make sense to turn this on as an automated task?

If there is anything else that DS can test in the meantime please let me know.

So the send button is not showing with shoreditch enabled...

@MBeat33 so regarding the above

1. url - I will change it when you confirm what you want me to change it to.
2. I think it's already changed?
3. Yes - when you have translations to add then add a phab
4. This is a check-box away from being an automated task - just say when.

Change 604214 had a related patch set uploaded (by Eileen; owner: Eileen):
[wikimedia/fundraising/crm@master] Remove submit confirmation

https://gerrit.wikimedia.org/r/604214

@mepps I figured out the shoreditch-bug - (after incurring serious brain injury) https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/604214/

All patches on this are currently reviewed, but I think we might be waiting on a new url to move to pending deployment?

Change 603763 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] Fix SmashPig form using CRM_Admin_Form_Generic

https://gerrit.wikimedia.org/r/603763

Change 604214 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] Remove submit confirmation

https://gerrit.wikimedia.org/r/604214

@MBeat33 we have deployed fixes to the form so it should work without the open-in-new-tab trick. Turning it on for the scheduled job is quick literally a check-box here at the bottom of this page civicrm/settings/smashpig

So really we are waiting on further instruction from you now

Confirmed in call that for English this is switched on as of today - thank you!

I will make a separate Task for the adding translations.

@jkumalah this change may improve recurring donation metrics over time in Civi, so just as a date stamp, today! is when @Eileenmcnaughton switched this on. I'll ping you as well when the translations are uploaded if that's helpful too.

Thanks for the update @MBeat33 !