RFP vs POC: Why the proof of concept is replacing the request for proposal

Say goodbye to bait-and-switch tactics and say hello to the enterprise version of the free trial.

We’ve seen companies get burned time after time with bait-and-switch tactics and have to live through multi-year contracts with a technology vendor that they hate. Believe it or not, it’s possible to choose an email service provider (ESP) that you’ll love, and the proof of concept is one of the key ways to help you do so.

Try-before-you-buy isn’t just reserved for SMBs. The proof of concept (POC) model is helping companies evolve from the traditional request for proposal (RFP) to adopt technology they love.

What is a request for proposal (RFP)?

A request for proposal (RFP) is an open bid in which a company announces that funding is available for a particular project or program, and vendors can place bids for the project’s completion.

Essentially, an RFP answers specific questions about how a vendor will meet needs and goals of the requesting company. These lengthy documents include detailed information on requirements like function, workflow, business goals, and integration specs to the vendors. It outlines the bidding process and contract terms, and provides guidance on how the bid should be formatted and presented.

The RFP often includes:

• Scope of work (SOW)
• Pricing information
• Price quote
• Contract terms and conditions
• Detailed reference information

An evaluation tool such as a weighted factor matrix might also be used that considers the relevancy and weight of predetermined criteria. This approach helps to provide a level playing field in terms of evaluating products and services by factors other than just price.

An RFP could also be used in conjunction with an RFI (request for information) and RFQ (request for quotation), or those might be included in an RFP, depending on the company’s preference.

What is a proof of concept (POC)?

A proof of concept (POC) is a demonstration of an idea or service to verify its feasibility. In layman’s terms, it’s the ability to show or prove that something actually works. And especially in marketing, that is crucial.

In the world of marketing technology, a POC is used as a pilot program for a company to use a vendor’s technology in a controlled environment to replicate real use cases. The purpose is to test the technology, plug in real data, and use it as if it were for actual day-to-day work.

Oftentimes, the vendor and company may agree to structure the POC to be within a limited time, a set number of users, and specific access to features and functionality. A company would enter a POC with a set of use cases and features they want to validate, and then the vendor would assist the company in proving that those use cases and features are indeed valid.

Why use a POC instead of an RFP?

While an RFP is a great way for companies to initially vet vendors and weed out the ones who are certainly not a good fit, it’s not a great way to determine which vendor is a good fit. Technical specs and feature sets may look good on paper, but they could be a different story in the actual technology.

The key disadvantage in RFPs is that they take an enormous amount of time and energy. In many cases, the RFP process can take over a year to complete, and it’s not uncommon for it to conclude with the company choosing to stay with their current technology provider.

Choosing technology based on an RFP alone has also led to a history of shady practices, leaving companies burned with bait-and-switch tactics. Over time, marketers have gotten more and more skeptical about what technology vendors say they can do versus what they can actually do.

The POC puts the power back into the marketer’s hands, giving the company leverage over vendors by forcing vendors to prove their worth and function.

It’s also a technical validation that the vendor is the right solution for the company and gives them an opportunity for their engineers to get involved with the technology, instead of just looking at API documentation or getting on a call with a sales engineer and getting a brief overview.

For example, in the case of choosing an ESP or messaging platform, a POC gives the company an opportunity to play with the UI and make sure that everything is feasible with:

• Throughput and scalability
• Managing content
• Using modular templates
• Triggers and automations
• Testing
• Optimization and more

Instead of being transactional in nature like the RFP, a POC is a collaborative process between the vendor, the company and all its buyers to align on key use cases and success metrics. In most cases, the POC will last anywhere from one to four weeks to validate the vendor and explore edge cases before signing a long term agreement.

The most valuable aspect of the POC is transparency.

It’s a win-win for both the company and vendor, as the company gets a no-strings-attached experience of the vendor and the vendor gets to technically prove themselves as the best solution. And the biggest wins are mutually shared expectations, trust, and alignment across the organization. So what that boils down to is not having to relive the nightmare of making a decision that isn’t aligned with the business objectives or doesn’t scale long term.

Cordial provides POCs for companies so that they can make the best possible decisions for their business. If a company completes a POC that doesn’t result in a Cordial relationship, that’s okay because ultimately Cordial is in the business of helping companies succeed.

So take a second look at your RFP and consider requesting a POC from the vendors you’re evaluating so you can get a genuine experience in the technology to prove that it’s the right solution for you.

Interested in seeing how Cordial is helping leading companies drive scalable revenue and lasting customer connections? Schedule a demo with our team to learn more.