RFP management: ask the right questions, get answers you can compare

What an RFP is, in plain English

A request for proposal is a written document that describes your business, your requirements, and your constraints, and asks providers to explain how they would meet them and at what price. It replaces the usual pattern, where every vendor pitches whatever they normally sell, with a structured one: everyone answers the same questions, so you can put the responses side by side and see real differences.

For IT purchases specifically, the RFP is the buyer's best tool for cutting through marketing language. Every MSP says they offer "proactive support" and "enterprise-grade security." An RFP forces specifics: response times in writing, the actual security stack, references from businesses like yours.

When you actually need one

• Choosing a new MSP. The most common case. If you're hiring or replacing a managed IT provider, an RFP is how you compare candidates on substance instead of charm. It's a core step in our brokering process.
• Major projects. A cloud migration, a new phone system, an ERP implementation. Anything with a five-figure price tag and more than one credible way to build it deserves competing proposals.
• Compliance-driven purchases. If you're subject to HIPAA, CMMC, insurance requirements, or a client's security questionnaire, the RFP is where you make those obligations explicit so providers commit to them in writing before you sign.

Not every purchase needs this. When the need is already well defined and you just want prices, a simpler RFQ is faster and gets you further.

What a bad DIY RFP looks like

We've read a lot of them. The failures repeat:

• Vague scope. "We need better IT support" invites proposals that range from $2,000 to $20,000 a month, none of them comparable, because each vendor guessed at a different problem.
• Wrong recipients. Sending a 30-person company's RFP to national enterprise providers, or a compliance-heavy one to generalists, wastes weeks. The document is only as good as the list it goes to.
• Unanswerable questions. Questions copied from an enterprise template ("describe your ITIL maturity model") that small providers can't answer and that don't predict whether they'll pick up the phone at 7 a.m. when your server is down.
• No scoring plan. If you don't decide what matters before responses arrive, the glossiest PDF wins by default.

How we run it

• Requirements workshop. A working session to pin down scope: users, locations, systems, compliance obligations, budget range, and what "good" looks like for your team.
• Drafting. We write the RFP in plain language, sized for the providers who will read it. You approve it before anything goes out.
• Targeted distribution. It goes only to vetted providers who fit your profile, drawn from our Maryland network. No blast lists.
• Scoring matrix. Weighted criteria agreed with you in advance, so responses are scored against your priorities, not against each other's formatting.
• Plain-English summary. One document comparing the responses: what each provider proposed, what it costs, where the gaps are, and what we'd push back on.
• Finalist support. We sit in on finalist interviews, help you check references, and negotiate terms before signature.

What it costs

Nothing. RFP management is part of our brokering service, and the whole service is free for the Maryland businesses we work with: providers compensate us when a match succeeds. You get the document, the responses, the scoring, and the summary, and they're yours to keep whether or not you hire anyone from the process.