Jay Oram, head of dev at ActionRocket, on intra-agency collaboration on email

Probably when I started, interactivity was in its niche, so there weren't many people doing it at all. It was all based on personalization and segmentation. Obviously, they're the basics and we try to get people to do those first. So segment, send it at the right time, the right message, all that kind of stuff, and then once you've built up all of that stuff, the interactivity is like the icing on the cake. 

Occasionally you get an interactive email and it just builds your engagement a little bit more and gets people to click, that kind of thing. But actual interactive email has probably only been around—well, it's been around for ages since Mark Robbins did his Checkbox Hacks six years ago, possibly even more—but actually being in the mind of every email marketer has probably only been three or four years.

Is that part of why ActionRocket moved from just, ‘we'll write up the email, you send it,’ to this more full service option, where you can deliver more value by doing some of the more complex stuff?

Yeah, we found that we were pitching strategy, which was like, ‘you can do more, you can do this, you can do that.’ And the pushback was, ‘well, our team just can't do that.’ So before we were delivering simpler templates and they were editing them and creating their own work. 

And now we're building everything, so integrating public APIs and interactive and web and social and bringing it all into email, adding interactivity. Most email teams don't have, well, they don't have the time or the team that can help them do that. We just tend to be an extension of their team when they need that special, I don't know, one-off email, Christmas, Black Friday, that kind of thing. They just need something to help them a bit more.

How does Parcel fit in? How did you guys start using Parcel and what is the key job to be done that it solves?

I started using Parcel when it was in beta with Avi… I don't even know how long ago. It was two and a half years when he first started probably, so not that long ago. The main thing is that we were still using Dreamweaver, and a lot of the reasons we were using Dreamweaver weren’t good reasons, but it was just that only Dreamweaver had certain things. You had a live preview of the design next to it, so you could code and see the live preview. 

As all of email is static, HTML, and CSS, there was no need to attach to servers or anything like that, it could just load straight there. So Dreamweaver did that really well. We were still using—well, we still are using tables—and Dreamweaver had a way of showing all of those tables in a really neat way on the screen, which no other code editor had the ability to do.

That was one of the first things that Avi also pointed out. There's the option to do the grid and it points out all the tables and stuff, so that's the only other code editor that does that at the moment. Also, being able to actually click on something in a live preview and it highlights it in the code, that's another thing that Dreamweaver did. 

A lot of email marketers and the coders that we have at ActionRocket, they're purely email coders, so maybe they're not used to any other way of coding, they're just visually seeing it, click on it, they know where it is, they can edit it, that kind of thing. That's why we went to Parcel. When Avi started it, he was asking loads of questions of what do you need, what doesn't Dreamweaver do? That was where it started, basically. 

So everything that we needed and came up with, he had an idea for and fixed it and added it in, and then Parcel became better than Dreamweaver. That's why we switched. We switched first when it was the free beta version, I was probably the only one on it at ActionRocket. 

Then, when we could share code, share files, share previews, all that kind of stuff, that was when it became a tool that we could actually use in the team. Whereas before I was doing all the coding in Parcel, then saving it down onto Dreamweaver probably, and sharing it the same way we always had done. So that's helped.

It's been hard for me to figure out if there's even a comparable alternative, or another tool that does what Parcel does. Do you see that out there? Is there any other tool like this doing what Parcel does?

You can make your own VS Code. You can kind of cobble together to make it do some of the stuff Parcel does. So you can get the live preview, you can kind of get the prettier and the accessibility checker and things like that, but it doesn't quite have everything. And it obviously doesn't have the live previews and stuff. 

And then the other stuff, Litmus Builder does have a lot of the features, but that’s bundled in with Litmus, and it's quite a high cost to get that implemented. I think to have it just as a code editor would be a really high cost. Maybe if you were a Litmus customer, you would use Litmus Builder instead of paying extra for Parcel, but even Litmus Builder doesn't have the options that Parcel does. 

With VS Code, you would just add in extensions upon extensions upon extensions to try and get what you needed. And not all of them are there. The live click to go to your code, I don't think is available. And definitely the table highlighting isn't there.

Did you guys ever look at Litmus at the agency?

Yes. Litmus was one of the only email preview applications for a long time that was really good. We did use them when I first started, but their Builder was not a major part of their product at the time. So you just pasted your code in and then you could do little changes, but it wasn't very good, and it costs too much for us, the amount of preview and testing that we do to use Litmus by itself. 

