I'm pretty sure I deleted all the segment/audience information within our email authoring environment. This affected the email I was working on as well as any others that had segment or audience targeting.
It was earlier this year. My company had recently switched to a new ESP. Our workflows were different, there were growing pains, bugs, etc, everything you would expect with using a new ESP. We had training on the authoring environment, which did the job on a beginner level, but did not cover the more in-depth features that would help make our workflow more streamlined. One of these features, was using one email (we would call this a container) and target specific sections to create different versions. For example, if one email had different lead stories for over 50 and under 50 audiences, we could build this as one targeted container as opposed to two separate ones.
Cool! I could put in a little more work to make things easier to maintain down the line. I thought of each segment within the authoring tool for a container as a parking spot where audience criteria would be parked. The segment / parking spaces would always be there, but some may be empty. Segments generated a if / else if / else (fallback) logic within the code that is visible on the proofs. To clean up my container (and make the proof easier to follow) I deleted the unused segments so that only the segments / parking spaces I was using was present. No big deal right?
Apparently, segments (parking spaces) were linked in a weird way. Within one container, if you delete a segment (let’s say, segment #8) it deletes segment #8 for every container with an instance of #8! It's like, if a sign said "hey, this parking spot is for email devs only!" in one garage, that same sign would automatically appear in an identical parking garage across the street. In my mind, this makes no damn sense. At the same time, it seems like it was expected behavior for this tool.
We were early in our move to this ESP so there wasn’t a ton of containers to go back and fix, however, some container were linked with a daily mailing so they had to be corrected asap. No external clients/recipients received any broken emails related to my mistake.
Now, if in doubt, I ask someone on my team before doing anything I hadn’t done before. Even if we both shrug and aren’t sure, that’s a start and I can dig around for a solid answer. This alone had saved me from almost accidentally emailing the whole database on a test email (yikes!). I wish we had more in-depth training and use examples like the above to push for that any opportunity I get. This ESP is powerful, which is great, but also, a little dangerous if you are uneducated about how it works.
TL;DR, I accidentally deleted segmented content for our emails without even knowing it.
Similar to what Jeffery mentioned below, we do have a step for sanitizing copy in our workflow. Mostly, it is to deal with the hidden characters. We open text in Text Wrangler, zap gremlins, then have a GREP pattern that searches for those gremlins so that we can remove or swap in the correct HTML entities.
When we worked a lot with accented characters, we also had a GREP pattern that would search for the character (let's say, a o with umlaut "ö") and replace it with it's HTML entity (
In your case, is the concern that the entire email has Sinhala characters that are not rendering properly? Or, that was a one off example?
Erm, unfortunately, I'm kind of at the end of the line so there aren't a lot of opportunities to improve things on a tool or project approach level. Luckily, we're under going some tool/program changes which gives us the opportunity to rethink our process (scrap what we're doing, let's work better and smarter) and revisit our template system since we know what has and has not worked over the past few years. I have learned that bringing actual data to the table and framing things as business risk or "hey, this will drastically increase/decrease turnaround times" is a start.
We send tests via our ESP as well as provide a Memo PDF of the email as it comes into Outlook. That way, they can check the link, etc on the test email, but easily markup the PDF or stamp it approved
For jobs that are not sent out of our ESP, since we're uploading assets to our CMS anyway, we provide the PDF proof and the HTML only.
It seems like the issue you are running into is more client education then anything else. Our clients know that the PDF may look distorted (since it breaks the email into "pages") but the test email they got is the gold standard.
Our naming convention is similar to what others have already mentioned. We work exclusively with in-house clients, so our needs may be similar to yours. For us, we name our templates, datasources/targets and mailings within our ESP with the following naming convention:
CXXXXXXXX = A unique combination of numbers/letter generated by our project management system
ABC = Manual identifier to match the business unit/client/distribution channel the email belongs. We work exclusively with in-house clients but different BUs/DUs have different templates, unsubscribe needs, hedge language, etc.
Description = Project or deliverable name. If its for an external client if may start with the company name, followed by topic and other descriptor.
MMDDYY = Date template, datasources/targets is uploaded into our ESP. For mailings, this would be the mailing date.
As far as naming our HTML files, its usually CXXXXXXXX_ABC.html with an additional indicator if its an automated email or for a particular vendor/system/file format.
Hopefully that's helpful! I'd be curious to see what you end up settling on.