blog

Every email your company needs to send, and how to send them

There is more to company email than onboarding drips and newsletters

Every email your company needs to send, and how to send them

45 emails are sent, every day, for every human alive on earth (that is, if Statista’s email stats and the UN’s population stats are accurate). Nearly two emails, per hour, per person, per day. Activation emails, newsletters, receipts, shipping notices, mentions and comments (and spam. Far too much spam.).

You can minimize your email footprint and trim down how many messages your company sends. Odds are, you’ll boost your open rates and general customer happiness that way. But some emails are expected, required even. There are more of them than you might expect when you first start your business. Shopify’s settings include 45 different email notifications that you can customize, everything from order confirmation and shipping notifications to password reset and payment error emails. Software (like Buttondown) and digital products come with their own email requirements to account for, from account verification to collaboration invitation messages.

What emails should you send? Where should you send them from? Here’s a list of the most common emails your team should be sending—and how to send them.

Marketing Emails: Waitlist, Newsletters, Onboarding, and Updates

Let’s start with the emails that likely came to mind first when you started your business: Newsletters.

You’re building pre-launch excitement for your product, and need a way to keep building that excitement and to let people know when your product is launched. A waitlist paired with a newsletter is perfect for that.

We’re biased, but we think Buttondown is perfect for those emails, plus all of the other marketing emails you’ll need to send over time.

Waitlist

Start with a sign up form. Build your own, add a 3rd party form and connect it with Zapier integrations, or grab Buttondown’s signup form code and embed it on your site.

Ideally, you’ll want to offer a waitlist form, with an opt-in to your newsletter.

For people who only join the waitlist, send them an automated email thanking them for joining. Then send a newsletter to the full list once when your product launches—which should be the same as a normal email newsletter, unless your product needs a unique invite code in which case you’ll need to either add a code to each subscriber’s Buttondown profile then include it in the email with a template variable.

Waitlist subscribers who don’t sign up should at most get one more, a bit later, as a reminder (if so, have your app use Buttondown’s API to take people off the waitlist when they sign up for your app). And if subscribers don’t convert, that’s ok; don’t overdo emails at this stage, and maybe they’ll eventually come back and rediscover your product.

Newsletters and Onboarding

For everyone else who opts in, here’s your chance to kick off your newsletter. Keep it simple and personal, with Buttondown’s default, Gmail-like theme, to share behind-the-scenes glimpses at your build process and how your team’s thinking through important product decisions. Or, add your logo and colors to emphasize your company’s branding pre-launch. Post-launch, repurpose this list into your company’s default marketing channel.

Pre-launch, you’ll also want to add onboarding emails. Buttondown’s automations can work for that, too. List out the things you’ll need to teach users, and the feedback you’d like to receive from them. Work them into 3-5 emails, add them to Buttondown’s Automations, and schedule them a few days apart.

Over time, you’ll want to add more marketing emails. Perhaps a product update blog where you share new features, a dev blog where you write more technical newsletters and share changelogs, and more. You might even want one-off lists for special events—a signup form followed by regular email updates for a conference, say. Run all of those through Buttondown, as normal.

Support Emails

People will have questions. Comments. Ideas. They’ll reply to your onboarding emails and newsletters, if you’re lucky.

When you first start out, your normal email account is all you need. Set up a new company email account, the same way you manage team emails (in Google Workspace or another email service), add it as a Contact Us email on your site, and use it as the reply address in your Buttondown automated emails and newsletters. Add an auto-reply, if you’d like, to let people know you got their message and will get back to them ASAP. Then reply as normal, just as you would with any other email.

Long-term, as your team grows, migrate that to a customer support app, something like Help Scout or Zendesk, Front or Intercom. You need a shared inbox, where your team can reply to customers together in the same place. Keep the emails simple; a plain, Gmail-style email is still likely best for a personal touch. And add automations that help your team—auto-replies with suggested documentations, or pre-written snippets to save time—but try to keep your emails human and friendly.

Support emails are emails you’ll keep tweaking over time, but they’d never make sense to handle through anything other than a personal email client for small volume, then a dedicated support app at scale.

Account Emails

Then come the emails that need to be sent from your app.

Not directly from your app, per se. Buttondown uses Postmark and Amazon SES to send emails; your app should use those or other transactional email services to actually send the emails via API calls.

Then build out triggers in your app, add HTML email templates with your company’s branding and style, and send them through your email API.

You’ll need account verification emails, plus a verification reminder a few days later if users don’t activate. Login emails, if you want to use Slack-style Magic Link emails instead of passwords. Password reset emails, for accounts with passwords. Activity messages, like when DigitalOcean tells you a server is ready, your credit card says you’ve made a purchase, or Buttondown tells you someone joined your email list. Inactivity messages, to bring users back when they’ve fallen away. Shipping notifications, if you’re selling physical products.

