Sample RFP

This section contains a sample RFP structure that you can customize if you wish to use an RFP process. RFPs are massive documents because each and every item in the requirements list will need to be translated into an RFP question. This sample simply refers to the requirements list when appropriate to avoid needless repetitions, but shows the other sections in detail. Many companies have standards for RFPs so use the suggestions here to augment the process that already exists in your organization if there is one. RFPs are organized as follows:

  • A cover page
  • A cover letter
  • RFP instructions
  • Company information
  • Vendor qualifications
  • Product overview
  • Technical requirements
  • Functional requirements
  • Implementation and maintenance requirements
  • Pricing information include configurations, often spreadsheet
  • Appendices: vendor exhibits

Let's explore what each section contains.

Cover Letter

The cover letter is simply a transmittal memo that summarizes the purpose of the RFP, orients the vendor to the way the RFP is packaged, and states the basic requirements for responding to the RFP.

Vendor Contact
Vendor Name
Vendor Address

Dear Vendor

We have selected you as a candidate vendor to provide a proposal for a 
CRM app.

This package contains complete instructions for preparing and sending the 
completed proposal. Please follow the instructions exactly so we can easily 
evaluate your responses as well as the other vendors' in an objective manner. 
I am available to answer any questions that may arise. I can be reached 
by e-mail or by phone.

Please return your completed proposal by Date. We will be unable to consider 
proposals received after that date.


Project Manager Name
Organization Name
Phone Number

RFP Instructions

This section describes how the RFP process will work and gives specific instructions on how to respond to the proposal.

Proposal Guidelines

Start by giving a short summary of the context of the RFP: why are you interested in a CRM tool? What are you trying to achieve? What target dates do you have in mind? This is only a summary so the vendor can confirm its interest in preparing a response. A more detailed description is included in the next section. Then, give the following factual information about the process:

  • Contacts and communications (on your side). Who will be able to help the vendors with questions?
  • Evaluation and selection process: how will the RFP process be run and what criteria will be used to perform the evaluation?
  • RFP and selection schedule. This is not a formal commitment to making a decision by a particular date, but it's useful for the vendor to understand your general timeframe. RFPs for CRM systems rarely exceed a couple of months for preparing the answer, and another month or two for reaching a decision.
  • Effective dates of pricing: give yourself plenty of time in case the selection process is delayed.
  • Legal considerations for the RFP. Ask your legal team to confirm what is best to include here. Almost always there is a so-called "right to reject" clause, stating that you are free to make a decision on any basis, including deciding not to make any purchase at all, with no recourse possible for the vendors.
  • Confidentiality: it is customary to ask the vendors to keep the RFP confidential and to commit to keeping the answers confidential except as required to make a decision.
  • Costs: vendors should bear all costs of responding to the RFP.
Vendor Instructions

Give instructions to the vendor on how to complete the RFPs, typically to provide clear and concise answers, to use the rating scorecards for the technical and functional requirement sections, and perhaps to provide pricing in a spreadsheet format. State that the RFP answer will become part of the contract. Give detailed instructions on when to respond and how. Electronic responses are common and they are often preferred because they can be shared easily. State any format requirements.

Company Information

This section gives the vendors information about your organization. It's important because it sets the tone for the proposal and it allows the vendors to tailor the RFP to your particular needs. The company information section should include the following subsections:

  • A company profile including the market you serve and the goals of the business (one or two pages).
  • Your existing technical environment including corporate standards, apps, database management systems, workstations, network topology, and vendors for all of the systems. Information about how the systems are administered is not always given, but I find it very helpful to include it as well.
  • A description of the business functions to be served by the CRM tool. For each business function, include its specific role within the organization ("Partner Sales" may be obvious to you, but maybe not to the vendor), its staffing level and reporting structure, the locations, goals, measurements, and anything else that pertains to how the system should work. Define whether the tool is replacing an existing tool, and if so why. Include your business goals for the new system. This section can be several pages long for a complex CRM project.

Vendor Qualifications

This section asks the vendors to describe their corporate fitness to meet the requirements. Many of the questions are taken from the "Vendor Requirements" section of the requirements list. Many deserve the full written answers that are asked since they don't lend themselves to the scoring system we will see later for the technical and functional requirements.

Vendor Profile

