Learn / practitioner

How to evaluate an IT proposal in 60 minutes

Most IT proposals are written to be skimmed and approved, rather than compared. Here is a 60-minute due-diligence template — what to read first, what to ask the vendor, and the seven specific traps that cost the most.

If you have an IT proposal in front of you and an hour to decide, this piece is for you. It is a checklist written from the operator’s side — by people who have written proposals, read proposals, and lived inside the operational consequences of accepting the wrong one. It is biased toward the buyer.

We are not pretending to be neutral about who you should buy from; we run an IT firm and we want you to consider us. But the specific traps and questions below apply to any proposal, including ours. You should be able to read our proposal and any competitor’s through the same lens.

The 60-minute structure

Reading an IT proposal end-to-end carefully takes hours and most buyers do not have hours. The 60-minute version is structured:

  • 5 minutes — orient. Read the executive summary, scan the headline price, note the contract length.
  • 10 minutes — line items. Read every line of the pricing table. Anything you do not understand goes on a question list.
  • 15 minutes — the SLA. This is where the real product is described. Slow down and read every clause.
  • 10 minutes — exclusions. Find the section labeled “out of scope” or “additional charges may apply.” Read it twice.
  • 10 minutes — termination + transition. What happens at the end of the contract, and on whose terms.
  • 5 minutes — the human references. Three names with phone numbers, please.
  • 5 minutes — your compare-with-the-other-proposal sheet. Numbers next to numbers.

Below is the depth on each section.

Phase 1 — Orient (first 5 minutes)

The executive summary tells you the vendor’s pitch in their own words. Read it. Then look at three specific numbers:

  • Headline monthly or annual price — write it down.
  • Per-unit math — divide the price by the relevant unit (employees, computers, mailboxes). The number you get should be in the published-benchmark range for your industry. If it is much lower, something is excluded that other vendors include; if it is much higher, you are paying for something specific.
  • Contract length — 1, 2, or 3 years is normal; 5 is aggressive; month-to-month is rare and worth asking about.

While orienting, also note who signed the proposal. A signature from the founder of a 30-person MSP versus from a sales rep at a 500-person regional firm tells you about whose desk this lands on if things go wrong.

Phase 2 — Read every line item (minutes 5-15)

Pricing tables in IT proposals are where a lot of the real story lives. Read every line. The patterns to watch for:

Unit ambiguity. “Endpoint protection — $40/month” is incomplete. Per what? Per device? Per user? Per company? The competent proposal lists unit + count + unit price + extension. The proposal that says “monitoring services — $1,200/month” without unit math is hiding the unit.

Recurring versus one-time muddle. Onboarding fees, project hours, hardware purchases, and license activations should be in a separate one-time section from the monthly recurring revenue. If they are commingled, it is hard to model the 3-year cost.

The “as needed” line. Any line item priced as “billed as incurred” or “TBD” or “scoped separately” is a future surprise unless the proposal also tells you the rate, the typical incidence, and the approval process. “Project work as needed at $175/hour” is fine if you know what counts as a project; less fine if every Outlook reconfiguration is suddenly a project.

The bundled-but-not-included line. Watch for products that are listed but where the line says “license sold separately” or “customer to procure.” This is sometimes legitimate (the vendor manages, the customer owns the license) and sometimes a margin-padding play. Ask which.

Phase 3 — Read the SLA (minutes 15-30)

The Service Level Agreement is the actual product description. Skip the marketing copy at the front of the proposal; spend the time here.

Things to find:

  • Response time vs. resolution time. “We respond within 1 hour” tells you nothing about when your problem gets fixed. The proposal should distinguish acknowledgment (within X minutes) from response (a human looking at it within Y) from resolution (problem solved within Z). Most weak proposals collapse all three into “response.”
  • Coverage hours. 24/7? Business hours? “Best-effort after-hours”? “After-hours emergencies only”? The 24/7 SOC for security is increasingly table stakes for cyber insurance (we have a whole separate piece on cyber insurance requirements) — but help-desk after-hours is a different question and most SMB MSPs leave it unstaffed. Find out what you actually get on a Saturday night.
  • Severity definitions. A P1 incident at one vendor is different from a P1 at another. The proposal should give explicit examples — “P1 = complete outage of a production system affecting more than 50% of users; P2 = degraded service affecting more than 10%; P3 = single-user issue with workaround.” Without examples, the severity classification is the vendor’s discretion.
  • Penalties for missed SLA. Real consequences for the vendor make the SLA real. The penalty might be a service credit (a percentage of that month’s invoice), a free month, or — at the high end — termination right with no penalty. SLAs without penalties are aspirations.

Phase 4 — Read the exclusions (minutes 30-40)

This is where most surprises hide. Find the section variously titled “out of scope,” “additional charges may apply,” or “exclusions.” Read it twice, slowly. Specific patterns:

Project-vs-support boundary. Most MSPs distinguish between managed support (covered by your monthly fee) and project work (billed separately). The boundary is famously hard to pin down — does setting up a new employee count as support, or is it a project? Does a server migration? Does responding to a phishing-driven incident? The proposal should give specific examples in each direction.

After-hours definitions. What counts as after-hours? Some vendors define after-hours as 5 PM to 8 AM in your time zone, plus weekends. Others define it as “emergencies only outside business hours.” Get specific.

Procurement markup. Hardware and software pass-through versus marked up — see our piece on MSP economics for why this matters. The proposal should disclose if there is a markup and what tier of markup.

