Sean Kennedy, senior marketing ops analyst at Zapier, on his email development workflow

Import from ESP is a big one. We use Iterable and HubSpot, and HubSpot's a bit of a weird one because of their editor. What we’re generally doing is building in HubSpot, but then for posterity and visibility of what exists in our world, we actually import it to HubSpot, so we've got the HTML as a reference point within Parcel, just so that we can take from their custom editor. That’s something we use. 

Versioning is probably one of the bigger upgrade features for sure. There's a lot included in the basic plan, components are probably one of the biggest ones. Approvals and feedback is another big one—feedback functionality is huge.

Can you talk about the workflow around how technical and non-technical folks at Zapier interact within Parcel?

Feedback has been one of the biggest shiny little features that I've been leaning on with Parcel, because it ultimately allowed us to deprecate our need for Litmus and simplify our tech stack and simplify our processes. 

Because the technical team can build the emails, and what we've historically done is they would build the emails and export or send themselves a proof. We would use Litmus Scope to capture a version of the email, start the Slack thread, put that into the Slack thread, and then that Slack thread would turn into a bunch of back and forth of all the things that need to be changed. Then, as you can imagine when you've got emails with multiple people providing feedback, it gets really, really noisy. Through feedback and Parcel, it's really allowed us to streamline our QA and feedback, because now the team can just provide a link.

Anybody—as many people as they want—can now annotate directly what piece they're talking about. Those comments can be threaded so that we can talk about a specific thing within that feedback view, and it makes it a lot easier for our technical team, the email marketing team, to then open up that feedback and go through each point as they're editing that thing. They can make sure that they're getting all the updates for that header, and then all the updates for that image, and all the updates for the content, instead of having to sift through and comb through the thread to make sure they got all the checkboxes that they needed. So it really makes that easier for the team, not even just in productivity, but just mental bandwidth of making sure things are moving quickly and that nothing has been dropped.

Then is there a dynamic on the other end, as I understand it, you basically have to create email, you build emails in Parcel, but to get it into your ESP, so for you HubSpot, Iterable, you'd have to copy and paste it? Is that basically what the workflow looks like on that end?

Yep. We do the export from the MJML that we coded into Parcel into the transformers feature, which has been a super handy feature for compressing our CSS files. They’re huge for all styles, but we don't use all the styles, so it removes unused CSS and really compresses and optimizes our exports. That’s been a big one for us. Then we can take that code, open up Iterable, for example, drop it in, and then they're good to go.

Is there any dynamic around folks editing the email using HubSpot or Iterable drag and drop editor from that point on, or is it pretty much good to go once it's imported?

No, we do all our building. We've got a couple exceptions where we'll use drag and drop editors, but probably 99% of our emails are using our MJML style guides and everything, so we keep everything consistent. That way the email team builds it and then they'll just import the code. If we need to do an edit, they will edit it in Parcel, re-export and then just overwrite the existing code.

If you had a wishlist or if you could control the Parcel roadmap, what features would you want to see in the platform?

I’ve got a wishlist somewhere. Actually, Avi started it and I've been just adding to it. Some of the functionality that I've been asking for is around components and making it a little bit more user friendly. For example, if I hover over a component I can put in the description, but it's just one text element. I'd love to be able to make it easier to manually indicate what the parameters are that this will accept, what the description of this is, and just make it a little bit easier for somebody who is not super familiar with our EDS trying to create an email. If they could put this in and then see on a hover more clearly what options are that exist, that is a little bit tricky.

That's for new folks who come in maybe, who do marketing and are not super savvy with HTML and CSS to be able to autonomously create a new email?

Yeah, that kind of thing. Even for our email team, I've been managing our email design system and I will build these components, but for them to get adoption, I have to really train them on how it works. For some of them, they're good at HTML, but once you start throwing in JSON, which essentially these are, it's a whole other language and a whole other concept. It's not always clear, unless they go into the component themselves to see what fields it will accept or what values it will accept. So I need to really define in the description of that component—what values it will accept, what parameters are available—and it just becomes this giant block of a text blog that they then need to read through.

I'd love to be able to make that a lot more intuitive. And the same thing with more dynamic or more complex components. If I’m creating a component that can do lists, I have to create an array within the component and you're getting into JSON styling of code, but getting our email team to do that is a lift and I feel like there's probably solutions through the product UI or through the way that the text input of a component could be more user-friendly, for those not familiar with JSON and that advanced language.

The team's fine with code, but just for a UI, I could see a component becoming almost with dropdown stuff, the different parameters of whether it's new. I'm speculating ideas, but I could see ways where it's not just a complete open code text. Components are really powerful, but they can become very technical when you start utilizing the power of them, for those who are not super code experts. In my list of other things around components—this is again just more around clarity—but the language, uppercase, lowercase in component logic, there does seem to be some confusion around that, so just to make things a little bit clearer as to what names can be.

