There are a couple companies currently looking for delivery specialists.
e-Dialog: Delivery Specialist
Responsys: Delivery Consultant
ThinData: Delivery & ISP Relations Analyst
ThinData: Privacy Analyst
Know anyone else hiring? Leave links in the comments.
Mailchimp published a case study looking at a customer moving from sending in house to using Mailchimp.
Read MoreIn the theme of the ongoing discussions about ESPs and their role in the email ecosystem, I thought I’d present some examples of how different ESPs work.
The good ESPs are those that set and enforce higher standards than the ISPs. They invest money and time in both proactive and reactive policy enforcement. On Monday I’ll talk about these standards, and the benefits of implementing these policies.
The typical ESPs are those that have standards equivalent to those of the ISPs. They suspend or disconnect customers when the customers generate problems at the ISPs. They have some proactive policy enforcement, but most of their enforcement is reactive. On Tuesday I’ll talk about these standards and how they’re perceived by the ISPs and spam filtering companies.
The ugly ESPs are those that have low standards and few enforcement policies. They let customers send mail without permission. Some of the ugly ESPs even abuse other ESPs to send some of their mail, thus sharing their bad reputations across the industry. On Wednesday I’ll look at some of their practices and discuss how they affect other players in the industry.
There is no such thing as a delivery emergency. They just do not happen.
Delivery is fluid, delivery is changing, delivery is complex.
But when delivery goes bad it is not an emergency. There is no need to call up an ISP person at home on a Saturday afternoon and ask them to remove the filters. (And, BTW, experience indicates if you do this that you may have future delivery issues at that ISP.)
I’m sure that people will provide me with examples of delivery emergencies. And, in some cases I might even concede that the receivers will be happy to receive email immediately when it was sent. However, email as a protocol was designed for store and forward. It was not designed to transmit messages instantaneously from sender to receiver. Sure, it works that way much of the time these days. On the whole the Internet is fairly reliable and major servers are connected 24/7 (which wasn’t always the case).
Among many people, particularly recipients and ISP employees, there isn’t the expectation that bulk email is instantaneous. This leads to the belief that delivery problems are not an emergency. Everyone faces them, they get dealt with, life goes on. Demanding an escalation to deal with a “delivery emergency” may backfire and slow down how long it takes to get a response from an ISP.