Every day, we all receive dozens of emails from companies and services, promoting products, reminding us of appointments, alerting us to new social media content. Despite consuming all those emails, it’s not immediately obvious how to implement them for your own business, so here’s a primer.
There are two major classes of email that you’ll send. The first is described as transactional email. These are emails like
- “Thanks for signing up”
- “You’ve requested a password reset”
- “Your friend posted a new photo”
- “Shipping on your product was delayed”
and so on. These emails share a few key traits of being
- highly personalized
- sent to a single recipient
- triggered through the user taking action, or an update on a pre-existing transaction the user has agreed to.
Usually, users can manage their email preferences regarding which transactional emails they receive. But notably, these emails enjoy the distinction that they are exempt from most of the regulations of the CAN-SPAM Act. That’s in contrast to the other class of email you send…
These represent pretty much everything else receive, including:
- Special offer
- New Product Announcements
- “Please come back, we miss you”
These are typically sent by the marketing department, are always sent in bulk, and usually have little-to-no personalized content in them, although quite often the email is sent to a segment of the full mailing list (like, only people who’ve purchased a particular product, or people we haven’t seen in a while, or people from the South-west).
Five Steps To Sending
In order to actually get an email sent, there are five things that need to happen. Where and how they happen is at the heart of determining the best email tools strategy for your business.
- Determine the recipient list — that might be just the single user who is getting a transactional alert, or a whole segment of users about to get an announcement of a new fall product line
- Build the content — emails are generally sent with both a rich HTML version, and a plain-text version, these need to be crafted along with all the content
- Personalize the content — as simple as a mail-merge, or as complicated as an algorithmically-driven set of friend-recommendations, most emails will get a least a small personal touch for each recipient
- Queue the email — no matter how you are going to accomplish step 5, it’ll be slower and less reliable than steps 1–3, which means you’ll want to queue up mails to get sent out (you don’t want your whole user sign up process to fail just because there was an error sending the welcome email)
- Send the email — Eventually, there needs to be an SMTP Server somewhere which actually sends the email to the recipients’ mail server(s) of record
For transactional emails, you will typically do steps 1–3 with your own code and systems, and maybe step 4 too. A new user will sign up, you’ll have a hook in your code during signup which captures their information, builds the custom welcome message in HTML and plaintext, submits it to a background queue, which will moments later safely deliver it to an email service provider to handle sending.
For promotional emails, most of these steps will be with an email service provider, who manages your list, helps segment it, has templates for campaign content, does mail-merge-style replacements to lightly personalize the content, and takes care of queueing and sending the mail.
BUT… no matter which kind of email we’re talking…
Don’t Ever Send Your Own Mail!
These days, there is virtually no reason to be sending mail (step 5) yourself. Just don’t do it. If you are going to do it, then it better be a pillar of your business. If it does so happen that you are building an email marketing company, then you should be prepared to hire a full-time staff to deal with scale, deliverability, spam complaint handling, etc. Unless you know you need that, you don’t!
Just to belabor the point, what happens typically is that your development team is running a linux box with your web host. That linux box comes bundled with sendmail or qmail, and a boot service that runs the SMTP server, which by default accepts emails sent from the web server process running on the same machine. Fortunately, this is becoming less and less common, but even in 2013 I see teams that use this kind of set up in development, and it works “well enough” that it never gets revisited in the production environment. Don’t let your developers take this approach.
Sending your own email without knowing deeply what you are doing is a guarantee of poor deliverability, and likely some security flaws and systems issues to boot. Use an Email Service Provider (ESP) in all cases. They are experts at getting email delivered, they have teams of people constantly looking out for your deliverability, email reputation, and as a bonus, they provide the value off of open and click-tracking on all your emails, transactional or promotional.
Tools For the Job
So that’s a lot of background info, when you really just want to know what email provider to use. From a practical perspective, you will want two separate Email Service Providers (ESPs); one for transactional emails and one for promotional emails. A few ESPs will tell you they can handle it all, but for now, that’s just a sales ruse, for two reasons:
- The economics for sending customized 1-off emails (where the content is sent on-demand from the customer, with an expectation that email will get to the recipient’s inbox within seconds) is very different than the economics for sending marketing emails (batches of almost identical emails, sent to a mailing list known in advance by the ESP, and using templates managed in their system, to be delivered any time without a window of a few hours for the whole batch). ESPs want to be able to price these products differently.
- The use-case for these emails are very different. In one case, your application code will trigger emails, and as described above, you basically need a mail server in the cloud. The ESP’s customer is your development team. In the other case, your marketing team wants a great dashboard for managing campaigns, segmenting the mailing list, measuring the effectiveness of coupon campaigns, etc. The only thing these use-cases share in common is the final step of sending an email, otherwise they are fundamentally different products you are buying.
In general, you’ll be looking at prices that vary between $0.10 – $1.00 per thousand emails, depending on the volume you agree to, and the capabilities of the email providers. Big “enterprise-grade” providers can send much higher volume at higher speeds, and provide more elaborate means for building and tracking emails, but you’ll pay for it!