Vendor and Solution Selection 101

By: John Rushing, Founder

 

Introduction

Let’s face it, nobody likes to write Requests for Proposals (RFP’s). They can be arduous to develop, require a lot of everyone’s time, and the more complex the RFP, the more difficult they tend to be to score.  But, if you’re selecting a vendor and solution that will determine how effectively and efficiently you can drive the desired Customer Experience (“CX”) for your business, we would argue that ensuring that you select the right solution is well-worth the time and effort. Better still, ContactScope™ has the experience, methodologies, and tools needed to ensure that the process can be executed as efficiently as possible while ensuring that the vendor and solution you select is capable of meeting all of your organization’s business and technical requirements.

In this article, we will discuss our approach to vendor and solution selection and will also describe some of the tools we use to ensure that the process can be completed as efficiently as possible.

8 Steps to a Successful Vendor & Solution Selection

The process that we follow to create, submit, and score RFP’s on behalf of our clients consists of 8 steps that we believe result in the most thorough and fair evaluation of selected vendors and solutions possible. Each of these steps is listed below and are described in more detail in the following pages.

1. Identify and Document Business, Functional, and Technical Requirements
2. Draft the RFP, RFP Vendor Response Scorecard, and Solution Pricing Worksheet
3. Identify and Establish Contact with Vendors to receive RFP
4. Issue the RFP
5. Score the Vendor Responses
6. Conduct Vendor Demonstrations
7. Check Vendor References
8. Select Vendor & Solution

1 – Identity and Document Business, Functional, and Technical Requirements

In our article called “The Case for Design” we discuss the importance of having well-defined business and technical requirements as the project moves from initial selection to detailed design and eventually implementation. We believe that it is best to begin the process of identifying and elaborating on requirements during the RFP phase of the project. Doing this early provides two essential benefits.

1. Defining requirements during the RFP creation phase of the project allows the team involved to begin the process of requirements elaboration. This process defines not only what functionality a company wants or needs, but how that functionality would be used and to what end goal.
2. When vendors respond to the RFP, well-defined requirements (along with the carefully crafted wording of the RFP questions) will allow the vendor to not only indicate that they fully support the required functionality but exactly how they would use their system’s capabilities to meet the specific use-case specified.

This approach we believe results in a much more thorough vendor response which in turn leads to fewer surprises down the road during system design and implementation.

Documenting Business and Technical Requirements

When documenting requirements, we recommend the following approach;

• Use an ID for each requirement to ensure that it can be tracked in the future. This will be helpful in later stages of the project as requirements are incorporated into use cases or addressed as a part of the solution design. As a general rule, requirements should be differentiated from one another as either a business/functional requirement or a technical requirement. This may be done by using a “type” or “category” definition for each requirement; a naming convention for the ID value if requirements are tracked in a single requirements sheet; or by tracking them separate sheets.
• Group requirements based on similar functionality. We typically have individual questions on a related subject grouped into “Sections” and related sections grouped into “Topics”.

• Indicate the criticality of the requirement. In our approach, we typically use “Must Have” and “Nice to Have” at a minimum.

In cases where the solution is being implemented to support more than one group or department (e.g., a customer service group, a sales group, and an internal helpdesk), it is essential to track the criticality of each requirement for each group since what is “nice to have” for one group may be a “must have” for another.

• As a best practice, also track the source of the requirement. This may be an individual, a group, or an outcome of a specific meeting or discussion. Tracking the source will allow the team to follow up with the right person or persons should there be questions about the requirement in the future.
• Notes for each requirement may also be helpful, particularly in the early stages as the requirements are being documented. Notes can help guide personnel during the drafting of the RFP by providing additional detail that may not be evident in the requirement description itself.
• We generally include a use case column in our requirements sheets to enable the team to go back when use case development begins and ensure that individual requirements can be traced to a specific use case. While this is not necessary for every single requirement, critical requirements should definitely be included in use case development.

How ContactScope Can Help Expedite Requirements Gathering & Analysis

Over the course of 25+ years, we have written a lot of requirements and RFP’s for just about every imaginable type of CX solution. Because of this, we can provide our clients with pre-defined sets of requirements that are unique to each solution type. While we would never recommend using a “starter set” of requirements as the only source for requirements analysis, having such a set definitely gives the team something to start with. This will allow the team to jumpstart requirements analysis and to focus on defining those requirements which are both critical and unique to your organization and your organization’s customer experience goals and objectives.