So we then moved to Email on Acid, which gives unlimited previews for the price per month, but the editor in there also doesn't really match, well, it doesn't do anything that Parcel does really. The best of both worlds for us was to use Parcel and then use the live previews, which is basically Email on Acid on the back end. We kind of got it in with Parcel so it works.

How many folks at ActionRocket are using Parcel on a regular basis?

So there's three full-time coders, they're always in it. Then we've got four designers who code occasionally, and they don’t have a business account, just pro. They don't quite have all the features, but they're in there. I'm using that. Then I think the new admin roles, we've got a couple of people that can go in and see stuff, but they can't edit things. Probably ten I would say. 

How many different ESPs do you see? Is there a main one or a main couple that you see? What's your experience been there?

Predominantly, we see clients in Braze and Salesforce, that's probably enterprise level and big organizations. The next one is probably Klaviyo and that kind of level of ESP, GetResponse, that kind of thing. 

But yeah, we do work, mainly we're in Braze and Salesforce, because that must be how big the organizations are that we work with. But we do actually work in all of them. The whole team is certified for HubSpot, MailChimp, all of them. We’ve worked in all of them, any one that comes along.

What would the benefit be to have the vertical integration of code editor and Parcel and ESP that you're using per customer?

The only thing would be if there was a way to get the code straight into the ESP without the client having to do anything. There's a couple of other tools we use like Taxi For Email or Alpaca or Stripo, those drag and drop editors that we've set up for clients. 

They have connectors where you can just do one click and it goes from the editor straight into the ESP, and then they don't have to copy and paste it or worry about it going to the right place. If that kind of integration was with Parcel, then if you could just one click and it goes to Salesforce, that would save them having to download it or do anything like that. Also personalization, although that's difficult to work both ways. 

But if there's data in an ESP and we want to pull it into Parcel, at the moment we just use placeholders or we just stick the ESP code in with some defaults or something and do that. But if it was live, we could see it a little bit better.

Is there any kind of difference today between ESPs on your end in terms of what you're able to do for the customer, the kinds of data you're able to integrate into the email, or is it pretty much the same across the board?

It's pretty much the same everywhere. It's just the process of getting the data in there is more difficult in some than others, or things like fetching stuff, using an API, something like that. Some of them are easier to set up than others and some just don't have the option to do that, to have an endpoint with some data on it that you can fetch or something.

Are there other features that you'd like to see in Parcel, stuff that you think is missing besides VS Code extension?

Being able to see the assets in the builder is sometimes harder than you would think. When you're adding an image, being able to search the library that you have already for the image, or within the builder having a preview of the image without having to leave the code to go and find it, that kind of thing. Or, the actual image dimensions or information, having that live, I think I mentioned that before.That's it really, there's not much else that we want.

You mentioned you guys will sometimes give the customer a drag and drop builder. Was that so they can make edits to the template that you guys have coded on their end, even if it's a non-technical marketer person?

Taxi For Email was our sister company for a while before it got acquired. One of the biggest use cases is we work with Nespresso, so they're an international coffee company with 64 languages. They needed the ability for us to create a template, create campaigns, but then give it to the 64 markets to be able to make the language changes. But then also, okay, some of them didn't have a certain coffee, so they'd have to swap images, different links to different stores, that kind of thing. That's generally what the drag and drop was used for. We create a big email design system, componentize it, and place it inside Taxi For Email or one of the other ones that are out there, and then they don't have to use us anymore to make their emails unless they want something special.

Are there other key products in your development stack or in this email developer use case that come to mind? Besides, obviously, the ESP the customer has prompted you to use and Parcel.

We use TinyPNG and image compressors to compress images, so they're somewhere in there. We use Figma normally for the designs, so we occasionally use that in the stack to create a design, then grab some code from there. Image compression, those kinds of things. And then just hosting files. ActionRocket has its own server, we can put a JSON file or any code basically up on a server so that we can access it. Something like Spacer GIFs we might use in multiple campaigns or something like that. That's it really for email. That's our whole stack.

Do you interact with anyone on the client-side using Parcel?

No, we have a couple of clients who touch the code occasionally, and we've recommended them to use Parcel instead of Dreamweaver. They just use a free account, paste it in, do some changes, then copy and paste it out. They don't really use it like a development tool.

Can you talk about the “re-purposing” of Dreamweaver for email development?

It was purely the visual aspect, just because VS Code, Atom, well, all of them basically, it’s just code. So you'd need an extension to see the live, or you'd have to hook it up to the browser so you could see the file in the browser. I think that was literally it, I don't think there was any other reason. Originally it was a standalone product, so you could just buy it like a CD, but then now it is part of the Creative Cloud subscription. 

