How to Write an RFP Vendors Can't Answer With a Brochure

You sent the RFP. Six responses came back. Six brochures.

Every proposal says the solution is secure, scalable and easy to implement. Every one has a glossy architecture diagram and a "contact sales" button where the pricing should be. And you are left comparing marketing copy instead of answers.

That isn't the vendors' fault. If your RFP lists 40 features with no priorities, no scoring weights and no dates, the easiest response is the standard pitch deck. The fix is structural, and it works the same whether you're buying UCaaS and contact center, SD-WAN, managed security or cloud.

Step 1: Define exactly what you're buying

Vague scope produces vague proposals. Before you write a single requirement, pin down the facts a vendor needs to quote and plan against:

• Category. One RFP per category. Bundling UCaaS, SD-WAN and security invites a provider who is strong in one and passable in the others.
• Size. Users and locations drive both price and implementation time.
• Target go-live. The date you need to be live, not the date you'd like to start. Everything else works backward from it.
• Contract term. One, three or five years. Term changes pricing and which contract protections matter.
• Regulations. HIPAA, GLBA and NCUA, PCI DSS, CMMC. Each one you answer to becomes a mandatory requirement, not a footnote.

Step 2: Mark every requirement must, should or nice-to-have

A flat list tells vendors everything matters equally, which means nothing does. Give every line one of three priorities, and leave out anything you'd skip.

Write requirements as testable statements, not wishes. "Number porting with a tested cutover plan and no downtime" can be answered yes or no; "seamless migration" cannot.

And don't forget the contract. Pricing locked for the full term, SLA credits with a right to exit for chronic failures, and termination rights with a full data return at no charge belong on the list as must-haves, not as something legal will "handle later."

Step 3: Set your scoring weights before responses arrive

Weights set after the proposals come in tend to drift toward whichever vendor gave the best demo. Pick five or six factors and make them add up to 100%. A balanced starting point for a communications project:

Two things to watch. If total cost carries more than 40% of the score, you're running a price auction and will get the cheapest bid that technically qualifies. And publish the weights in the RFP: vendors who know how they'll be scored write to the score instead of to their brochure. Score each factor on a 1–5 scale and multiply by its weight.

Step 4: Build the timeline backward from go-live

Most RFP timelines start from today and hope. Start from your go-live date instead. The date that matters is the latest day you can issue the RFP and still make it.

For the 450-user, 14-site credit union, implementation runs about 13 weeks. A May 12 go-live means the RFP has to go out by December 2:

Implementation time depends on what you're buying. Typical ranges MALA sees for mid-market projects:

Put these dates in the RFP. A vendor who can't meet your questions deadline is telling you something about how the implementation will go.

Step 5: Run a scope check before you send

The expensive RFP mistakes are visible before the document goes out. Run four checks:

An RFP gets back exactly what it asks for. Ask for specifics.

Build yours in six minutes with the free RFP Builder

MALA's RFP & Requirements Builder does all five steps in one place:

• Pick UCaaS and contact center, SD-WAN, managed security, or cloud and colocation. Each opens with a worked example you can edit.
• Enter users, sites, go-live, term and regulations. Each regulation adds its mandatory requirement automatically.
• Mark every requirement must, should, nice-to-have or skip, and set weights that always add to 100.
• Get your latest issue date, a dated timeline and a scope check, plus a summary for your project sponsor.

Then unlock the full draft: an eight-section RFP outline with your scope, dates and requirements filled in, a weighted scoring matrix with disqualification rules, and a requirements sheet that pastes into Excel. Not sure an RFP is the right route at all? Three Ways to Buy compares the options, and our 15 questions to ask at project kickoff help before you write a word.

RFP FAQ for IT leaders

How long should an IT RFP be?

Long enough to cover scope, requirements, scoring and dates, and no longer. Length that doesn't change a vendor's answer is padding.

How many must-have requirements should an RFP have?

At least three, and no more than about 60% of the total. Fewer screens nobody out; more disqualifies everyone.

Should I share scoring weights with vendors?

Yes. Published weights get answers aimed at what you value instead of a generic pitch.

How long does an RFP take from issue to award?

About 10 weeks for a typical mid-market project, plus two weeks to write and approve it and the implementation time for the category.

Source: timelines, implementation ranges, scope-check rules and example figures are from MALA's RFP & Requirements Builder, based on typical ranges MALA sees for mid-market projects. Circuit lead times can extend network projects.

For informational use only. Not legal advice.