How to Write an IT RFP: A Step-by-Step Guide for Maryland SMBs

A request for proposal (RFP) is a written document that tells IT providers what you need, asks them all the same questions, and requires answers in the same format so you can compare them fairly. That is the whole idea. Done well, it turns a fog of sales pitches into a side-by-side decision. Done badly, it becomes a 40-page template nobody reads, answered by boilerplate nobody wrote for you.

This guide covers what to include, section by section, how to run the process on a realistic timeline, how to score responses, and the mistakes that sink most first attempts. It assumes you are a Maryland small or mid-sized business buying managed IT services, though the structure works for most IT purchases. If your need is a straight price check on a scope you have already defined, you may want the lighter-weight RFQ instead; our post on RFP vs RFQ covers the difference.

Before you write anything: know what you actually need

The most common RFP failure happens before the first word. If you cannot describe your environment and your goals, providers will guess, pad, or both. Spend a week gathering:

• Inventory. Headcount, locations, number of workstations and servers, cloud services in use (Microsoft 365 or Google Workspace, line-of-business apps), phone system, and who currently supports it all.
• Pain points. The three to five specific problems driving this purchase: slow response, a scare with backups, an audit finding, growth, a retiring IT person.
• Constraints. Budget range, compliance obligations (HIPAA, CMMC for defense-adjacent work, financial regulations), contract end date with any current provider, and internal politics worth knowing.
• Success definition. What will be measurably different a year after signing? If the answer is vague, the proposals will be too.

Larger organizations sometimes need a step before this one: deciding what to outsource at all versus keep in-house. That is a strategy question rather than an RFP question; it is the kind of analysis our composition strategy service exists for.

The eight sections of a working IT RFP

Section 1: Company overview and background

One page. Who you are, what you do, headcount, locations, and why you are issuing this RFP now. Providers price risk; the more clearly they understand you, the less padding lands in the number. You do not need to name your company in early drafts if confidentiality matters, but do name your industry and size honestly.

Section 2: Current environment

The inventory you gathered, cleaned up: users, devices, servers, network locations, cloud services, key applications, current backup arrangement, and current support model. Note what you know is broken. Providers will find out during onboarding anyway, and disclosure now buys you accurate proposals instead of change orders later.

Section 3: Scope of services requested

The heart of the document. Spell out what you are buying: helpdesk (hours, channels, on-site expectations), security services (be specific: endpoint protection, email filtering, MFA enforcement, awareness training, patching), backup and recovery expectations, cloud management, vendor management for your line-of-business apps, and strategic guidance like quarterly reviews or budgeting help. Separate must-haves from nice-to-haves explicitly. If a compliance framework applies to you, say which one and ask providers to describe, concretely, how they support it.

Section 4: Service level expectations

State the response and resolution expectations you want guarantees on, broken out by severity: full outage, degraded system, single-user issue, routine request. Ask providers to respond with their actual SLA terms and, critically, the penalty or credit when they miss them. An SLA without consequences is a brochure.

Section 5: Questions for the provider

This is where you learn who they are. Keep it to 15 or 20 pointed questions rather than 60 generic ones. Ask about team size and technician turnover, whether the helpdesk is in-house, references from clients your size in your industry, their own internal security practices, insurance coverage, onboarding process, and reporting. Our 15-question MSP checklist is a ready-made starting set; move the ones that matter most to you into the RFP so every provider must answer them in writing.

Section 6: Pricing format

Dictate the format, or you will get incomparable numbers. Require pricing broken out as: monthly recurring fee and its basis (per user or per device, with the count), onboarding or setup fees, what is out of scope and billed hourly at what rate, and pricing for the optional items you flagged. Ask each provider to state total first-year cost for your stated headcount. This single requirement does more for comparability than anything else in the document.

Section 7: Contract terms

Ask for term length options, termination provisions, what happens to your documentation and credentials at offboarding, and any auto-renewal language. Flag now, in the RFP, any term you will not accept, such as a multi-year lock-in with no performance exit. Providers negotiate more honestly when the dealbreakers are visible before anyone has sunk cost into the process.

Section 8: Process, timeline, and evaluation criteria

State the submission deadline, the format, who to send questions to, when finalists will be interviewed, and when you will decide. Publish your evaluation weights in broad strokes (for example: capability fit 40 percent, price 25 percent, references and stability 20 percent, contract terms 15 percent). Telling providers how you will judge them focuses the responses and signals that you are running a real process, which itself improves the quality of what comes back.

Running the process: a realistic timeline

• Weeks 1 and 2: Gather your inventory and write the RFP.
• Week 3: Send it to four to six providers, not fifteen. A giant distribution list produces shallow responses; a short list of plausible fits produces effort.
• Weeks 3 and 4: Answer questions. Share every question and answer with all bidders so nobody gets private information.
• Weeks 5 and 6: Proposals due. Score them against your published criteria before any interviews, so the in-person charm offensive cannot rewrite your reading of the documents.
• Weeks 7 and 8: Interview two or three finalists, check references, and negotiate with your first choice.

Two months feels slow when your current IT is on fire, but a rushed process signs a contract you will live with for years. If the house really is on fire, fix the emergency separately (an incident is a project, and can be handled as one under IT project management), then run the selection properly.

Scoring responses without fooling yourself

Build a simple scoring sheet from your Section 8 weights before proposals arrive. Have at least two people score independently, then compare. Watch for three specific traps: the halo effect, where great design and confident writing inflate every category; the lowball, where the cheapest proposal quietly excludes half of Section 3 (score against your must-have list line by line); and the incumbent discount, where familiarity with your current provider makes their weaknesses feel smaller than a stranger's. References beat prose: a mediocre proposal from a provider whose clients rave is usually the better bet than a beautiful document from one whose references are lukewarm.

Five mistakes that ruin first-time RFPs

• Copying a giant template. A 50-page government-style RFP for a 30-person company signals that you do not know what you want, and providers respond with boilerplate. Ten to fifteen pages is plenty.
• Hiding your budget entirely. You need not name a figure, but a range prevents proposals that are architecturally wrong for your spend.
• Letting providers set the pricing format. Unstructured pricing sections are incomparable by design.
• Skipping references because the proposal was impressive. The proposal was written by the sales team. The references lived with the delivery team.
• Treating the RFP as the finish line. The RFP gets you to a fair shortlist; interviews, reference checks, and contract negotiation still decide the outcome.

If you would rather not run this yourself

Everything above is doable in-house with a couple of weeks of focused effort, and for many Maryland businesses that is the right call. The honest tradeoff is time and market knowledge: knowing which providers to invite, what current market pricing looks like, and which SLA terms are actually negotiable is exactly the leverage a first-time buyer lacks. Running that process for businesses is what we do, both as a standalone RFP service and as part of a full broker engagement, at no cost to you.