Civi Email Wishlist (#CiviCRM)

Posted on by — 1 Comment ↓

I was only able to join the recent CiviCRM book sprint for 2 days but I did spend most of that time working on documenting email in Civi (both CiviMail and core email functionality). As part of that process I discovered a lot of things about email in Civi and hopefully made those features explicit for other users (although there will always be room for improvement). But I also took the opportunity to compile a wishlist of features (modeled on the recent CiviCase wishlist) that would be nice for email in Civi and CiviMail. Some of these have already been discussed on http://wiki.civicrm.org/confluence/display/CRMDOC40/Improvements+on+CiviMail but I thought I’d leave them in to provide additional perspective (the relevant points are marked as [Already mooted].

Contents

Core email functionality

  1. It would be nice if footers could be inserted for email sent as activity as well as mass mailings (another solution would be to make it possible for staff sending emails to configure signatures) Lack of signatures makes using Civi to send emails a less appealing option for admin staff. We do use templates but since they can’t be combined this is a cumbersome solution.
  2. It is almost impossible to provide sufficient training and/or QA process to make sure staff always check the Plain Text version is the same as the HTML version. A filter that would automatically create a Plain Text version would be a simple thing to implement – strip out tags, convert links and lists – there must be code out there for this that could just be plugged in. The only difficulty would be with tables but that could be done manually when table tags are present.
  3. It would be nice if there was a list somewhere of all the emails sent from the database as activities. It would make tracking much easier.
  4. When users subscribe to multiple public groups at once, an confirmation email is sent for each group separately. It would be nice if the subscription confirmation could be handled with just one link or at least have all the links sent as part of one email. (BTW: Not sure how much this is used at the moment but the feature has now been properly documented so it may see a bigger uptake). [Already mooted]

CiviMail functionality

  1. It would be nice if we could preview a list of mass mailing recipients before sending. The number just is not enough (I have sent mailings to the wrong groups twice). This may not be useful for people sending truly mass mailings but most of our mailings are in the low hundreds so it is possible to see at a glance if it’s being sent to the right group. And of course it would give an indication with complex inclusions and exclusions, whether the logic produces expected results.
  2. This is a small thing but one that comes up all the time. It would be nice if we could insert a CC/BCC email for mass mailings just like with emails sent as activities. I know this can be done by groups but 1. this would result in lots of 1 person groups for us and 2. it adds one more thing for which we have to provide training and documentation. [Already mooted]
  3. Very often we want to send people information related to their participant record but the tokens don’t allow for that. Perhaps a solution would be event/contribution/membership tokens that would specify which event, membership, contribution the data for the token should be taken from. An integration of CiviMail with CiviEvent has been completed as MIH (http://wiki.civicrm.org/confluence/display/CRM/Scheduled+Reminders+for+Events) but it does not support custom data as tokens which is what is really needed. Also, it won’t support contribution and membership tokens.
  4. We often use CiviMail to send emails to staff or students (we have over 50) who are confused by the compulsory unsubscription/optout/domain link because they are not allowed to unsubscribe from messages from us. It would be nice if this wasn’t compulsory by default (organizations should be responsible for legal compliance) or if there was a checkbox somewhere saying “This is an internal mailing, no legal opt-out compliance is necessary”
  5. It would be great if the mass mailing creator could always receive a notification email if there are bounces on a mailing. This would make workflows and training so much simpler.
  6. If link tracking is turned on, clean links are overwritten with long ugly links. Could these be generated as short codes in Drupal – e.g. mysite.com/civilink/ioywe843. This would make emails much easier to display and forward.
  7. I understand the reason for the unsubscription group when mass mailing is sent based on search but perhaps Civi could provide one by default or not make it compulsory – we often use this to send email to staff or students where no unsubscription is required.
  8. Mailings sent to recipients based on a search cannot be reused or saved for editing later. It would be nice if this was not the case, or at least, if there was a warning and the Save and continue later button was disabled.

CiviMail Interface

  1. The big one is tabbed navigation as in CiviEvent or on contribution pages. This has been under discussion for a while but it would be a huge boon.(http://wiki.civicrm.org/confluence/display/CRMDOC40/Improvements+on+CiviMail)
  2. The group/mailing selection areas in Step 1 need at least a vertical scroll bar. We have long names for groups and mailings that are often differentiated by the last bit only. We had to set a naming policy but that is hard to enforce. (BTW: This is also a problem in Report creation.) But a much deeper interface overhaul would be best. Why not select recipients the same way Groups and Tags are selected in the Advanced Search interface or the way To, CC, BCC recipients are selected (i.e. based on a search rather than a list). This could also make it possible to reduce the total number of screens/steps (I think 3 would be ideal: 1: Message options: Recipients, Tracking, Footer/Header, etc. 2. Message composition, preview, test 3. Sending and scheduling.)
  3. It would be nice if the Screen 1 mailing would contain an ajax button that would display the number of recipients without having to go to the next screen. Or at least place some text
  4. Another way to simplify the task of mailing would be a Quick Mass Mail interface that would just take the default settings and allow the user to create a mailing on one screen and then have one more screen to test and send it.

General Email Interface

  1. When sending an email to recipients based on search results, the titles in the – actions – drop down menu are inconsistent. We should change “Send Email to Contacts” to “Send an Email to Contacts”. This would make it consistent with the activity name which is “Send an Email”
  2. On the message template editing pages, “Message title” should be “Message template name” to avoid confusion with subject
  3. The Site Domain title is very confusing. Perhaps renaming it to Default Organization Contact Details or something like that would be better.