Choosing an ESP: The Inside Scoop

By John Caldwell

There has been a recent surge in articles and posts about selecting a new ESP – everything from why one would or should to how to go about it from beginning through RFP. Some are opinions by pundits based on what they have observed or picked up in meetings and conversations. Better ones come from the first-hand experience of day-to-day email marketers sharing their experiences of going through the process. And then there are the articles and posts by agencies and consultants that guide others or perhaps manage the entire process.

You don't have to read very many before the commonalities begin to surface. Step 1 is always going to be having a justifiable business reason to switch. It's almost always less expensive and time consuming to repair a relationship if it can be repaired, and the deeper an organization is integrated the more expensive and time consuming a migration will be.

On average the typical ESP user will use less than 30% of a platform's features or functions; the thing is nobody uses the same 30%. The Email Vendor Features & Functions Guide from Red Pill Email survey's ESPs on over 600 data points. If the average vendor features number 400 that means that an organization using 30% of the platforms feature capabilities totals 120 features being used. That's a lot. But it doesn't matter how many features an ESP has if they don't have the ones that you need; or are not efficient in their use, and that could be reason to make a move.

Step 2 will be collecting requirements from the email platform stakeholders within the organization. It's important to list all of the Functional and Non-Functional specifications for all of the stakeholders. It's equally important to group like functions to reduce them to the core function. Save the long list to satisfy internally, but only show to vendors what they need to know to meet the organizations requirements. Sending an email after someone completes a subscription form or survey form or any other kind of form is at its core form-triggering an email.

Step 3 is compiling the RFP. That's RFP not War & Peace. Opinions differ whether to RFP before or after developing a short list or seeing platform demonstrations. There isn't really a right or wrong answer or way of going about it. Having an immense amount of data on scores of ESPs we like to create a short list based on the client's requirements that will be invited to demo to help determine which vendors will be invited to RFP.

The RFP should be short, sweet, and to the point, and by to the point I mean not 237 4-part question laundry list or an exhaustive list of every conceivable application of a form-triggered message. And always be sure to use the correct descriptive – and often legal – language in the RFP. “Shall” is an absolute and if the platform does not meet a “Shall” requirement then it is disqualified. Period. If the requirement is not absolute “Should” is the proper qualifier. This isn't me making stuff up, this is all ISO language; if you're going to use it make sure you follow it and know what it means.

Following the RFP comes contract negotiations followed by preparing for migration; both topics for another time…

About Red Pill Email

**** Active in email marketing since 1996, Red Pill Email founder, John Caldwell, has worked on the agency side, the client side, and as a consultant, using deployment tools from ESPs to in-house to homegrown email systems.

He has been involved in over 50 ESP vendor selections for major clients since 2005, and has produced an annual Email Vendor Features & Functions Guide since 2009. The annual vendor guide reviews ESPs across 600 data points and is the only ESP vendor guide written by an experienced hands-on practitioner providing objective analysis of email vendors' functional capabilities.