2 – Draft the RFP, Vendor Response Scorecard, and Solution Pricing Worksheet

Creating an effective RFP can be a daunting task but will be made much easier if your organization has completed the groundwork beforehand.  This includes defining a thorough set of business and technical requirements, discussing use cases that demonstrate how requirements will be realized in terms of specific functionality in the system, and ensuring that the organizational stakeholders are in agreement regarding how the system needs to operate to meet everyone’s needs.  The next step then would be to actually create the RFP documents that will be needed to facilitate the selection process. It is important to note that the steps detailed here apply no matter how the RFP will be distributed to participating vendors. Online RFP management systems are a popular option today since they provide both the company issuing the RFP and respondents with features that help to expedite communications during the processing of the RFP. These systems do not, however, eliminate the need to develop the content of the RFP carefully.

Drafting an Effective RFP

When I was in the service, I noticed that every system or technical manual was written in the same format no matter what type of system it was or its purpose. The documents always began with an overview of what the system was designed to do and a general description of its capabilities. This was followed by sections covering the physical characteristics of the system, the functional aspects, descriptions of the systems significant components, and then sections diving into increasing levels of detail for each component and sub-component that made up the system.  Like everything in the military, this structure was anything but accidental. If you’re working on weapon systems, and there’s a problem, you really don’t have time to study the table of contents. The common structure of the documents allowed readers who were familiar with the system to zip quickly to the appropriate section or sections of a document in order to obtain the information necessary and move on (this was obviously well before the age of digital systems manuals).

I believe that a well-crafted RFP should have a similar structure albeit for completely different reasons.  For both authors and respondents of an RFP, a logical flow from general to highly-specific (technically or functionally) helps to establish a proper mental framework for working on the RFP. We generally recommend a structure as described below whenever possible.

RFP Content Sections and Flow

At ContactScope we generally divide RFP’s into sections which generally flow as follows;

• Section 1: Introduction – This section is divided into subsections that provide vendors with background on the way the RFP is being issued and provides instructions and guidelines to the vendors responding to the RFP.
  • The most important part of this section is the RFP guidelines which should include a complete schedule for the vendor selection project including;
    • when the RFP will be issued,
    • the date/time of the bidder’s conference,
    • closing date/time for vendor questions/clarifications,
    • vendor notification of outcomes,
    • date (date range) of vendor demonstrations & reference checks,
    • date final selection decision, and
    • the desired date for the end of contract negotiations.
  • This section should also provide clear guidelines on how communications with vendors and between vendors and the company will be handled. In the interest of ensuring a fair selection process, we generally recommend that all communications between the company and vendor participants be strictly limited during the selection process. Further, any questions or comments received from one vendor should be shared with all (both the question/comment and the response). To facilitate this, an individual point-of-contact should be defined for the company and each participating vendor. No communication should be conducted regarding the RFP, the selection process, or vendor capabilities and/or status except through the defined POC’s.
• Section 2: Company Background – This section of the document is generally divided into subsections that describe the following;
  • Background on the company issuing the RFP including information on the company’s size, number of employees, office locations, markets/sectors the company operates in, number/type/location of contact centers (if applicable), etc. Generally speaking, the more information the company is able to provide here, the better vendors will understand the environment their solution will operate in.
  • Detailed information about the company’s voice and data communications environment should also be included as these tend to be very relevant in customer experience solutions. To the extent possible, diagrams should also be included to help the vendors understand how services are deployed, accessed, and managed within the environment.
  • Detailed information covering the company’s use Contact Centers including number, location, type, and function of each. Obviously, the number of agents and the make-up of agent groups is usually helpful.
  • Detailed information on the company’s applications environment including a description of all applications used to support CX. This should include information on the version/release of each application as well as a description of any custom-developed applications or integrations that may be relevant in the environment.
  • Finally, a subsection on how the company envisions the new system/application operating in their environment and how the solution will impact their operations in the future-state.  If the company has previously undergone a CX Capability Maturity Model / Future-state visioning effort, the information collected during that effort will be very helpful here.

