Email Workflows that Work: Webinar Recording + Q&A
Your workflow is an expression of the investment you make in every email—and is itself a predictor of email program success. Most brands spend weeks planning and executing each email they produce. But what’s the secret to building a workflow that enables your team to get higher-quality emails out the door, faster?
Using insights from the largest email industry survey of its kind, Litmus’ third annual State of Email Workflows report takes a detailed look at how email teams tackle every stage of the email creation process—from planning and building to quality assurance and sending.
In this webinar, Litmus Research Director Chad S. White and Community & Product Evangelist Jason Rodriguez dive into the report’s key findings and break down the top 5 opportunities to improve your email workflow. You’ll learn…
- How email teams leverage project management software and email briefs to keep email campaigns on track
- Why collecting feedback and approvals is the largest time drain in the email process—and how you can streamline this step in the workflow
- Why more brands are embracing modular design, and how this design approach can reduce your production time
- And more!
Along the way, we share details into how Litmus has acted on each of these opportunities, making changes to its own email workflow.
Watch the recording above, and download the slides and read the Q&A below:
Get More Insights from LitmusDuring this webinar, we mention upcoming research about How to Improve Email Review Cycles and Email Approvals. It’s now available! Download the free Executive Summary → We also mention upcoming research into the State of Email Service Providers. That research is also available now! |
Q&A
We didn’t have time to get to all of the questions during the live webinar, but we’ve answered them here on our blog. Have any additional questions about email workflows? Please leave them in the comments.
What’s the advantage of splitting email sends across two ESPs?
Chad S. White: There are a few reasons you might want to do this: First, different ESPs are good at different things, have different price structures, and so on. So, one might excel at broadcast and segmented messages, while another might be great for transactional and other automated messages, for instance.
Second, needs might differ across departments or company divisions. For example, if your company has both a B2C and a B2B division, they might use ESPs that specialize in serving those types of businesses.
And third, you want your transactional emails to be sent from a different IP address and domain than you send your marketing emails. Since those are already separated in that way, some brands go a step further and use different ESPs. It’s not necessary, but it’s not uncommon. (For the record: Your corporate emails should also be sent from a different IP address and domain than your marketing and transactional emails.)
How is engagement data from multiple ESPs consolidated to provide actionable insights?
Justine Jordan: This is one of those elusive “it depends!” answers. As Chad pointed out above, the use cases for multiple ESPs can vary widely from brand to brand. In Litmus’ use case, our transactional provider sends emails specific to Litmus software and our platform (i.e., password reset emails, new user notifications, etc.) while our marketing provider sends newsletters, webinar invitations, onboarding emails, new product announcements, upsell campaigns, and the like.
You could almost consider the transactional platform to be customer-only emails, and our marketing provider to be a mix of prospects and customers. For those reasons (and many more outside the scope of this blog post), it may not be necessary to consolidate engagement data such as opens and clicks across multiple ESPs for activities like frequency management or segmentation.
For brands that share customer data across multiple ESPs, data warehousing solutions, business intelligence software, APIs, and integrations can start to help you build a 360-degree view of your customers.
How does Litmus handle version control for emails that may have a long shelf and undergo regular updates?
Jason Rodriguez: Since we use Litmus Builder for all of our email campaigns, we have built-in version control. Builder keeps a complete history of changes made to an email and allows users to quickly view those changes—including who made them—and roll back to a previous state if needed.
Litmus Builder’s Timeline version history in action.
For viewing historical sends, we just use our ESP’s tools, which allow us to see past sends and dig in when necessary. We can always look up old sends and view the email creative, envelope information, lists, and performance.
Do you think it’s important for developers to participate in creating and approving the email brief? Or should they just build the email based on a Photoshop file?
Chad: In general, it’s a good policy to have a developer involved—especially if you’re creating an interactive email or doing anything that you haven’t done many times before. Simply put, while email designers may create a single Photoshop file, email developers translate that into many versions of that email because of the complexities of email rendering.
That email is going to look different on mobile than on desktop; look different when images are enabled then when blocked; potentially look different when web fonts are supported; potentially look different when interactivity and HTML5 video is supported; and on and on.
The age of pixel-perfect fidelity across email clients is long gone. Now the goal is to create platform-perfect emails that play up to the capabilities of individual email clients and use fall-backs to create acceptable experiences in less sophisticated email clients. Having an email developer involved in creating email briefs can ensure that such issues are taken into consideration early on rather than when they crop up during the review process.
Does Litmus’ email request form automatically create and populate the Google Doc with what was entered on that form?
Jason: Not yet! We still have to do a little manual work getting that information into Google Docs. The Google form does automatically populate the card within Asana, but once it gets to the “In Progress” stage, we will copy the necessary information over to our email brief in Google Docs and expand on it there.
Besides Google Forms, what other tools would you recommend to make a user-friendly email brief for more traditional companies (who aren’t as tech-savvy)?0
Chad: The format doesn’t really matter, just so long as everyone who needs access to it can get to it quickly. That might be a Google Doc template that folks fill out. It could also be a Word doc on a server. It doesn’t have to be fancy, just so long as it’s easily accessible and editable.
One of the main benefits to a standardized request form is encouraging the requestor to think holistically about the goals, audience, and other key attributes of the send. Think of it as a conversation starter, especially if your team is less tech-savvy.
Does using snippets and global modules ensure that custom fonts “stick” without having to be inline?
Justine: Snippets and partials don’t inherently overcome rendering issues, but they can help you reduce errors. For instance, you can add your font coding to all of your snippets and partials that include copy. That ensures you never forget to add it and always code it correctly. You can also use Builder to automatically move CSS styles inline.
If we use a different vendor for building emails, are the terms “snippets” and “partials” unique to Litmus or something that’s gaining familiarity industry-wide?
Jason: Although the terms “snippets” and “partials” are used within Litmus Builder, they are fairly standardized across both the web and email industries. Both snippets and partials refer to specific features within Litmus Builder, which you can learn more about here. But the idea that snippets are reusable code blocks that can be updated on a per-use basis and partials are global code blocks that are pulled into a document dynamically is well understood in the design and development crowds.
Some ESPs, frameworks, or tools might have their own names for snippets and partials, but the underlying functionality is very similar. Just read your tool’s documentation to learn about their terminology and you should be fine.
Can you use Litmus Proof with any ESP? What type of Litmus subscription is needed to access Proof?
Justine: Yes! You can use Proof (and all Litmus products) with any ESP. We like to call ourselves ESP-agnostic because Litmus works where you do. To get started with Proof, you can send a test email from your ESP to an email address inside your Litmus account, or you can upload HTML. Proof is currently available on Litmus Enterprise plans. We may release a version of Proof to other plans later this year, though timing and details are to be determined. Get in touch with our team for details!
Does Proof allow clients to view and suggest edits, or is Proof more beneficial for internal teams?
Proof works equally well with clients and with internal teams. In an agency setting, you can use Litmus subaccounts to create private groups for each client, add your clients as Reviewers, and use Proof to allow stakeholders to collaborate, mark edits, make suggestions, and resolve comments. The process works similarly for internal teams. See how Litmus uses Proof (and get some of the story behind why we built Proof) in this video.
How can I learn more about using partials?
Jason: We have a few resources for learning more about using both snippets and partials in Litmus Builder. Check out the following to level up your email workflow:
- Automate Your Email Builds in Two Ways: Snippets vs. Partials
- Create and Manage Dynamic Code Blocks Easily with Partials
- 7 Ways to Add Automation into Your Email Workflow
- Best Practices for Creating HTML Email Templates in Builder
And again: If you’re not using Litmus Builder, hunt around in your preferred tool’s documentation to learn more about how they implement snippets and partials. Both are vital components in an efficient email development workflow.