Email Integration

One of our clients approached us a while back about fixing their email implementation.  Email volume for this company was easily in the 2MM+/month range as the company has a large sales force (100k+) of geographically dispersed folks.  As is probably obvious, email is a critical component for them.  It has to be reliable and timely so that they can effectively message, schedule, and direct those sales folks, often at a moments notice.

When we started talking to them about their pain points and coupling that with analysis of their legacy implementation, it was easy to see that they needed to bring a good amount of functionality online.  One of the biggest issues of their existing implementation was that their email model was very much a fire-and-forget model.  They were delivering email from their applications to their own SMTP server.  That server would give an immediate delivery accepted or rejected message and the calling applications would note that and go on their merry way, thinking all is well . . .

Unfortunately, email doesn’t quite work that way.  There are a lot of factors that come into play.  For one, the delivery SMTP server doesn’t know if those are valid email addresses for one, it can only verify that those addresses are more or less syntactically correct.  Once that server actually went to go try to deliver those emails, it would then get responses indicating that specific users didn’t exist, maybe mailboxes were full, etc.  But, at that point, the application side of the house had already marked off that those emails had been successfully delivered (when in fact, at least some percentage did not).  This small thing was causing an issue on their sales team where folks would complain that they were not looped in on some (potentially critical) correspondence.

The other unfortunate side effect of not capturing the actual delivery responses — besides not really knowing if any specific email was delivered to the recipient — was that this company was continuing to send emails to bad mailboxes.  As they continued to try to deliver emails to bad addresses and as more sales people joined, even more bad addresses were added.  This just contributed to decreasing reliability as ISPs would routinely block or defer delivery of email for this client.  Essentially, their email reputation was being negatively effected and as they continued to send emails the worse it was becoming.

So, we put in a solution that did a couple of things.  One, it centralized their email system and we gave them a single, authoritative manner in which to deliver email.  This system integrated not to their SMTP server, but a high volume email provider.  That’s a vendor whose job is to deliver email.  We tied in through that vendor to receive delivery status notification, so that our customer could definitively answer the question: “did that email get delivered to x person” and “why not?”.  In addition to those metrics, we also put open and click tracking in place and stored both the requests and responses in a database so that they could look at point in time data and report on the effectiveness of any single email communication.  Thse guys don’t worry about email anymore.