How to Read an MSP Proposal: Line-by-Line Guide

A managed IT proposal looks dense and intimidating on first read. There’s a glossy cover, a 2-page executive summary, a SOW (statement of work) full of acronyms, a pricing table that doesn’t quite tie back to the SOW, an SLA that may or may not be real, and a master services agreement appended at the back. Most buyers read the first page carefully, skim the rest, and sign.

That’s the most expensive mistake in IT buying. Knowing how to read an MSP proposal — section by section, what to question and what to push back on — is the single highest-leverage skill in this purchase. This guide walks you through every standard section of a typical proposal.

What’s in a typical MSP proposal

A typical proposal has six sections, in roughly this order:

1. Cover and executive summary — the marketing layer
2. Discovery findings and recommendations — what they learned about your environment
3. Statement of work (SOW) — what they will and won’t do
4. Pricing — the fees, schedule, and how they may change
5. Service Level Agreement (SLA) — performance commitments
6. Master Services Agreement (MSA) — the legal contract terms

Each section deserves a careful read for different reasons. Below is what to look for in each.

Section 1: Cover and executive summary

What it is: the marketing layer. A 1–3 page narrative summary of why this provider is the right choice for your business, often with quotes, stats, and a high-level pitch.

What to read for:

• The named owner. Who at the MSP is signing off? Is it the CEO, a VP of Sales, or a generic “Solutions Team”? A named, accountable senior leader matters.
• The “we understand your business” claim. Real proposals demonstrate this with specifics from discovery. Generic claims (“we serve clients in your industry”) with no specifics suggest the proposal is largely templated.
• The pitch language vs. the SOW. The summary often promises more than the SOW commits to. Margins for “vision,” “partnership,” and “innovation” don’t appear as line items later. What’s promised here is not what you’ve been sold.

What to push back on: vague language without measurable commitments. If the executive summary uses words like “world-class,” “best-in-class,” or “industry-leading” without naming a measurable standard, ask what specifically those phrases mean.

Section 2: Discovery findings and recommendations

What it is: a written summary of what the MSP found when they assessed your current environment. This often includes security posture, identified risks, vendor inventory, and recommendations for the first 90 days.

What to read for:

• Specifics about your environment. A real discovery references your actual systems, not generic SMB findings. If the discovery section could be sent to any SMB without modification, no real discovery happened.
• Findings that show they actually looked. Examples: “your backup hasn’t completed in 11 days,” “MFA is missing on 12 admin accounts,” “your firewall firmware is 2 versions behind.” Vague findings (“we noted opportunities to improve security posture”) suggest a shallow assessment.
• Recommendations tied to findings. Each recommendation should reference a specific finding. Recommendations that float free of findings (“we recommend deploying our standard security stack”) are sales pitches in disguise.

What to push back on: a discovery section that reads like a brochure for the MSP’s services. Ask: “Can you show me three specific findings from my environment that drove these recommendations?” If they can’t, the discovery wasn’t real and the rest of the proposal will be similarly templated.

Section 3: Statement of work (SOW)

What it is: the most important section in the entire proposal. A defined scope of what the MSP will and won’t deliver each month, plus what is “in scope” vs “out of scope.”

What to read for:

• Specific deliverables. “Monthly patching” is too vague. “Monthly patching of all Microsoft Windows endpoints and Microsoft server systems, with patches deployed within 14 days of vendor release for high/critical severity, with monthly compliance reporting” is a real commitment.
• Inclusions vs exclusions. Almost every SOW has an “out of scope” list. Read it carefully. Common gotchas in the out-of-scope list: project work over a defined hour threshold, custom application support, hardware procurement, after-hours work above a defined volume, security incident response.
• The line between “support” and “project.” This is where most surprise bills come from. The SOW should define exactly what counts as a project (typically: anything taking more than 4 hours, anything requiring a planned change window, anything touching multiple systems). If the line is fuzzy, your bill will be too.
• Quarterly business reviews and strategic planning. Are these included in the monthly fee, or marketed as an upgrade? If marketed separately, push to either include them or reduce the base fee accordingly.

What to push back on:

• Vague deliverables without measurable units (hours, frequencies, completion criteria)
• Out-of-scope items that should be in scope for what you’re paying — for example, security incident response is increasingly considered table-stakes
• Missing items entirely — if the SOW doesn’t mention something you assumed was included (vendor management, license renewal tracking, password reset processes), it isn’t

Section 4: Pricing

What it is: the fee schedule, billing terms, and any price escalation clauses.

What to read for:

• The headline per-user fee vs. the total monthly fee vs. the total contract value over 36 months. They will differ.
• Bundled services — what licenses or third-party tools are included in the per-user fee, and what are billed separately?
• License markup — what’s the MSP charging for Microsoft 365 / Google Workspace licenses vs. direct-from-vendor pricing?
• Onboarding fee — is there one? Is it itemized? Is it capped?
• Hourly rates — for project work, after-hours support, incident response. These should all be specified, not “TBD” or “industry standard.”
• Annual price escalators — does the contract include automatic price increases? If so, by how much, and is there a cap?
• Payment terms — net 15, net 30, prepayment discounts?

What to push back on:

• Annual escalators above 3–5% with no cap. “CPI plus 3%” with no ceiling is open-ended.
• Project hourly rates without minimum bill. Time-and-materials with no cap means you carry all the cost risk; demand a not-to-exceed quote on every project over a threshold (commonly $1,500).
• License markup that wasn’t disclosed. If you’re paying $X per user for M365 and the MSP is paying $Y direct, the difference should be visible.

A separate guide covers all nine common cost categories in more depth: Hidden Costs of Managed IT Services.

