Why We Built a Product for ESPs

If you missed our announcement last week, the title of this post might seem a little strange: an email service provider (ESP) building a product for other ESPs? Well, lots of ESPs rely on another ESP’s sending infrastructure to support the email activities of the hundreds or thousands of individual senders using their platform to power their businesses.

Now an ESP building something for other ESPs starts to make sense, right? Right. 

So, why did we build email infrastructure tools specifically for service providers and complex senders who are currently using the likes of SendGrid, Sparkpost, Amazon SES or Mailgun to send their mail? 

We’ll get to that. But first, let’s look at why those tools were needed. 

Why did we build a product for ESPs? 

Let’s start with a short history lesson.

How we got here

Email was exclusively on-premises for a long time. But as the world around us evolved and moved to the cloud, so did email. This ushered in a big change in the email industry because it created a new fast-pass to scalable email sending without the upfront investment in email infrastructure and the teams capable of managing it on-premises. 

What happened next? Naturally, the emergence of many robust marketing automation providers (like Braze, Attentive, Klayvio…) that quickly rivaled more established marketing clouds (Salesforce, Oracle, and Adobe). This led to the heyday of marketing automation, which opened a whole new world of possibilities and creativity for email marketers. But as those capabilities grew, outsourced services via cloud infrastructure became costly to ESPs, some prohibitively so for smaller providers. 

This is because of one big thing: Most core cloud infrastructures were designed for single-tenant, direct sender use, not for multi-user service providers and other complex senders. This severely limits ESPs’ ability to optimize, scale, manage budgets…literally do ANYTHING quickly and with confidence because so much still needs to be built to be effective. They end up going to great lengths to shape products to their own use cases. 

MacGyvering a vendor’s standard direct-sender technology into an ESP’s complex needs usually requires multiple groups to design additional features, duct tape workarounds, and solve a variety of unforeseen issues typically stumbled upon while trying to optimize performance of the infrastructure while scaling. Because of the work involved, ESPs find themselves with significant and growing technical debt and deep integrations with their current provider. This makes it difficult to justify the work necessary to switch providers when they’re dissatisfied with their performance over time. 

Unfortunately, ESPs often find themselves going down with the poorly performing infrastructure ship because they invested so much to get settled onboard. There needs to at least be a lifeboat to keep them afloat in choppy waters. 

So… 

What issues did we solve in our product for ESPs?

Here we are today.  

There is a vast need for email sending infrastructure built specifically with the one-to-many sender in mind. One that skips all the trips to the hardware store for more duct tape and lets service providers and complex senders do their thang when it comes to email.  

The issues we needed to solve were clear. 

Issue: visibility 

For service providers, it is nearly impossible to see the performance of hundreds or even thousands of users efficiently and successfully. Even when they know there’s a problem, it’s difficult to detect below-average senders, meaning they can continue to send mail and damage the performance of good senders. 

Issue: optimization 

It’s increasingly difficult for ESPs to maintain positive performance for good senders because the behavior of poor senders taints the entire pool. Today’s platforms aren’t engineered to manage the reputations of so many senders. Poor performance leads to substantial support overhead and eventual customer churn.  

Issue: customer scaling 

Current platforms weren’t designed to grow to accommodate additional senders, just more mail, because they had single-senders in mind. ESPs often find themselves dedicating significant time and energy to onboarding customers and monitoring warm-up activity.  

Issue: competition 

With so many email service providers being acquired by larger parent companies with omnichannel technology, they can do lots of things (including sending email) on their one platform, cutting out the need for the ESP-middleman. It is more beneficial for them to sell directly to end users than it is to support an ESP’s customer. Don’t be surprised when a mega-provider finds it easier to send mail for your customers themselves rather than through you.  

Issue: product focus 

Frankly, the largest sending platforms are no longer email-focused. There are so many marketing channels to use today and since parent companies of email sending platforms are omni-channel, email is now just one channel of many and still suffers from the idea email is not much more than a small piece of a very large puzzle. ESPs can’t rely on these mega-infrastructure providers to continue innovating in email…they’ll find themselves waiting a long time. 

How we built the solution

Remember how we said all those beautiful email minds started migrating away from the mega-providers? Well, we are the lucky winners of the email lottery. Our team is full of seasoned experts with their own experience at different ESPs like SendGrid, Mailjet, Oracle Marketing Cloud, and Salesforce Marketing Cloud. From engineering and product to compliance, deliverability and marketing, SocketLabs brings together the people who know exactly what problems ESPs face. 

The ask was simple: Can we build all the email infrastructure management tools we always wished we had when we were at ESPs? 

The answer was more complex. The bar was very high but we basically did this: 

Nailed it.

We started with a strong technical foundation in our powerful, homegrown mail transfer agent (MTA). Our on-prem MTA, Hurricane, was launched in 2008 and we started a cloud version in 2009. Since then, billions of emails have deployed through both. Let’s be frank: When you send that much email for that long, there are definitely times when you don’t clear the bar and belly flop onto your face. It hurt, but over time we learned how to do it well and at scale, so you don’t have to smash your face like we did. 

We harnessed a combination of powerful technology and industry talent to build the right features to solve ESPs’ biggest issues.

We created a platform for ESPs to easily manage their complex infrastructure.  

Are you ready to make your life at your ESP easier? We are.