Travel and on-site. Some MSPs include on-site visits in the monthly fee up to a limit; some bill per visit; some require a separate retainer. If you have multiple offices, this matters more.

Compliance-driven scope-creep. If you are pursuing or maintaining SOC 2, HIPAA, or similar, the work to support that compliance posture often shows up as a separate line. Make sure you understand what the monthly fee covers vs. what is sold as a compliance engagement.

Phase 5 — Termination, transition, data (minutes 40-50)

The end of the contract is where the mistakes you made at the beginning catch up to you. Specific items:

  • Notice period. 30, 60, 90 days? With what trigger?
  • Auto-renewal lock-in. Some contracts auto-renew for a full term unless cancelled by 90 days before expiration. If the proposal has an auto-renewal clause, find the cancellation window and put it on your calendar the day you sign.
  • Data portability. What happens to your data — passwords, configurations, monitoring history, backup chains, ticket history — when the relationship ends? The proposal should obligate the vendor to hand it over in usable formats. The version that fails: the vendor “owns” their RMM data; you get a CSV at termination if you ask nicely.
  • Knowledge transfer. A reasonable contract obligates the outgoing vendor to spend, say, 20-40 hours over the transition window briefing the incoming vendor on environment specifics. Without this clause, you pay your new vendor to discover everything from scratch.
  • Penalty for early termination. Some contracts have early-termination fees that effectively lock you in for the full term. Read this carefully — if the contract is bad, the early-termination fee determines what it costs to escape.

Phase 6 — References (minutes 50-55)

Vendors will give you references. The good ones offer them proactively; the weaker ones give you the same three logos that appear on their website.

Specific things to ask for:

  • Three named customers, not on the website. The marquee names on the homepage are the ones who agreed to public reference; ask for the ones who agreed to private reference.
  • Phone numbers, not email. A 10-minute phone call surfaces things email never does. Tone of voice, hesitation, the moment when the reference says “well, most of the time…”
  • Same industry, comparable size. A vendor who is great with 200-person manufacturing firms may not be great with 30-person law firms.
  • A scripted question list. “Are they responsive?” gets you a yes from everybody. “When was the last time something broke at 9 PM on a Friday, and what happened?” gets you a story. Specifically: “If you were starting over, would you sign with them again knowing what you know now?” — that question separates the satisfied from the trapped-but-paying.

Phase 7 — The compare-with-the-other-proposal sheet (final 5 minutes)

If you have two or more proposals, put them on a spreadsheet:

ItemVendor AVendor BVendor C
Monthly base cost
One-time onboarding
Estimated project work / year
Total 3-year cost
Hours of coverage
MDR included?
Backup included?
Per-employee equivalent
Termination notice
Reference quality (1-5)
Apples-to-apples gap items

The “apples-to-apples gap items” row is the most important and the most often skipped. Vendor A includes backup and Vendor B does not — if you add backup to Vendor B’s proposal, what is the new total? Vendor A includes 24/7 SOC and Vendor B does not — same question. Two proposals that look similar at the headline price often differ by 30-50% once you normalize scope.

Seven specific traps that cost the most

Patterns that show up often enough to call out by name:

  1. Bundled but unverifiable. “Includes endpoint security” with no detail on which product, which configuration, which alert thresholds, who watches the alerts. Get specifics or treat it as not included.
  2. The hour-bank trap. “Includes 10 hours of project work per month.” Unused hours expire at month-end; exceed them and you pay overage at a rate that is conveniently absent from the proposal.
  3. The compliance line item. “Compliance support included” without specifying the framework, the deliverables, or the evidence-collection automation. Compliance done well is expensive; compliance done as a checkbox is cheap and useless.
  4. The unverified MFA claim. Every proposal in 2026 claims “we enforce MFA.” Verify operationally — ask for screenshots from the management console showing MFA enforcement on every privileged group.
  5. The “we will figure that out together” boundary. Anywhere in the proposal where the boundary between “covered” and “not covered” is left to be worked out post-signature is a future invoice you have yet to see.
  6. Pricing that auto-escalates without index. Annual price increases of “up to 10%” or “as market conditions warrant” without ties to a specific index (CPI, IT-services PPI) effectively let the vendor reset the price.
  7. The auto-renewal trap. Already mentioned, but worth flagging again: 90-day-out cancellation windows with multi-year lock-in are common in regional MSP contracts and the most common single source of “we are stuck for another two years” anger.

What good proposals look like

A defensible IT proposal — written by a vendor you would want to work with — has these structural properties, regardless of who wrote it:

  • Pricing table with unit + count + unit price + extension on every line.
  • One-time costs separated from recurring; 3-year TCO computed for you.
  • SLA with explicit response, resolution, and severity definitions; named penalties for misses.
  • Out-of-scope list that is specific (with examples) rather than open-ended.
  • Termination clause with a reasonable notice window, no auto-renewal trap, and obligated data portability.
  • Three named references with phone numbers, in your industry and size.
  • A named human as the vendor’s primary contact, rather than an account-team mailing alias.

The proposal that has all of these things may still be the wrong proposal for you on substance, but it has been written by people who expect to be evaluated on substance. The proposal that fails several of these structural tests is telling you, in advance, what the relationship will be like to operate.

If you would like to see what our version of a proposal looks like, the build flow generates one for your specific company size and industry. We use the same structure described above — partly because it is how proposals should be written, partly because we want our proposals to be evaluated on the same checklist as everyone else’s.

Technically reviewed by Tobias Wexler.

Want this turned into a real plan?

The build flow uses the same logic this article describes — three minutes to a configured IT department.