The lock-in problem of email newsletter management

The lock-in problem of email newsletter management

Summary: Email-based mailing lists may be here to stay, but so are the systems they're mailing from. This is lock-in and you're pretty much stuck with what you were doing back in 2005.

SHARE:
email-inbox-detail

I recently read an article on Wired.com entitled, Why E-Mail Newsletters Won't Die. Like most Wired pieces, it was well-written and thoughtful.

Unfortunately, while the author extolled the renewed virtues of email mailing lists, he didn't really cover some of the modern-day realities and challenges most marketers and list managers won't tell you about until it's just too late.

But I will. I've been there. I've done that. I have the scars to prove it.

The premise of the article is simple. Despite the prevalence of social networking, the rise of Twitter and Facebook, nothing works for direct, immediate outreach in the corporate space like an email newsletter.

This is true.

We have a number of email newsletters here at ZDNet, including one devoted to my ZDNet Government blog. You can see a big, blue subscription form. It's right there, to the right of this column ------>.

Back in 1998, when I first started the ZATZ Web sites, we knew that people would come visit the Web sites (even then, search mattered). But we knew what would bring readers back was reminding them we were there. So every week, we sent our opt-in readers news summaries and tips and techniques.

Over the years, we amassed a list of more than a million subscribers. As email spam became more and more of a problem, we added further insurance to make sure only readers who wanted email got it. We added a triple-opt-in process, which meant you had to opt-in, then you'd get an email confirmation where you had to confirm the opt-in, and then we had a permablock option, where you could permanently opt-out of getting any email from any newsletter, forever.

Further, each email message sent had what's called a VERP, a variable envelope return path, that allowed us to be sure that regardless of what email address the user used to subscribe, when he or she wanted to unsubscribe, we could guarantee we could successfully process the unsubscribe request.

I decided I'd try to move my mailing list to a list management company. The process was a total disaster.

In addition, we would periodically validate and de-bounce the list. Validation meant sending the list to outside providers to verify that each email address was deliverable (and removing the bad addresses) and de-bouncing meant that after a certain number of failed deliveries in our own system, we permanently removed the address.

In other words, we operated our mailing list with the absolute best practices. We'd get one or two subscriber complaints a year, usually from someone who'd forgotten he or she had subscribed.

A year or so ago, I decided I didn't want to run my own mail servers anymore. I've been fortunate enough to change my career primarily to teaching, lecturing, writing, and punditry. Mailing list management is a pain. So I decided I'd try to move my mailing list to a list management company. There are a ton of cloud-based mailing list providers out there, most with very inviting offerings.

The process was a total disaster. Even though I had a thoroughly vetted set of lists with subscribers who opted in, it became impossible to actually move the list to a new vendor and keep it running.

Basically, what happened is I ported the list to a new vendor, and did a first mailing. Since this first mailing came from a new source, some of our subscribers reacted by complaining they'd never subscribed. Even though they'd subscribed to our newsletters, they weren't aware of the new sending email address of the new vendor.

When you have hundreds of thousands of subscribers, you're going to get a few complaints when you do something new. A few complaints came into the first mailing list provider, and without even contacting us, they just cut us off. No mailings and no access to our list. No calls returned. No email contacts returned.

Now that I knew this might be a problem, I moved on to another vendor. This time I did my homework again, and added relationship building to the process. I informed the vendor ahead of time of the situation, discussed it in detail, worked out exactly the potential issues, and had complete assurance that there would be no problem moving the list over.

We started our first mailing, and wouldn't you know it? A few subscribers complained. The second vendor immediately cut me off as well. What annoyed me the most was that there was no acknowledgment of our previous discussions, and absolutely no willingness to work out a solution.

To be clear, the newsletters I mailed were not spam. One was about IBM's Notes and Domino, another was about mobile technology, and a third was tips and techniques for Outlook and Exchange. All three had been successfully mailed for more than a decade.

Vendors are so scared of being slapped with the "spam" label that they don't use good business practices when working with customers.

I actually tried a third vendor, but that one insisted that they wouldn't mail to any pre-existing addresses. We'd have to start from scratch, and they'd be willing to build up a list, but they wouldn't take anyone who hadn't opted in on their mailing list system. Period.

Finally, I just went back to operating my own servers, using the nice ISP I've been using for years. Because the ZATZ sites are now primarily archive sites for the hundred thousand or so articles we've published over the years, I no longer offer a subscribe form. We just mail weekly updates to our existing, very loyal readers, who number now somewhere in the 20-30 thousand range.

So, what's the moral of this story?

It's sad, really. Vendors are so scared of being slapped with the "spam" label that they don't use good business practices when working with customers. It's a one-strike and you're out sort of game.

That leaves me with one warning for you: if you're currently operating a mailing list with a lot of subscribers, work your vendor relationship carefully. Because the odds are, you're stuck with your current solution. It's highly unlikely you'll be able to move your mailing list to another vendor (especially if you're a relatively small company with a relatively big list).

Email-based mailing lists may be here to stay, but so are the systems they're mailing from. This is lock-in and you're pretty much stuck with what you were doing back in 2005.

Topics: Data Management, Cloud, SMBs, IT Policies

About

David Gewirtz, Distinguished Lecturer at CBS Interactive, is an author, U.S. policy advisor, and computer scientist. He is featured in the History Channel special The President's Book of Secrets and is a member of the National Press Club.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • So very true...

    You summed it up nicely.

    On Internet, it all boils down to: if you want to keep your reputation, be very careful what you start. For you may have to continue doing it until you pass away.

    I have a joke about all this: It's like applying as an field agent spy. You cannot quit on your own. You are never dismissed either. You serve until the end.
    danbi
  • If your're on your own you have another fight...

    About 7 years ago I decided to use open source PHPList in order to be the real owner of my mailing lists, but the big problem is that if you're not one of selected big vendors, you constantly have to fight removing your server IPs from all kinds of spam engines, black lists, et., etc.... So I guess there is no easy way. You can use hosted SMTP server services to at least try make that problem easier.
    Tomas M.
  • "Lock-In"--I Do Not Think It Means What You Think It Means...

    "Lock-In" is supposed to be where an important part of your business is under the control of some vendor, and you cannot take it away from them.

    Here you have the opposite problem: the system is under your control, and you can't seem to pass that control to a vendor.

    Whatever it is, it's not "lock-in"...
    ldo17