Email Mail-Merge Letter Options

There are a number of options around how to do email mail-merge letters in DONATION that I’d like your opinions on.

Currently the only thing you can mass email is the built-in receipts. When you do that, they are saved as PDF files (which is necessary for receipts, at least in Canada, so they aren’t modifiable by the donor who receives them). The program’s user also specifies a text message to go in that email, though no merge fields (like the donor’s name) can be merged into it.

When I add emailing of mail-merge receipts, they will be done basically the same way, as attached PDF files, with (probably) a fixed, non-merged, text portion of the email. (Though that could change if option (1) below is implemented.) This may be the only email mail-merge feature to be added in the next release – I’m not sure yet. Part of that will depend on which of the options below is chosen, and how complex it is to do.

Whenever I do add email merged letters (as opposed to receipts), though, they require some different considerations, because they don’t necessarily have to be sent as PDFs. Here are some options:

  1. Plain text emails only, with merge fields as in the current mail-merge editor, though probably with some limitations (like no <<DetailsTable>> or <<SummaryTable>> fields). This is probably the easiest thing to do, it creates the smallest emails, and has the least issues with compatability between different donor’s email programs. But it also gives the least ability to make the emails look good.
  2. HTML emails, created with DONATION’s current internal mail-merge editor (which is Internet Explorer in edit mode behind the scenes, and is thus editing HTML). These would then be sent as an HTML email (not a PDF). This is fairly simple to do, but has one big problem – different email programs handle different parts of HTML differently, and some are very limited in what HTML they can handle. But the internal mail-merge editor tends to create very complex HTML, and thus when letters edited with it are used as an email, they may not come out well in all donors’ email programs.
  3. HTML emails, created with DONATION’s current internal mail-merge editor, but then saved as PDFs and emailed as attachments, with a standard (non-merged) text portion. This is safe in terms of working well with donors’ email programs, but obviously slower for large numbers, because of the delay for generating each PDF file individually.
  4. A combination of (1) and (3) – a merged plain-text portion, with an attached PDF from a merged HTML portion from the current internal editor. This has the same advantages and disadvantages as (3). However, in terms of the text portion of the email, it’s a bit more complicated, though more flexible in terms of the results, for the user.

While (2) above, a straight HTML email, is the most obvious choice in a way, the concerns about how the HTML emails will come out in different email programs really worry me. Also, there are apparently still people who have email programs that don’t handle HTML at all (or choose to turn off the option to handle HTML in their email programs). To account for that, if you send HTML emails, you must also include a plain-text version that non-HTML email programs will display. (It can be auto-generated by the sending program like DONATION, and HTML email programs will ignore it.) Also, I’m told by the email sending service that I use that mass mailed HTML-only emails, with no plain text version included, are more likely to be classed as SPAM by ISPs or by individuals’ anti-SPAM programs. So, the program would have to add in an automatically converted plain text version to any HTML emails anyways. (You do not want to be classed as a spammer by any of your recipients’ ISPs – that sticks to you, and you may never be able to send to them again!)

This problem about being classed as a spammer by ISPs is actually a bigger problem overall with the whole idea of mass emails. That’s why I switched to using an email-sending service, instead of sending the emails myself, because I started having problems with this when I was sending thousands of emails to DONATION users directly. (The services do all sorts of magic to avoid the problem.) I suspect that if you only have hundreds of donors you are mass emailing to, it’s not very likely to be a  problem, but I will have to warn the larger users of DONATION, with thousands of donors on their mailing list, about this concern!

When I currently send out my HTML emails to DONATION users, I hand edit them to use only extremely simple HTML, to avoid the problems with different email programs’ limitations. That’s obviously not an option that I can force on DONATION users who want to send mass mail-merged emails to their donors!

So, I’m really unclear on what the best solution is here. I could offer only one of the four options above, or more than one, though obviously that significantly increases the complexity for the user, if they have to choose between multiple ways of doing mass emailed letters to donors, and understand their pros and cons. Plus, again obviously, it increases my development time.

What are your thoughts? As usual, please comment by adding Replies to this blog post, if it’s convenient, so we can all join in the discussion and see each other’s thoughts. Thank you!

5 thoughts on “Email Mail-Merge Letter Options

  1. A perfect example of the dangers of HTML emails being inconsistenly displayed in email programs is that when I was editing the blog post, I left a blank line between each of the four numbered items in it, to increase readability. When I received it in Outlook, though, those blank lines had disappeared! It’s a small thing, but symptomatic of the frequency of problems occurring with HTML emails.

  2. Dan,

    Thanks for continuing to enhance DONATION mail merge functions. I’m strongly inclined toward the text-only approach. While the result is aesthetically lacking, it is quick and free of the 1001 quirks of html displaying on different platforms. Let’s face it – DONATION is not primarily a mass-marketing tool.
    I don’t understand the technical challenges with including merge fields – but it probably would be good to have access to sum fields.

    • The only technical challenge for including mail-merge fields in plain-text emails, Bill, is for the fields that display tables of information that are available in the Total Donation Information and Receipt Information merges: <> and <>. The problem there is getting columns to line up properly. It’s possible if you can be guaranteed that a plain-text email will be displayed in a monospace font like Courier in all email programs, but I’m not sure that’s true. In a proportional font, like Arial or Times, there would be no way to make those tables like up, so I think they should not be available.

  3. Another small problem with plain-text emails is that you have to limit line lengths to a reasonable limit (say, 65 characters) because some email programs will otherwise display long lines without wrapping, requiring left-right scrolling!

    And unfortunately, PowerBuilder, the program with which I create DONATION, doesn’t have a plain text editing control that puts in line breaks when text word-wraps onto successive lines. So I will have to hand-code some line-breaking into the sending of the emails. Not a big deal, just a bit annoying!

    I guess in a way it’s actually better, because if the line breaks were already in there, a field like <>, expanded to a longish name, could mess up the lengths of lines. So the program will have to insert the line breaks AFTER doing the merging, if I end up supporting plain-text email mail merging.

  4. Pingback: Beta Test version 3.23, with email mail merge receipts « Software For Nonprofits Blog

Comments are closed.