The information included in the RFP up to this point has all been centered around giving the vendors information that they can use to respond more effectively to the company’s RFP.  A good vendor RFP response team will tailor their response to the information provided in the first two sections of the document to explain not just what their solution can do but how its capabilities will address the specific needs of the company as described in the document.

The next two sections of the document, are really the core of the RFP and include the Vendor Questionnaire and Document Request sections. While the actual content of these sections is specific to the type of system being selected, there are some general rules that can help.

• Section 3: Vendor Questionnaire – Regardless of the type of system being selected, we generally start this section with subsections that ask questions related to the vendor’s company (size, number of employees, office, support functions, etc.); the product or products that they are recommending as a part of their RFP response; and a general technical subsection that covers systems administration, data & security, compliance, business continuity, use of 3^rd-party services, etc.
• The remaining subsections of Section 3 would be dedicated to questions pertaining to the Functional and technical capabilities of the solution and its ability to meet the company’s requirements and operating model. In keeping with the concept of going from general to highly-specific, we generally try to write each of the functional capabilities subsections to begin with very general questions about a given capability and progress to specific applications of the capability in the company’s environment.
  • In this regard, it is important to note that there is absolutely nothing wrong with repeating the same question in a different way, both within a subsection and between them. For instance, if the solution being selected is a Contact Center as a Service or “CCaaS” system, we would have questions in a subsection that may be called “Interaction Handling” that ask a general question about the solutions ability to handle (route, treat, target for a given resource) using different types of channels. Later in the same section, we might rephrase this question regarding handling a specific kind of interaction. Similarly, we would likely have a subsection on Omni-channel and Multi-channel communications or performance management reporting and would again pose the question under that specific context while elaborating on particular capabilities referenced in the subsection. It has been our experience that taking this approach tends to yield much more information about how the vendor’s solution addresses various capabilities and how these may apply in the company’s environment.
  • While some small percentage of questions in Section 3 may require only a yes or no response, we generally recommend stating questions in a way that forces or at the very least encourages the vendor to elaborate on their response.
• Document Requests
  • We generally have a section of the RFP that requests that samples of different types of documents be provided with the RFP response. These may include sample reports, user documentation, system diagrams or other information that pertains to the solution.

While there is some level of effort required to draft an RFP in the manner described, we have always found that the end result is well worth the effort. We generally recommend preparing the vendors ahead of the RFP issue date to let them know the company’s expectations regarding the vendor response to the RFP. This should give the vendor sufficient time to coordinate their teams so that they can match the company’s efforts in drafting the RFP when they respond to it.  As you might imagine, there will be vendors who fail for whatever reason to step up to the challenge. Our opinion in this regard is that if the vendor is not willing to put the effort into winning the company’s business, there is no reason to assume that will put any more effort into ensuring the company’s success after the purchase/service agreement is signed.

RFP Document Formats

When we issue RFP’s to vendors, we recommend issuing a PDF document containing the actual RFP content and a vendor response worksheet (Excel) that contains each question (group by section/subsection) and space for the vendor to respond. Responding inline in the document containing the RFP is also an option. If an inline response is preferred, issuing the document as an MS Word or similar format tends to be easier than a PDF.

As mentioned previously, there are numerous online RFP tools available that allow the vendors to read and respond to questions online which saves a great deal of effort and enables response teams to work more efficiently.

3 – Identify and Establish Contact with Vendors to Receive RFP

In most cases, companies will have already considered by the time the RFP has been drafted which vendors should be considered to respond to it. We believe that it is critical to establish contact with the selected vendors as early in the process as possible. Generally speaking, companies will issue a letter of intent and a mutual non-disclosure agreement as a part of the pre-bidding process but we recommend taking a few additional steps at this early stage to begin the process of building a relationship with each prospective vendor. These are discussed briefly below.

1. Take the time to speak with each vendor to determine their willingness and ability to bid on the solution.
2. Explain the structure of the RFP and the importance of responding fully to each question/item in the RFP.
3. Make the vendor aware of the selection timeline and key dates.
4. Have each vendor assign a single point-of-contact for the selection process
5. Lay the ground rules for communication during the selection process. This is particularly important if one or more of the vendors involved already has one or more solutions in place in the environment (e.g. they are an incumbent).

While some of these may seem unnecessary on the surface, our experience has always been that most vendors appreciate the effort a company takes to ensure a fair, transparent, and objective evaluation of their company and their solution’s ability to meet a prospective customer’s needs.