This section typically starts with a free-form statement from the vendor. I recommend limiting the length here for fear of getting back a very long and not very relevant expose. It is useful to get a feel for the history of the company, though, as it can indicate much about the vision and the executive team. After the overall statement, questions in this section include:

  • Business vision
  • Financial history (typically you want to request the financial statements for the last two or three years)
  • An overview of the products offered (limit the length here again!)
  • Industry experience: does the vendor have similar clients?
  • R&D investment: how much is the vendor investing in developing new products and new technologies
  • Geographical location of development, sales, and support offices
  • Partnerships with relevant vendors
  • User group
  • ISO 9000 compliance
  • Product awards
Product strategy

Ask the vendors to explain their plans for new releases, new markets, and new customers. Place a limit on how many pages you will consider or ask specific questions to avoid getting massive amounts of information that's not directly useful. I recommend asking both for a long-term plan (say 3-5 years) and for the contents of the next major release, which should be firmer.


Specify type of customer, location, configuration, etc. We'll discuss references more fully in . Ask the vendor to provide contact information for each reference.

Contractual Terms

An RFP is not the place to negotiate detailed contract terms, so your goal is to gather information on standard terms so you can get ready to negotiate. If specific terms and conditions are important to you, by all means include them in the RFP. Specifically request:

  • The terms of a standard contract
  • Acceptance criteria
  • Warranty information
  • Non-disclosure protections
  • Payment terms
  • If the vendor may provide implementation services, terms and conditions for the implementation, including a statement of work, ownership of the finished product, and warranties on the work and on the milestones.

Product Overview

Provide an overview of the recommended system.

Technical Requirements

The technical requirements section, like the Functionality Requirements section that follows it, is usually constructed to match exactly the requirements list you created. Both require the vendor to answer each question in detail as well as rate its ability to match the requirements in a scorecard similar to the one we showed in the last chapter when we discussed requirements. Questions take time to create, which is one of the main reasons why the RFP process is resource-intensive—the other reason is the scoring—but they are often necessary to communicate the nuances of each requirement. Compare the following RFP question:

Describe your technical architecture and how it supports scalable deployments. If several options are available, describe the ones that are better able to meet our requirements as discussed in the statement of work section.

with its corresponding, terse item from the requirements list:

Scalable architecture

It's clear that you will get more information from the question than the item as is. And, at the same time, it will take you much longer to interpret and score the answer to the question than to look at the rating. Whenever possible, use short and precise questions to increase your chances of getting unbiased information. Start the section with instructions on rating the items. It's usually very dangerous to use a simple yes/no rating system, since anything that's remotely possible will be rated with a "yes". Most RFPs use a system similar to this one with four categories:

  • Features that are available today in the out-of-the-box product
  • Features available in future releases (the vendor should specific both the release name and its targeted date)
  • Features that require minor modifications (no coding)
  • Features that require major modifications (coding)

Functional Requirements

This section is by far the longest in the RFP, matching its length in the requirements list. Proceed as you would for the technical requirements section, asking vendors to provide both written answers and ratings.

Implementation and Support Requirements

This section explores the implementation and support requirements per the requirements list you created. If you expect the vendor to provide implementation services, you will probably have to create a separate statement of work and negotiate it separately, but you can ask about high-level information in the product RFP. Even if you are completely certain that the vendor will not be the integrator, it's useful to get the vendor's high-level estimates of what an implementation would consist of so you can use it when selecting an integrator. Here are items to request for the implementation:

  • Overview of implementation project
  • Technical requirements
  • Sample project plan with schedule and deliverables
  • Strategies for each major phase: planning, requirements gathering, testing, rollout
  • Suggested staffing including qualifications and roles
  • Recommended strategies for minimizing maintenance requirements of customized tools

For training, request the course list, complete course descriptions, pricing, end-user training options, and the availability of a train-the-trainer program. Request recommended backgrounds and custom curriculum suggested for system administrators and implementers. Request training schedules and course availability: if courses are always tutorialed, your technical staffers may need to wait for a long time before they can be useful. You may want to request sample user documentation in the RFP. For support and maintenance, be sure to detail the requirements down to the SLA (service-level agreement) level.


Request firm pricing quotes for the configuration(s) you require. It's useful to request several quotes for different configurations, as it may be advantageous to purchase a license for slightly more users than you currently have. Quotes should include implementation (if provided by the vendor), maintenance, and other services such as training. Request future pricing information as well. For instance, are maintenance price increases capped? How will maintenance be computed in the future?