3 ms·
Split your mail into 3 classes: 1) Interpersonal. This is your own email that you type and send from your own mail client. Internal discussions. Scheduling a m
by cimmanom 8y ago
Split your mail into 3 classes:
1) Interpersonal. This is your own email that you type and send from your own mail client. Internal discussions. Scheduling a meeting with an investor. Etc. Use a hosted IMAP+SMTP service for this (g suite, zoho, fastmail, whatever).
2) Transactional mail. This is mail that's related to specific interactions on your platform: "thanks for registering" or "you have a new private message" or "your order is in the mail". Legally, there's no obligation to allow users to unsubscribe. You'll be automating the sending of this with code, and once you write and design each message it will be changed infrequently and probably by developers. If you need to do automated processing of incoming mail, it also falls into this bucket. For this you want cheap SMTP and ideally a robust API with pre-parsing of incoming mail. For this you want a service like Mailgun or Sendgrid.
3) Marketing mail. This is newsletters, offers, etc. Broadcast-only (not a conversation). Your marketing team will be customizing these each time they go out, so you need a WYSIWYG interface. Ideally this is also hooked up to a CRM so that you can segment your messaging. You also need automated unsubscribe for compliance purposes. And this is the mail most likely to be actively marked spam, so you want to send from a different hostname and IP than your interpersonal and transactional mail so that your interpersonal/transactional mail won't be auto-filtered as spammy just because users mark your marketing mail as spam. This is what services like mailchimp or constant contact are for.
- stefanski 8y agoWhat CRM do you typically use for a project like this to hook in with marketing mail?
- cimmanom 8y agoGreat question. Ideally your marketing email provider would include its own robust CRM or have excellent integrations into robust third party CRMs. All the options the companies I've worked for have used so far have been extremely awkward fits. I'd be interested in how other people are solving for this.
- bradknowles 8y agoI recommend doing these under three separate but related domains, or at least separate subdomains, and on separate infrastructure. This way, you can allocate an entire domain (or subdomain) for each function, and if you run into problems with your marketing mail going down the tubes because someone decides to put your IP address ranges on a blacklist, that doesn't automatically nuke your main corporate mail and your transactional mail with your existing customers.
- shostack 8y agoHaving dealt with this stuff quite a bit, I'd caution about keeping all your transactional mail siloed. True, many emails may seem not worth having in a business user-friendly ESP where your marketing emails live, but if you keep transactional email on a separate system, you lose a lot of visibility into the role of those emails in your business unless you incorporate them into an analytics system elsewhere. A check confirmation email, account renewal notice or other transactional email couple play a critical role in your funnel or with combating churn. If you don't have it married up with everything else, you'll lose a lot of that insight. Any ESP friendly enough for a business user will likely have an API for sending programmatically. Rates might be a bit higher over something like SES, but that may be worth it depending on your scale. It also let's business users manage templates and such without needing to have an engineer touch code, and the reporting is all there.
- cimmanom 8y agoYou make a good point. The cost balance may depend on your use case and size. I'm currently at a B2C company that sends hundreds of millions of transactional emails per month. We use Sendgrid. They provide basic open and click tracking, which is more information than our small team has the bandwidth to make use of at this point anyway. If you're a B2B sending 10,000 emails per month with high potential value per interaction, integrating transactional and marketing mail and tracking email interactions with transactional mail on a granular level may be worth the additional cost. And a large team may have use for more detailed data, or the capacity to build out reporting and integrations for themselves. But super early stage, that's not the low hanging fruit you should be worried about. And even if you end up using the same platform, for conceptual purposes, for compliance purposes, and for optimizing deliverability you'll want to consider marketing and transactional email separately.