4 – Issue the RFP

The RFP should, of course, be issued based on the schedule defined but in our experience, some additional steps will help to ensure a thorough response from the vendors and a smooth and fair selection process.

• Establish a date approximately 3-5 business days after the RFP issue date that is the final date for questions or clarifications regarding the RFP. Vendors should be instructed that they must send any questions or requests for clarification to the assigned point-of-contact at the company via email. They should not be allowed to use chat, phone, face-to-face meetings, or any other means to seek clarification.
• When responding to a question from any vendor, all vendor points-of-contact should be copied with the text of the original question and the response from the company.
• Establish a date and time for a bidders conference approximately 7-business days after the issue of the RFP. This conference should also be scheduled a day or two after the close of questions from the vendors.
  1. During the bidder’s conference, we generally recommend highlighting the key requirements of the solution, reviewing the RFP schedule, and of course going over any questions that have been received up to that point. After this, vendors should be given the opportunity to ask any final questions for the balance of the bidder’s conference. At the end of the conference, vendors should be reminded that there should be no further communication regarding questions or clarifications or the status of the selection until all vendor responses have been completed and received.

When issuing an RFP, we generally recommend giving the vendors 30-calendar days to respond. While this may seem like a long time to some, it is important to remember that the company put a lot of effort into creating the RFP and should, therefore, allow adequate time for the vendors to respond to it effectively.

5 – Score the Vendor Responses

Establishing both a process and a tool to evaluate each vendor response objectively and fairly is obviously very important. From a process perspective, we believe that one key to a successful selection is ensuring that all internal stakeholders have the opportunity to participate in the scoring and that in the end, a consensus is achieved by all internal parties regarding which vendor and solution will best meet the company’s needs.

Vendor Response Scoring Process

The scoring approach that we generally recommend is to establish a scoring team early in the process of creating the RFP.  This team should be cross-functional and have representation from each group or department within the company that will be impacted by the solution. This would include stakeholders from the various business groups (operations, training, quality, workforce management, management, etc.) as well as supporting organizations such as IT.

We generally kickoff the scoring process by conducting a team meeting during which all scoring participants are walked through both the RFP and the scoring tool that will be used to evaluate vendor responses. Once scoring begins, we generally recommend that each participant be given the opportunity to review and score each vendor response either on their own or in small groups. Participants should be given adequate time to do this and that time should be scheduled in advance to ensure the availability of personnel as much as possible. We generally recommend that comparison of vendor pricing for each solution be evaluated separately (and after) scoring of the vendors’ responses to the RFP.

Once all individual stakeholders or stakeholder groups have completed their own individual scoring, we recommend using another group meeting to go through the scoring process again as a team. While this may seem redundant, our experience has been that it helps to build consensus across all stakeholder groups while simultaneously giving individuals or sub-groups the opportunity to make their case for why they scored a given vendor capability the way they did.

If your company is using a 3^rd-party (like ContactScope J) to conduct the vendor selection, we strongly recommend that the 3^rd-party’s response scores be used as a “control” score. They should not in our opinion, be averaged in with or otherwise allowed to impact the final vendor scores.

Please note that the goal of the scoring process at this stage should be to narrow the list of vendor candidates to no more than 2-3 vendors.  These vendors will undergo additional due-diligence before the final selection as described in the sections below.

The most important thing at this stage is that once the vendor scoring is complete, all stakeholders should feel that their voices have been heard and that everyone is comfortable with the scoring assigned to each vendor.

Vendor Scorecard

In order to score individual vendor responses to an RFP, we use an excel worksheet (as shown below).  The worksheet has all of the questions from the RFP listed and numbered as they are in the original document along with a column to score each vendors response. As evaluators read through each vendors response to a given question, they rate it on a scale of 0-5.

Our preferred scoring mechanism is to use the scale as follows:

• 0 = The desired capability or requirement cannot be met
• 1 = The requirement can be met but requires custom development
• 2 = The requirement can be met using a component or add-on supplied by a 3^rd party
• 3 = The requirement can be met using a vendor-supplied component or add-on
• 4 = Fully meets the requirement
• 5 = Exceeds requirement

