Last week when I announced the completion of our annual Email Vendors Features & Functions Guide I mentioned that this year’s Guide includes a section on Preparing for Vendor Selection.  I promised that we’d be giving that section away here; and here we are. 

When we engage with a client on a vendor selection project we always start with a Discovery.  The primary objective of discovery is to define, map and analyze existing email messages, programs, and processes; and to document their current state within the organization in order to provide a baseline for the project moving forward.  

The first step is to discover existing processes, step-by-step, to understand all the functions performed by individuals on legacy systems. Documenting the processes, with all the required views, data, drawings, and analytical reports follows.

The Discovery is intended to provide insight into the underlying business problems that motivated the project. This insight will then serve as the foundation for developing Functional and Non-Functional Specifications required for supporting current and future email messaging programs and initiatives.

A specification is an explicit set of requirements to be satisfied by the prospective vendor.  Specifications are needed to avoid errors due to lack of specification, for instance, in interoperability issues.  For instance, when two applications share data, but use different normal forms or use them incorrectly, in an incompatible way or without sharing a minimum set of interoperability specification, errors and data loss can result.

The specification describes the features the vendor solutions must meet or exceed to support the client’s messaging needs.  In practice, many successful specifications are written to understand and fine-tune applications that were already well-developed and in operation.  Specifications are most important for external interfaces that must remain stable.

Specifications should be divided into two unique parts, Functional and Non-Functional.

Functional Specifications define what the vendor platform is expected to DO.  A functional specification is the documentation that describes the requested behavior of vendor platform or system.

The documentation typically describes what is needed by the user as well as requested properties of inputs and outputs of the system. A functional specification is the more technical response onto a matching requirements document. Thus it picks up the results of the requirements analysis stage. On more complex systems multiple levels of functional specifications will typically nest to each other.

Non-Functional Specifications define what the platform is expected to BE.  A non-functional specification is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional specifications that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

A system may be required to present the user with a display of the number of records in a database. This is a functional specification. How up-to-date this number needs to be is a non-functional specification. If the number needs to be updated in real time, the vendor must ensure that the system is capable of updating the displayed record count within an acceptably short interval of the number of records changing.


Sample Discovery Questions

The following questions are a sampling of Discovery questions used by Red Pill Email in vendor evaluations and selections.

Critical Issues 

  • What is the biggest challenge your organization faces regarding email messaging?
  • Who needs to be involved with any solution considered by your organization?
  • Please identify any technology, resource, or business dependencies:


  • What limitations do you face with your current deployment vendor?
  • What are your strategic messaging objectives (6mos, 12mos, 18mos, 24mos.)?
  • What are the pain points with current provider?


  • What data is required to support your current messaging?
  • Is data automatically updated, or is data obtained ad hoc?  Please describe.
  • What metrics are used to measure success?


  • What is the total number of active subscribers?
  • What is your average message deployment volume?
  • What is your average overall monthly deployment volume?


  • Please describe your current messaging programs and provide content examples:
  • Please identify message triggers and/or timing:
  • Please provide an overview of your current messaging processes:
  • Where do you see difficulties or obstructions in your current messaging process?


  • What resources do you have to support your messaging programs?
  • How long does it take to develop and deploy campaigns?
    Ad hoc? Automated?
  • Who initiates and/or requests and/or approves offers and content?


  • Are you currently integrated with any third-party solutions?
    If so, who and for how long?
    If so, what is your level of integration?
    If not, do you plan to integrate with any third-party solutions?


Be sure to check back next week for Part 2, Preparing an RFP.