Section 5: Service Level Agreement (SLA)

What it is: the performance commitments — response times, resolution targets, uptime guarantees, and what happens when the MSP misses them.

What to read for:

• Severity tier definitions. Are tickets categorized by severity?
• Response time and resolution time per severity. Concrete numbers, not “prompt.”
• Coverage hours per severity. 24/7 vs business hours, defined.
• Credits for missed targets. A real consequence if they miss.
• Exclusions. Reasonable list, not over-broad.
• Reporting cadence. Monthly, automatic, sent to a defined recipient.

A separate guide covers the structure of real SLAs in detail: MSP SLAs Explained.

What to push back on:

• Soft language like “commercially reasonable efforts” — this is legalese for “no commitment”
• No credits for missed targets — without a remedy, the SLA isn’t enforceable
• Vague uptime claims without defining what’s measured

Section 6: Master Services Agreement (MSA)

What it is: the actual legal contract. This is what you’re signing.

What to read for:

• Term length and auto-renewal. Is it 1 year, 2 years, 3 years? Does it auto-renew? For how long? With what notice required to cancel?
• Termination clauses. How can you exit? With what notice? What fees apply?
• Termination assistance fees. Some MSAs charge thousands of dollars in “transition assistance fees” if you leave. Negotiate this clause first — before discussing onboarding terms.
• Ownership of credentials, documentation, and tenants. You should own your domain registrations, M365 tenant, password vault, and documentation outright.
• Data ownership. Your data is yours. Backups of your data are also yours. Exit terms must guarantee return.
• Liability cap and indemnification. Standard contracts cap liability at 12 months of fees. If your business has higher exposure (regulated data, large customer base), negotiate higher caps.
• Confidentiality and IP. Mutual NDAs are standard; one-way NDAs (where only your information is protected, not theirs) suggest an unsophisticated provider.
• Subcontracting clauses. Can the MSP subcontract your work to third parties without notification? Almost every modern MSP outsources at least some functions (often the SOC or after-hours desk) — you should know which.

What to push back on:

• 3-year contracts for a first engagement. 12 months is standard.
• Auto-renewal for the same term. A 3-year auto-renewal on a 90-day-notice cancellation window is the most common contract trap in the industry.
• Vague termination clauses. Specifically, fees that aren’t itemized or processes that aren’t time-bounded.
• MSP-favorable indemnification. They should indemnify you for their negligence; you should indemnify them only for your negligence.

What most companies don’t realize

Three things experienced buyers know:

The pricing table doesn’t always match the SOW. It’s surprisingly common for the SOW to commit to one set of services and the pricing table to itemize a different set. Reconcile them line by line. Anything in the SOW not reflected in pricing is at risk of being billed separately later.

The MSA is more important than the SOW. The SOW changes every year as your needs change. The MSA defines the long-term operating rules — and it usually doesn’t change. Have your attorney review the MSA, not just the SOW. The two-hour legal cost is the cheapest insurance you’ll buy.

A redline-friendly MSP is signaling something good. A provider who happily accepts redlines on the MSA is signaling that they understand they’re proposing a partnership, not a product. A provider who refuses any redlines is signaling that they expect to be in control of the relationship. That tells you a lot about year two.

How to evaluate an IT provider’s proposal

A repeatable process for working through a stack of three competing proposals:

1. Read the SOW first, before pricing. Understand what’s actually being delivered before discussing the cost.
2. Build a side-by-side comparison spreadsheet with rows for each service category (help desk, monitoring, security, patching, backup, etc.) and columns for each provider.
3. Reconcile pricing to SOW. Make sure every line item in pricing maps to a deliverable in the SOW, and every SOW deliverable has a price.
4. Read the SLA structurally, not narratively. Look for severity tiers, credits, and reporting — not pretty language.
5. Read the MSA last, with your attorney. This is where the gotchas live.
6. Ask each provider the same five questions in writing. Compare answers; vagueness shows up immediately.

Frequently asked questions

What’s the difference between an SOW and an MSA?

The MSA (Master Services Agreement) is the long-term legal contract that governs the relationship — payment terms, IP, liability, confidentiality, dispute resolution. The SOW (Statement of Work) is the specific scope of services for a particular engagement, attached to or referenced by the MSA. The MSA usually doesn’t change for years; the SOW changes annually as your needs evolve.

How long should I take to review an MSP proposal?

A serious review takes 5–10 hours of your time plus 2–4 hours of your attorney’s time on the MSA. Spread over 1–2 weeks. Reviewing in a single sitting almost always misses something. Walk away, sleep on it, and come back with fresh eyes — twice.

Should I get my attorney to review the proposal?

Yes — at least the MSA. The SOW and pricing you can review yourself if you’ve done a few of these. The MSA is where multi-year liability, termination terms, and ownership of your data and credentials are defined, and small clauses there can cost five or six figures.

What’s a fair onboarding fee?

For SMB and mid-market engagements, $5,000–$25,000 is a reasonable range. Some MSPs waive it on multi-year contracts; some bill it monthly across the first quarter. Be cautious of “free” onboarding — it’s usually shallow.

Can I negotiate the proposal?

Almost every line item is negotiable in a competitive process — pricing, SOW inclusions, SLA targets, MSA termination terms, onboarding fees. MSPs that refuse to negotiate any of it are signaling something about how they’ll behave at renewal.

Keep learning

• Hidden Costs of Managed IT Services — the cost categories most often hidden in pricing tables
• MSP SLAs: What Makes One Real vs Marketing — a deeper read on the SLA section specifically
• 12 MSP Red Flags to Watch for Before You Sign — many of the proposal warning signs in concentrated form

To compare proposals from multiple providers, browse the MSP directory.