We have found that in most cases, the scale above will suffice but in some cases, it may be necessary to adapt the meaning of each value to suit specific selection needs. As long as the scale is used consistently for all questions and vendors, modifying it to suit specific needs is fine.

In addition to the raw score for each question/vendor, we apply a weighting to both the individual question and the “topic” or category of questions. Weighting allows a company to indicate which of the requirements are most important to them.  Questions that pertain to a key requirement or capability would have a higher weighting while less significant ones would be weighted lower.  The topic or section weighting is applied similarly except, in this case, the sum of all topic weights must be 100%. In essence, this allows the company to define with a fairly significant degree of precision what topics and questions are most important and which are less so.

When scoring for all vendors responses has been completed, we will generally recommend comparing the scores with and without weighting just to see how vendors stacked up. In addition, the tool we use allows us to compare each vendor’s response at an individual question, topic or overall against the averages of all vendors for the same area. This can also be useful if the results were relatively close.

Solutions Pricing Worksheets

One of the most difficult parts of any vendor comparison can be structuring the pricing worksheets to ensure and “apples-to-apples” comparison of costs for one solution versus another.  This can be made all the more difficult if the company is comparing “Cloud” solutions to on-premise ones given the differences between how each is priced. We generally work closely with the vendors during the RFP draft phase to ensure that we understand their pricing models and then build a pricing worksheet to suit all of the solutions. In most cases, this pricing sheet will compare the following;

• Year one costs (itemized) – This includes all costs to acquire, implement and run the solution for the first full twelve months. Costs are broken down by type (hardware, software, service, implementation, etc.) and itemized.
• Recurring Annual Costs (itemized) – The would typically including seat/server or other recurring license costs, maintenance fees, support costs, and other recurring costs associated with the solution.

As mentioned previously, the goal of scoring the vendor responses is in most cases to narrow the list of vendors down to no more than 2-3 vendors that can be evaluated further.  This would typically include vendor demonstrations, reference checks, and additional due-diligence if desired. We generally recommend vendor demos and reference checks at a minimum, however.

6 – Conduct Vendor Demonstrations

Allowing those vendors that have made it through the first phase of selection to conduct a presentation and demonstration of their solution’s capabilities is another great opportunity to see how the vendor interacts with your team and in your environment.  For both the presentation and demonstration, the vendor’s should be asked to show capabilities that are of particular interest to the company and how those capabilities would be implemented in their environment. We usually recommend working closely with the vendors and providing clear guidelines in the lead up to demonstrations to ensure that each vendor understands what the company would like to get out of the presentations and demonstrations.

7 – Check Vendor References

We generally request a list of 4-5 references that are a similar size and complexity to the company performing the selection.  References should not be contacted until the vendors have been narrowed down to the final 2-3 candidates. In most cases, it will be best to notify the vendors in advance before contacting references. This will help to ensure that the contact specified as the reference will be available and ready to discuss their implementation and use of the vendor’s product.

8 – Select Vendor & Solution

Based on the outcomes of the RFP scoring, reference checks and vendor demonstrations it should be possible to make a final selection and move forward with contract negotiations, design, and implementation.  We recommend that companies inform vendors of their standing in the process at each step. It’s never a pleasant thing to have to call a vendor and let them know that they have not been selected to move forward but it’s far worse to leave them up in the air after they have put in the effort to respond to the RFP and otherwise support the company’s selection efforts.

An Alternative Approach for Consideration

In some cases, it may be preferable to not go through the process of issuing and scoring an entire RFP. We believe that a more streamlined approach may be considered when there are a limited number of vendors capable of meeting the company’s needs, or when it may be desirable to work with each vendor more closely during the selection (e.g. to complete a proof-of-concept as an example).  In these cases, we believe that it is still prudent to spend the time and effort to identify and document requirements thoroughly but instead of issuing the RFP, time would be spent in face-to-face or “whiteboard” meetings with the prospective vendors to develop a design and implementation plan that will best suit the company’s needs.

Summary

In many cases, companies that are selecting a CX/CEM or Contact Center solution are making a choice that will impact the company for 5-8 or more years. The time and effort that goes into the selection process will go a long way to ensuring that the vendor selected is capable of delivering on the company’s needs and expectations both in the short and longer-term.

For more information on our approach or to speak about a selection you are planning, please contact us at info@contactscope.com.  We would be happy to help out!