What Your IT Services RFP Tells Vendors Before They Reply
Two requests for proposals landed in our inbox a week apart last spring. The first ran fourteen pages. It had every section a good RFP is supposed to have, a company background, a scope of work, a technical requirements list, an evaluation rubric, a submission deadline. We read it twice and still could not tell what the company actually needed. The scope said “managed IT support for approximately 80 employees,” and that was the most specific sentence in the document. So we did what any provider does with an RFP like that. We wrote back a careful, hedged, generic proposal, priced for the widest range of outcomes, because the RFP gave us nothing narrower to aim at.
The second one came from a Series A fintech in the Financial District. Six pages. It told us they were moving off a break-fix shop that took four hours to answer a ticket, that they had a SOC 2 Type II audit scheduled for Q3, that two of their engineers were quietly handling IT on the side and resented it, and that the founder wanted to stop thinking about laptops. It named the systems they ran. It told us what “good” looked like to them. Three of our engineers read it and wanted to win it, and we sent back a proposal with real numbers and a real plan in four days.
Same service, same provider, two completely different responses. The difference was not the length of the document or how many sections it had. It was how much each RFP let us see. After two decades of reading these on the receiving end, I can tell you the single thing that separates an RFP that gets fast, accurate proposals from one that gets slow, padded ones: how clearly it shows a vendor what you actually need and how you will decide.
What your IT services RFP looks like from the other side of the table
An IT services RFP is a document a company issues to solicit detailed proposals from managed IT providers for a defined scope of work, and the way it is written determines how fast and how accurately vendors can respond. Most advice on how to write an RFP for IT services is written from the buyer’s chair, telling you which sections to include. This is written from the other chair. We are the provider reading what you send, and every choice you make in the document changes the proposal you get back.
Here is the mechanic that buyers rarely see. When your RFP is vague, a vendor cannot price the actual work, because the actual work is unknown. So we price the risk instead. We pad the estimate to cover the version of the project that turns out to be twice as large as it sounded, we add hours for the integrations you did not mention, and we write proposals full of “depending on” and “to be scoped during onboarding.” That padding is not us being greedy. It is us protecting both sides from a scope we could not see. A clear RFP removes the unknowns, which removes the padding, which is how you end up with a number you can actually trust.
| Document | Question it answers | When to use it | What sending it signals |
|---|---|---|---|
| RFI | Who is out there and what is possible? | Early, exploring the market, building a shortlist. | You are still scoping and open to ideas. |
| RFQ | What does this exact thing cost? | Late, requirements fixed, price is the only variable. | Specs are locked; you want apples-to-apples pricing. |
| RFP | How would you solve this, and why your way? | Middle, you know the problem, want the methodology. | You want a strategic partner, not just a price. |
First, make sure you actually need an RFP
An RFP is one of three vendor documents, alongside the RFI and the RFQ, and each one answers a different question. Before you write anything, confirm you actually need the RFP and not one of its two cousins. The wrong instrument wastes everyone’s time, and to a vendor, sending the wrong one signals that the requirements underneath are not settled yet.
A Request for Information (RFI) asks “who is out there and what is possible?” You send it early, when you are still mapping the market and do not yet know what you need. A Request for Quotation (RFQ) asks “what does this exact thing cost?” You send it when your requirements are fixed and price is the only open variable. A Request for Proposal (RFP) asks “how would you solve this, and why your way?” You send it in the middle, when you know the problem but want providers to bring the methodology.
The common mistake is reaching for an RFP when an RFI would have served. You send a full proposal request to eight providers before you have decided what you need, and every one of us responds to a slightly different interpretation of the document, which makes the proposals impossible to compare. If you are still figuring out what managed IT even covers for a company your size, start with an RFI or a few discovery calls. Save the RFP for when you can describe the problem clearly.
The discovery work that shows up in your RFP
The most useful parts of an RFP come from work you do before you write a word of it, and a vendor can tell whether that work happened. Three pieces in particular show through in the document.
Define what the project is not
Scope creep is the quiet killer of IT engagements, and it usually starts in an RFP that only described what was included. PMI’s 2018 Pulse of the Profession found that 52 percent of projects experienced scope creep, up from 43 percent five years earlier. The fix is almost embarrassingly simple and almost nobody does it: write down what the project excludes. If you do not want us touching your AV systems, say so. If application support is out of scope, name it. Exclusions tell a vendor exactly where the edges are, and a proposal priced against clear edges is a proposal you can hold us to later.
Settle the final sign-off before you publish
We have watched well-run RFP processes stall at the finish line because the person who actually controls the IT budget was never in the room. The committee runs a clean evaluation, picks a provider, and then the founder or the CFO surfaces with a different idea about what this should cost or whether it is even the right time. From the vendor side, this is the most expensive kind of delay, because it lands after everyone has poured in real effort. Get the final signatory aligned with the scope and budget before the RFP goes out, not after the proposals come in. The hour it takes to walk them through it up front is the cheapest hour in the whole process.
Pull requirements from the people who live with them
The technical requirements in an RFP written entirely by leadership tend to miss the things that actually break people’s days. The end users know that the VPN drops every afternoon, that onboarding a new hire takes a week, that the shared drive is a mess. When those details make it into the RFP, our proposal can speak to the real problem instead of a sanitized version of it. When they do not, we find out about them in month two, and so does your budget.
Why vague questions get vague answers
The questions in your RFP are the single biggest lever you have over the quality of the proposals you get back. A yes-or-no question gets a yes-or-no answer, and yes-or-no answers tell you almost nothing, because every serious vendor says yes. Scenario-based questions, the kind that make a provider show their work, are how you separate the operators from the order-takers.
Three examples of the difference, drawn from questions we actually get asked:
Disaster recovery
Vague: “Do you provide disaster recovery?”
Sharp: “Lay out your proposed disaster recovery architecture for our critical applications. We need defined RTO and RPO targets, US-based data residency, and detail on how you test failover.”
The sharp version forces a vendor to reveal the depth of their infrastructure and whether they can actually meet your recovery and data-residency requirements. The vague version gets you a one-word yes from a provider whose “disaster recovery” is a nightly backup nobody has ever restored.
Email migration
Vague: “Can you migrate our email?”
Sharp: “Describe your phased approach to migrating 80 mailboxes from on-premise Exchange to Microsoft 365, including how you handle delegate permissions and mailbox archives over 50GB.”
Migrations fall apart in the details, the shared mailboxes, the calendar permissions, the archives that are too big to move cleanly. We took on one a while back that the RFP described in a single line, migrate our email, roughly 80 mailboxes. It sounded like a weekend. Then we got in and found a tangle of delegate permissions nobody had documented and one executive archive north of 90GB that choked every tool we threw at it.
What should have been a weekend turned into the better part of a month. None of that was in the RFP, and to be fair, the client did not know to put it there. But a sharper question on their side, or a discovery call, would have surfaced it before anyone signed. A question that names those details tells you whether a vendor has done this at your scale or is about to learn on your environment, on your clock.
Security
Vague: “Is your service secure?”
Sharp: “Describe your security hardening process and how you monitor for threats. Provide your current SOC 2 Type II report, and if you support clients under HIPAA, describe how you handle that.”
Asking for the SOC 2 Type II report by name moves a vendor from promises to proof. Any provider can claim to be secure. Far fewer can hand you a current third-party attestation, and for a company heading into its own SOC 2 or operating under HIPAA, that distinction is the whole ballgame.
The pattern across all three: name the system, name the standard, and name the number. Specific questions cost you a little more time to write and save you weeks of discovering what a vendor cannot do after you have already signed.
What vendors read into your budget and timeline
Your budget and your timeline are the two numbers a vendor reads most carefully, because together they tell us whether you have thought this through. Get them right and the proposals come back fast and priced to reality. Get them wrong and you invite exactly the padding and delay you were trying to avoid.
Disclosing a budget range gets you accurate proposals, not inflated ones
The most common worry we hear is that sharing a budget invites vendors to spend all of it. The opposite is closer to the truth. When you tell us the budget, we can design a solution that fits it, and we can tell you when your expectations and your number do not line up. When you hide it, we are guessing, and we guess wide, which means half the proposals you get are priced for a project you cannot afford and the other half are priced for one that will not do what you need. A budget range is not a weakness in your negotiating position. It is the fastest way to get proposals that are actually comparable.
Ask for the pricing broken out, so you can compare like with like: one-time costs for implementation and onboarding, recurring monthly costs for ongoing support, and the cost of any scope you might add later. A vendor who will not itemize is a vendor whose number you cannot interrogate.
An honest timeline gets honest responses
A timeline tells a vendor how seriously to take the document and how much of their best thinking to invest. Build in a real question-and-answer window, a fair amount of time to actually write the proposal, and an evaluation period you intend to honor. When you demand a complex managed-services proposal in five business days, you are not getting faster proposals. You are getting whichever vendors had a stock response ready to paste, which is rarely the same set as your best-fit providers. Tight, arbitrary deadlines read as internal chaos, and internal chaos is exactly what a careful provider is trying to avoid signing up for.
| Criteria | Weight | What it measures |
|---|---|---|
| Technical fit | 40% | Ability to meet your must-have requirements and technical constraints. |
| Cost and value | 30% | Long-term value and transparency of the itemized pricing. |
| Experience | 15% | Track record with similar companies and relevant certifications. |
| Support and SLA | 10% | Response times, escalation paths, and quality of ongoing support. |
| Innovation | 5% | Useful ideas you did not ask for but are glad to hear. |
Tell vendors how you will score
State your evaluation criteria, and their weights, inside the RFP. This is one of the highest-leverage things you can do, and it works entirely in your favor. When a vendor knows that technical fit counts for 40 percent and price for 30, they aim their proposal at what you actually care about instead of guessing. You get responses concentrated on your real priorities rather than a scattershot pitch that buries the answer you needed under features you did not ask about.
A weighting that works well for most managed IT engagements looks like this. Adjust the numbers to your situation, but publish whatever you choose.
Disclosing the criteria is RFP-stage work. Actually running the evaluation once proposals arrive, scoring vendors against each other, checking references, comparing total cost of ownership, is its own discipline, and we wrote a full guide to it here: Guide To IT Services Vendor Evaluation and Selection. One practice worth borrowing from it now, because it belongs in the RFP itself is that if one vendor asks a clarifying question, share the anonymized question and answer with every bidder at once. It keeps the field even and it keeps your own requirements consistent across the proposals you get back.
The RFP that gets you fast, accurate proposals
Pull all of it together and the RFP that works is not the longest one or the one with the most sections. It is the one that lets a vendor see clearly what you need, how you will decide, and what you can spend. Here is the short version, with the payoff to you next to each item.
Pick the right instrument. RFI to explore, RFP to choose a partner, RFQ for fixed-spec pricing. The right one gets you responses you can actually use.
Define what is out of scope. Exclusions are what protect your budget from creep later.
Align your final signatory before publishing. It is the difference between a decision that sticks and a process that restarts.
Ask scenario-based questions. Name the system, the standard, and the number. Specific questions get specific, comparable answers.
Share a budget range. It gets you proposals priced for the project you can afford, not padded for the one you cannot see.
Set a realistic timeline. Enough time to respond well is how you reach your best-fit providers instead of whoever had a stock answer ready.
Publish your scoring criteria. Vendors aim at what you weigh, so you get proposals focused on what matters to you.
None of this is about impressing anyone. It is about cause and effect. Every signal your RFP sends either speeds up the response and sharpens the scope, or it slows things down and pushes vendors toward hedge-everything bids. The better the document, the faster and more accurate the proposals, and that is true no matter which provider you end up choosing.
Get help scoping your IT services RFP
We read these from the other side of the table every week, and we are happy to help you write one that gets you the proposals you need, whether or not Jones IT is on your list. If you are a Bay Area startup or scaling tech company sorting out managed IT, reach out to us and we will walk you through it. And once the proposals come in, our guide to IT services vendor evaluation and selection picks up where this leaves off.
About The Author
Evan JonesFounder and CEO of Jones IT
With over two decades of IT experience in San Francisco, Evan guides Jones IT's long-term strategy, finances, and culture, with a vision of building the city's highest-rated IT services firm. Outside of work, you'll find him on the golf course or running Bay Area Warriors, his non-profit connecting Bay Area kids to college through basketball.