Everything almost feels like it needs to be lowercase, but when you code in languages, it'd be great to use camel case and stuff, so that you can better indicate for the team, this is padding capital T top or whatnot, rather than just padding tops or other custom needs. Support for CSS files, not huge, but I create CSS files that we then can import to other platforms like HubSpot, and being able to edit those and this starts turning Parcel into a little bit more of a general code editor, but support for CSS would be nice.

Getting into more specific features that I would've on my wishlist is around organization and file management. So the search, I feel, is lacking. It's a little simple. Being able to search files through just additional criteria, and having it being able to surface them better and go through the list. Compared to Visual Studio Code, their search function's pretty handy, pretty robust, and the way that it presents the results that you can then click on and go through, there’s something to be desired there in Parcel around the search functionality. I'll use it for ‘find all emails with a certain keyword,’ like we're looking for pricing, so dollar sign, or regular expression searches, finding all your emails that can contain this regular expression in it would be helpful. Being able to move or delete files in bulk. So, being able to select multiple files at the same time and move them into a folder versus one at a time or have a checkbox to be able to delete multiple files at the same time or something like that.

My biggest one has been adding personalization, but I know the team's been working on that already, so I think that's done with additional handlebars and liquid logic and all that stuff, but I think they've been handling that. But that's been one of the other big ones. Then the other one—which I don't know how they can do it—what I'm calling it is a persistent undo history. Because it lives in the browser, if you open up a file and edit it, but then you toggle to one of your other files because you're trying to reference it, or want to copy something from that, then you go back to the previous file that you were just at.

When you come back, you cannot undo anything, that command Z shortcut does not work. As soon as you change to a different file, any previous edits that you had been making on that other file are lost. That has bitten me a couple times where I'm like ‘oh crap, now I have to manually remember or go back or just rewrite.’ It's just extra effort that I don't think needs to be there. But that's also just in the nature of the product being in a browser.

I'd love to talk about that a little more. Do you personalize emails further using features in Iterable or HubSpot to make up for what's not in Parcel?

The reason personalization is important is it comes back to that feedback functionality. We want to be able to use Parcel, end-to-end, from development all the way through to review, and then the final step to launch is just us copying that code and putting it into, say, Iterable, for example. We can test personalization in Iterable, but because Parcel has the ‘send test’ or ‘send proof’ functionality as well—or even when we're creating feedback views—we want to be able to show our stakeholders what this email is going to look like in the wild, and not with placeholder, handlebars, pieces or giant blocks of logic, for say, the header or the footer or blocks in between.

Personalization becomes a convenience where when we send this, it's like, ‘oh, and don't worry about this, this will render when we actually send it.’ It actually makes it easier for us to show them what it will look like, and especially when we have cases where there may be three versions of an email, depending on a user's data values that may render. We can create a feedback version for situation A, situation B, situation C, and manually set the data value so that when it does create those renders in Parcel, it shows our stakeholders exactly what that's going to look like.

That minimizes confusion for teams, makes things super clear, reduces the risk of missed gaps because what they see is what they're going to get, not ‘here's what we did, take our word for it, it will render properly’ type thing. That's the importance of it and we use a lot of personalization in our emails.

Can you delineate what is done in Iterable and what's done in HubSpot, is there any overlap for how you use them?

There is a little bit of overlap. Mostly Iterable is our primary marketing platform, so any of our onboarding marketing messages pretty much go out of Iterable. HubSpot is, for the most part, our lead generation and sales tool.

If we have emails regarding how we engage with leads, or nurtures for leads, or we've also been using it for some of our more upmarket marketing, so enterprise-y type stuff where we have inserted salespeople working those conversions to upsell people, that's where those come into play. There’s some overlap on some campaigns, in some areas, but for the most part it’s sales is HubSpot—anything sales-related, lead generation related—and then anything that is just our users, our everyday users is in Iterable.

It sounds like most of what's done in Parcel ends up in Iterable as marketing content. Is there any stuff that's happening in Parcel that ends up in HubSpot as sales emails?

Not a ton. A lot of our sales emails could be like plain text, they're mimicked plain text emails that we built. So they'll take a template, code it, and then usually in HubSpot they'll just build it using their editor, because in HubSpot we create our own custom components for them based off of our EDS.

Then, they can just drag them out—it's not a true drag and drop, they've got three different editors, it's very confusing and they've got their own limitations—but yeah, they build it in HubSpot for the most part. But there are rare instances where they will take code from Parcel and just drop or code it and email right into HubSpot and send that.

You mentioned making Parcel more like a full IDE, and it's something that's come up with other folks, where it replaces VS Code so completely that it could sort of be your only IDE that you've used.Do you still use VS Code or something comparable for anything? Or do you basically manage all of your development work in Parcel?

