For as long as I can remember the standard mail merge process has always been one dimensional in that you are doing little more than poking holes in your document and filling them in with a flat data source of some sort. Which is wonderful for non-technical people looking to send out a quick email to their list and fill in a couple fields to make the email more personal. But while easy for non-technical people to use, doesn’t usually meet the needs of more complex email that needs to be sent out, like invoices which need modern programming features such as loops and conditional statements.
The other type of email templates that my readers are probably more familiar with is the ones their applications send, the ones that contains those loops and conditional statements that create 99% of the transaction email that we all receive each day. However this type of email, while very powerful, because it has all the benefits of a modern programming language, usually falls short when a non-technical marketing-type wants to get in and change some wording or update the design. This usually gets done, but at a much slower pace than it should happen, because meetings, development, tests, and pushes to production have to happen, when a simple word needs to be changed. So that is not optimal for non-technical types who simply want to do their jobs and not be involved in the development process more than they have to.
Who cares about what?
The technical side of the email templating process (i.e. the developers), if you break it down to the bare essentials, only care about the data that needs to be pulled together to merge in to the email that needs to be sent out for each individual customer.
The non-technical side of the email templating process (i.e. the marketers) only care about the message that is being delivered to the customers, they don’t necessarily care about the data that is being merged in, because they are treating the message as a generic template for talking to all their customers.
What can be done?
In a optimal world the developers would compile the data they need to merge in to the email template, not caring anything about design, formatting, or output, and then pass it off to the marketers to put in their optimal format for talking to their customers, because they would control the formatting and design. However as I eluded to in the beginning of this post, most transactional email today, requires a modern programming language that supports loops and conditional statements. So what can be done? Both sides seem to need each other, developers for the data, marketers for the design, and somewhere in between to turn the whole thing in to a production quality transactional email.
Well it is time we take a step forward and bring this problem to some Web 2.0 thinking. If developers and designers can collaborate over a web page and both work on it simultaneously and produce work in a fraction of the time it took 10 years ago, we should be able to bring that same thinking to email templating.
Stay tuned!!