Shelly Spiegel

CEO & Chief Creative Officer

(Part 2 of a series of 5)

Welcome to Part 2 of my five-part series on choosing an admissions CRM! (In case you missed it, here’s why I wrote this series.)

In this post, I’ll tell you why the Request for Proposal (RFP) process often leads to a disappointing outcome.

Admissions offices (especially state institutions) typically spend as much as a year going through the RFP process to select a CRM. Now, imagine putting in all that time, and still being unhappy with, or caught off guard by, the outcome! Believe me, it happens. All. The. Time.

Why? Because so much crucial information comes to light only AFTER the RFP process is complete.

Let’s take a look at the top six problems involved with RFPs …

1. RFPs leave out some really important questions.

RFPs typically include hundreds of questions about features and functionality, and the vendor that checks off the most boxes, or responds “yes” the most times, is likely to win. However, a vendor’s philosophy, culture, and values, along with other hard-to-quantify but essential factors, aren’t often captured in an RFP … and these factors are critical to a successful long-term partnership with your CRM vendor.

2. RFPs only ask WHAT, not HOW.

RFPs ask a lot of questions about WHAT the CRM does, but don’t ask HOW the CRM actually does it. For example, RFPs don’t tell you if a CRM is able to adapt to your admissions office’s processes. RFPs don’t tell you how many steps it will take to do a given task. RFPs don’t tell you if the functionality you’ll use most often is part of what the CRM was originally designed to do, or if you can only accomplish your tasks through workarounds. Also, RFPs don’t tell you which tasks users can accomplish without assistance from an administrator.

3. RFPs often prioritize the bells and whistles.

A common IT adage is that 80 percent of all software users generally use only 20 percent of a software product’s features and functionality. Yet, many RFPs focus too much on the bells and whistles rather than on the essential features and functionality an admissions office needs to get its job done. Remember, no admissions CRM, or any software for that matter, does it all.

4. RFPs don’t ask how a CRM is different.

Most admissions CRMs offer similar features and functionality; what RFPs don’t usually ask is, “How is your CRM different from the dozen or so on the market?” Instead, RFPs ask about the features and functionality most CRMs currently have. This means you could possibly go through the entire RFP process, without ever finding out about some of the most innovative and future-friendly features and functionality a CRM includes.

5. RFP weightings don’t align with admissions goals.

IT department requirements – put in place to save time for the IT department – are often weighted more heavily than admissions requirements. This can result in admissions offices being forced to go with a CRM that makes it more difficult for them to get their job done, and thus harder to meet their enrollment goals. All just to serve IT’s interests!

6. The most qualified vendor(s) may decline to participate.

Because responding to an RFP can consume so much time and so many resources, a complex RFP – with hundreds of detailed questions – may discourage the best vendors from responding. When this occurs, RFP committees may only have a handful of less-qualified vendors to choose from; this can lead to a “failed RFP” and force a school to start all over again (really, it happens).

Next, I’ll share with you The 3 Things to Do BEFORE Writing an Admissions CRM RFI or RFP (Part 3 of this series).

Shelly Spiegel has nearly 30 years of experience in the education market – including 15 years as CEO & Chief Creative Officer of the company she founded, Fire Engine RED.