October 31, 2008 | By | General Blogging

Just to be clear about what I am looking for in a newsletter system, here are my major requirements:

  • Easy to use; difficult to make mistakes. Once set up, and end client should be able to use it, and it should be very clear what the client needs to do, and what the system is doing for the client.
  • No queues to get stuck. I don’t want to be unlocking files, killing background processes and not knowing how far the sending has gone. Press button to go, and if it fails, press it again to continue where it left off.
  • Templates. Each message can be created from an initial template. There are two types of template here: the wrapper template that the entered newsletter is insterted into, and the initial template that is given to the user as initial content for the newsletter. The latter can often be kept as an external file and loaded in each time, but that is too hard for end users.
  • Safe and secure registration and deregistration. Use of a capcha to reduce robot spam, and use of a double e-mail system to confirm e-mails are live.
  • Bounce handling. It is surprising how quickly e-mails expire, and I would like to be able to catch them and filter them out. This is expecially true of hotmail and ISP-supplied e-mail addresses, as people only seem to keep them for a few months before moving on. Muppets.
  • Link tracking. To be able to see when an e-mail is opened, is very handy to end clients. It’s not perfect, but it gives an idea of how successful a newsletter is.
  • Custom fields. Being able to define custom fields and assign them to specific newsletters, and use them in templates, is all very handy. Luckily most systems support custom fields.
  • An API. This is rare. Being able to subscribe a user as they register for a CMS – that’s handy.
  • E-mail history. Knowing which users have received which newsletters allows specific newsletters to be resent to a group, picking out just the new subscribers who have not yet recieved that newsletter. If the e-mail send is run daily on a cron job, until the next issue is sent, then new subscribers get an instant catch-up.
  • Newsletter online. This allows a subscriber to view the same newsletter online, in a web page. This particularly useful for web-mail users, where the HTML newsletter may not be displayed properly in their client.
  • Newsletter archive. An archive of older newsletters. Sometimes the archive and online versions should not be made public. The ability to turn on restricted access to registered subscribers, on a newsletter-by-newsletter basis, is important.

Next I will compare how well the systems I have looked at fit into this requirements list.