Each of those emails require a relatively simple email template, paired perhaps with the customer’s name, unique links for their account, and activity details if needed. More complex emails that are a deeper part of your product offering—such as Google Maps’ email with details about your location’s reviews, or Ahrefs report of new and lost keywords and search rankings—will require similarly advanced templates and instrumentation.

Collaboration and Notification Emails

Collaboration and notification emails will similarly require templates paired with more detailed instrumentation. If your app offers collaboration features, you’ll need invitation emails—for the invitee, and for the inviter once the invitation has been accepted (emails that could do double-duty with light tweaks for a referral program, if you offer one). You might need variants of those emails for individual and team accounts. And you’ll need emails for any other parts of collaboration: Edit requests, comments, suggested edits, and the like.

Same for notification emails for follows, likes, mentions, and more—or, perhaps, for estimated arrival dates and tracking info for physical products. Each requires both thinking through the data needs, and the logic of when and where to send the message. If your app supports in-app notifications, default to that ideally, and only email when users aren’t online. It’s worth digging in and building detailed notification logic, Slack-style, to keep from having your customers’ apps and email inbox dinging with notifications at the same time. Or, offer options for a digest email that shows all notifications once a day or so; it’s a bit harder to build, for something that will make your users appreciate the emails and be less likely to automatically delete everything they receive from your company.

Finance Emails

Some emails could be sent on your behalf, from other services, especially for the finance side of your business. Stripe, for example, could email your customers when they pay—with additional email reminders about ending trials, failed payments, subscription renewals, and more.

Or, you could take over them all yourself. If so, first note every email you need to send about billing and payments. End of trial, subscription confirmation, payment receipt or invoice, renewal notification, upgrade or downgrade notices, or shipping updates for physical products.

You also may need usage notices for metered billing or limited features. Dropbox, for example, emails when your storage is almost full, while Twilio emails if your account balance is running low. You’ll need to build internal triggers that fire whenever users hit those thresholds paired with email templates that share details about the metric and what users need to do, and send them via your transactional email service.

One finance-adjacent email you could send via Buttondown automations, if you want, is download reminders. Selling non-online digital products like eBooks and other downloadable items? Whenever a sale comes in, add that user with a tag to Buttondown, with an automation that sends everyone with that tag the download link. Or, if the download needs to be customized per-user, send it in-app like notification emails.

Another finance email perfect for newsletters: Pricing changes. If you’re changing pricing for everyone, you could use Buttondown to update your entire user base about the changes. Or, if you’re only updating specific account types, tag those users and send them a one-off message the same way.

Notices and Reminders

Then come the emails that could come from Buttondown or another newsletter service, if you’d like. Things where you’ll need to write more text and send messages occasionally, as needed. These are worth keeping a full list of all of your users’ email addresses—even though you never should send your standard newsletter to them, unless they’ve opted in.

When your terms of service or privacy policy changes, you’ll need to notify customers. Same for GDPR-type changes; when new regulations affect your business, they may also require updates. Or, if there’s a breaking change—if all users need to update their app or add info to continue using your product, or if there’s a significant outage coming up, or (hopefully not) there’s a security issue, that’s worth telling every customer about, even if they didn’t sign up for your newsletter.

Sometimes there will be notices that only some people need, but could still make sense to send via Buttondown. Issues with integration and 3rd party add-ons should be sent to people who use those items (or, possibly, your whole user base for popular integrations). Same for changes to core features; let the people who use those features know, or just go ahead and email everyone.

And some will be one-off emails that you’ll send once in a blue moon. Holiday messages, sent sparingly. Company milestones and anniversaries, perhaps. Acquisition news, or anything else that means a major change for your users.

These and anything else that’s one-off and text-heavy are perfect for a newsletter. No need to think about templates and sending services. Just keep a spare email list with your entire customer base, and when something comes up, fire up the email list for that one-time email. Include a note in the email’s footer about why you’re emailing and include an option to opt out of even these infrequent emails, just in case. Or, one other option: Keep the list around, and use an automation tool like Zapier to send one-off emails as needed, if you’d rather use something other than your newsletter tool.

Then leave that list dormant until you really need to send an email again. For all the more frequent updates, rely on your core newsletters to stay in touch.

You’ve Got Mail

Buttondown covers your newsletter, and onboarding messages. Things your marketing team will want to send and tweak over time. But don’t forget about the rest of the emails you’ll need to send. Some—like terms of service updates—you can build in Buttondown, if you’d like. Others—password reset emails, for example—are best sent directly from your app.

The good thing is, most of the emails you’ll want to tweak are great to be sent from Buttondown. The ones you need to build-in? Odds are you’ll only change them whenever you refresh your app’s design.

Happy emailing!

Published on

August 23, 2024

Filed under

Written by

Justin Duke

Justin Duke is a software engineer, lover of words, and the creator of Buttondown.

No credit card required. Only pay for what you use. Cancel anytime.