QUESTION: what issues could we run into if...
Should we have any concerns in doing this?
Solved! Go to Solution.
Still, it may be worth using Marketo if you're already comfortable with the editor and happy with your rendered emails.
Just wanted to add that we did this A LOT at past companies. For pretty much any Marketo asset program - whitepaper download or webinar invitation - that we built using program tokens and program cloning, we also created one version of the email to hand over to vendors. It was actually part of our standard program cloning process, so that version of the email was already done with no additional effort. The end result is an HTML document that - of course - you have to build without anything that can't work outside of Marketo. View-as-a-webpage e.g. or the above mentioned personalization. Also, our 3rd-party template email didn't include company headers and footers as they were not supposed to be used in that other environment.
But apart from that: Solid approach IMO.
You can certainly do that.
Some things to keep in mind:
To clarify, when you say another system, do you mean another Marketo instance or a different ESP/MAP altogether? If it's the latter, then the Marketo-specific syntax/classes that are supported by Marketo's email template builder would likely not work/render.
Also, as Micheal said, if you're importing the HTML to another Marketo instance, any source instance-specific personalization(dynamic content)/custom tokens would not work unless you create the same setup in the target instance.
Furthermore, instead of importing the email, I'd suggest you create the exact same email template in the target instance, and create an email from it. You can copy and paste the editable content from the source system into the email asset. This may consume a bit more time, but this would be more scalable and manageable over time. FWIW, you'd save a ton of time in updating emails later, if need be. You'd just need to update the email template and re-approve the emails vs. update every single email's HTML (which will certainly take more time).
...any source instance sepecific personalization(dynamic content)/custom tokens would not work unless you create the same setup in the target instance.
Also very unlikely, unless it's also Marketo, that the target system uses the same variable syntax + field names as Marketo, making personalization impossible to test (if it's supported at all).
Still, it may be worth using Marketo if you're already comfortable with the editor and happy with your rendered emails.
Still, it may be worth using Marketo if you're already comfortable with the editor and happy with your rendered emails.
Just wanted to add that we did this A LOT at past companies. For pretty much any Marketo asset program - whitepaper download or webinar invitation - that we built using program tokens and program cloning, we also created one version of the email to hand over to vendors. It was actually part of our standard program cloning process, so that version of the email was already done with no additional effort. The end result is an HTML document that - of course - you have to build without anything that can't work outside of Marketo. View-as-a-webpage e.g. or the above mentioned personalization. Also, our 3rd-party template email didn't include company headers and footers as they were not supposed to be used in that other environment.
But apart from that: Solid approach IMO.
Absolutely, Sandy! The latter part of my response was more so related to if the target system is another Marketo instance itself. 🙂