Unfortunately, we still have a full Adobe suite because we have to use Photoshop for some clients. The subscription, whether you have just Photoshop or Photoshop and Dreamweaver and Illustrator is all the same price. The whole company still has a full Adobe account, and Dreamweaver is still there if people want to use it. A lot of our designers make assets from scratch, so that's why they're using Photoshop. They still create email designs there, but the majority are moving over—90% are in Figma now.

Can you say more about this role of the email developer? Are the folks you hire for this role already experienced in email development, or is it more the kind of thing where someone with some experience in lifecycle marketing is pretty much picking it up on the job?

I actually hired two people in the last year, the two coders from the team. One of them previously had three or four years of experience coding emails, and that's why we hired them so they could start. But then the other one was straight out of a web developer bootcamp, they hadn't worked specifically in email, but they obviously knew basic HTML and CSS that came from that course. That meant that we could train them to do that. 

I was a marketer before, so before I was a coder full-time, I started off in social media and then was head of digital marketing for a load of e-commerce and global companies. Then, I just got bored of the marketing stuff and wanted to code, so that's why I swapped over. One of the things we’re noticing is that the two coders on our team that are just coders don't grasp the marketing side of email.

They just do what's in front of them, so you get a design, you just code the design the best you can, so they don't have as much input on the strategy or the ideas or the data or all that stuff that goes around the code, they haven't got as much of an idea about. We've noticed that. In terms of roles in general, when we are talking to companies, they all tend to have one person who knows email code, but they also tend to be the same person that deals with all of the CRM stuff. 

So in that messages push everything, the email code part is a very small part of their job, they know enough that they can change stuff, but often, they don't know enough that they could create a whole template by themselves.

So they come to us to get a template and then they can work with that. A lot of our time is spent consulting with people that know just enough, but maybe they don't know about dark mode or they don't know about the latest Gmail background image issue or whatever. We help internal teams that just need a bit more training up. Bigger companies do have one dedicated email coder who will purely work on emails. 

We worked with Pokemon to create their new template and they've got one in-house coder who could’ve quite easily made the template himself, but time-wise, he spent all his time doing campaigns. So he outsourced, needed us to build the template, so that he could focus on the one-off campaigns that were going out every day or every week.

It’s the same with BBC, they've got a team of three or four who create the emails that go out every day, and they have a knowledge of Salesforce and a knowledge of the code, but not enough that they could completely do an email from scratch. Or, they could do a basic email from scratch, but they couldn't do an interactive email. A lot of code roles seem to be junior or CRM executives or something like that. They have the knowledge of HTML and CSS to change stuff, but not necessarily the knowledge to pull it off completely from start to finish. Very few companies are employing an email coder that could start from scratch and do absolutely everything.

I do a lot of courses to teach people how to code for emails, and there isn't a massive uptake, and there aren't that many courses out there. That makes me think that there isn't a massive market for the ‘email developer’ role in general. Obviously, I'm UK-based, but we do one a month, which gets about four to six people, that's not a lot. That's 40 to 60 people a year. Whereas in the US there's been a couple of people inquire about it, but not that much. 

For Litmus, the Litmus event, the workshops, they're only looking for a maximum of 20 to 30 people, and I would've thought that would be a major draw for people to do workshops. If they needed to learn it, then that would be a really easy place to do it. I’m also seeing lots of other email courses that have one or two people or only run every three or four months. I don't feel there's a massive market trying to learn it, but maybe there is a market for people that need to know just a little bit. They're not interested in a full course, but they need to learn a little bit, so maybe Parcel could help that way.

Anything else that comes to mind about any of this, about Parcel that you think would be interesting or that we didn't get the chance to talk about?

Well, one thing is all of the community stuff that Parcel does is definitely standing out. More people are noticing it and it’s bringing more people towards using Parcel. Whereas oddly, when Litmus or Email on Acid do it, they don't quite get the same reception. I don't know why. I don't know if it's just having the team of Mark, Avi, and Naomi, whether they've just got the reputation that those people are nice or something and they want to go to their events, whereas Litmus or Email on Acid is more corporate or something, not sure.

I'd spoken at Email Camp for Email on Acid and the amount of people that went to that was very small, and weirdly, the same people that are always there, the same kind of 10 or 20 people that seemed to go to every event. Whereas going to Parcel Unpacked, all of a sudden there were loads of new people there and lots more engagement that I hadn't seen at Litmus or Email on Acid events. I don't know why, but whatever they’re doing, they’re doing it right. But I don't know what that is.

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.