No, I do use VS Code still, specifically for when I'm working with data and JSON formats. So like API calls, if I'm working with Mailgun, I'll export. If I'm troubleshooting an email, let's grab the payload, what was sent to them and I'll drop it into VS Code to analyze it, parse it so I can see what was actually sent and use that. The big code languages are what I would use VS Code for, like CSS files because Parcel doesn't support them. Then all of my workaround for Parcels, I make an HTML file with just a really big CSS style block and I just do it that way. But JSON is a big one for data, API calls, and just analyzing and working through that.

As someone who works at a bigger company on email tooling with a larger team, why is it so important to have an email design system, and to have components, and have this software engineering workflow around email marketing? Especially since that’s somewhat rarer at smaller companies.

Ultimately it just comes down to efficiency, reliability and consistency. Those are probably the three adjectives I would use. Efficiency, our team has a request process like any other business does, and we are often the hub to many product teams and other teams that whenever they want to send out an email, it's got to go through them. So the faster they can get a request, triage it, get it built, get it reviewed and QA-ed and sent, the faster they're going to support the company as a whole because other team's objectives are able to ship faster and not get bogged down in an email team's backlog.

Also, being an automation company, we automate as much as possible for that exact reason, so efficiency becomes a big one. The team does a lot of context switching when they get these requests, so having an EDS minimizes the need for them to really need to think about what they’re building or why are they building this? They can take the request, understand the layout that it needs to be, and then just lean on the EDS to say ‘okay, I need this component, I need this component stack. Oh, they want a different order, I just moved those around.’ They don't have to worry about getting into the nitty-gritty of the code.

It also makes the code of the files super, super small, not in file size, but in just lines of code. Since moving to MJML, I think we’ve had emails going from thousands of lines of code to a few hundred, if not shorter in some cases. Then once we start fully rolling out components, I could see us sending massive emails within a hundred lines of code. So that adds to efficiency because as the team needs to debug things, there's less lines that they need to analyze to figure out where the issue is coming from or what they need to fix.

Not to mention centralizing. Having the components, if something goes wrong, as an operations person or whoever is managing it, I can go in and edit the component and it edits it everywhere, it's centralized. All those emails are referencing that component versus hard-coded code that is then set in every single email. We've done this a few times. We did a rebrand last year where we had to go through every single email template and update over 200 templates like Indiana Jones style, as they're live, quick swaps. That can kill an entire month for a team, which means nothing new is going out, no new productivity is happening. It's literally just foundational work. Now, we're all built where if we need to do switches like that, update logos, update colors, it’s one line in one file that all the files and all the emails reference and it's done. So that's a big one.

The other side of it, then, is more around consistency. The bigger the team—you can talk about your brand guidelines until you're blue in the face—when it comes down to it, divergence will happen, and often does creep in. It starts like ‘oh, an extra eight pixels or ten pixels of padding here,’ and then it's this and then it's that. That compounding over months can lead to one email marketer's email looking very different from a different one, for the exact same email, just due to little nuances. So by leaning on our components and our email design system, it ensures that no matter who is building an email, I can step back as the brand ambassador for our email team, so I know and trust that anything that's going out is going to follow our guidelines. As long as they're using our components, our styles, our set classes, it leaves that room for divergence to be really, really small.

What would you use if Parcel went away tomorrow?

That’s a good question. I think the immediate needs for us—there's nice-to-haves through the components, those are absolutely need-to-haves—but if Parcel went away, probably the very first thing that I'd be sourcing out is how do we manage version control of files. So that if something goes sideways, how do we roll it back, or things like that. Litmus would definitely be a part of the solutions that we would be looking at. Prior to going to Parcel we were also looking at whether we could just stand up our own GitLab repository, and teach the team how to do Git, and do pull and push requests and manage it that way. But then it doesn't solve all the issues, things like feedback, QA, and that's probably when we’d start looking at Litmus again and tooling that way.

We've also looked at other add-ons, things like Taxi for Email or there's a couple others that are like that. They’re low code or no code editors that we can build our own components or our branding and EDS into, but then there's no code to build the emails. We'd probably look at something like that, and so there's other options, but for flexibility, Parcel definitely—as an email teams end-to-end workflow, from taking the request all the way through and even behind the scenes of managing—it does check with a lot of the boxes. So it would be missed.

How do you compare Taxi for Email and Parcel?

I'd probably rate it as the no-code version of Parcel. You can define components and put all the snippets in and everything, and then whenever someone wants to build, it's like drag and drop. It's like the drag and drop editor version of it, and then you export it to your ESP and it does what it needs to do. We explored it, and we were really considering bringing that in, especially for some of our more product teams to be able to self-serve for product specific emails. But keeping control of branding is, again, for reliability and consistency.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.