I’ve been working in product for a decade and I have yet to work in a company that had a scalable and effective transactional email management process.
Transactional emails are the emails your users actually want to receive: things like shipping confirmations, email address verification during signup, and password reset emails. Even emails like subscription confirmations are transactional, and they are directly tied to revenue. Yet few companies have a defined strategy for their transactional emails, and fewer still have made that strategy an organizational priority.
As a product leader, I’ve been at many companies where we knew transactional emails had to be a focus but we were unable to make them a priority. They always took a backseat to crucial feature work. This was a mistake. In one case, our subscription renewal emails were a big driver of renewals, generating millions in extra revenue. In another, email was integral to the onboarding process and a key driver of engagement. Although in both cases we knew we had a great opportunity to grow the business with some investment in transactional emails, like so many other product teams, we simply didn’t know where to start.
The following examples, drawn from my own experience, may sound familiar to you.
- One company stored transactional emails in a system that was over 10 years old. The last engineers who had any insight into either the system or the emails it housed had long since left the company. Making changes to those emails always came with crossed fingers, since there were few ways to test them and the risk of breaking things was great. We affectionately referred to this process as a ‘house of cards’.
- Another company granted so many employees access to editing transactional emails, without any review or approval workflow, that we often sent emails with obvious typos or broken links to millions of users, resulting in eroded user trust and hundreds of thousands of dollars in of lost revenue.
When I heard about Dyspatch’s mission, to help Enterprise organizations create and change transactional emails fast, I was impressed by how seamlessly it addressed those very challenges. I immediately empathized with the problems the platform solves for so many organizations, like the ones where I’d previously worked.
Dyspatch’s core functionality is crucial to any company sending emails to users, regardless of industry, market, or strategy, transactional or not, and it would have made a meaningful difference in my ability to meet quarterly objectives in my previous roles. Here are a few of the features that would have been most impactful:.
Permissions and approvals:
Establishing granular access levels and edit permissions ensures the users or teams who need access to a particular email are the only ones who do. Not only that, Dyspatch’s approval workflow requires that both content blocks and assembled templates are assigned for review before they can be published.
These features would have saved me days of email tag, waiting for stakeholders from across the organization — often in different time zones — to sign off on an email.
Previews:
Ensuring that templates have the right assets, are typo-free, and render correctly on multiple devices and email clients is a given. But QA on transactional emails often gets short-changed. Dyspatch makes device previews a mandatory step in the email creation workflow.
An easy way to preview emails would have saved us many reports from our customer success team about customers receiving broken emails. As things were, testing all the device/OS/email app combinations in-house was virtually impossible.
Building and editing emails, with or without code:
Dyspatch’s visual editor allows anyone to create or update email by assembling pre-coded and pre-tested content blocks. And they can do so without touching code. But we also have a sophisticated code editor for power users. These editors scale extremely well to include all types of email communication, although deftly handling the complexity of transactional email is our specialty.
I’m not proficient in HTML — heck, I may never be good enough to compose delightful emails. Having a visual editor would have allowed me and my non-coding peers to create a new template without having to bake it into the engineering org’s quarterly priorities. This would have been the single biggest time-saver — and would have let the engineering teams focus on initiatives that, for them, were higher priorities.
If sending transactional emails isn’t your company’s core competency (which is true more often than not), building something internally, something capable of all of the above, is difficult, time-consuming, and expensive. And more importantly, the cost of having engineering and product teams tasked with email creation and editing (as opposed to the other good stuff that’s in your quarterly OKRs) may feel like a distraction. We recently heard from a large financial company who tried to build their own solution, only to find themselves five months into a project that was still months away from providing any meaningful ROI. (They ended up calling us.)
So when we chat with organizations who tell us that they’re currently managing transactional marketing emails with in-house systems and ad-hoc, undocumented workflows, I always ask them how much faster they think they’d be able to create transactional emails with a platform like Dyspatch. The answer is always the same: much, much faster.
My recommendation? Don’t waste time and resources trying to build it yourself, don’t continue to struggle with your current workflow — try Dyspatch instead.
I’d love to chat with you about how your organization is managing transactional emails, and about how it’s working for you.
