Why Project Pricing Goes Wrong for MSPs
Projects are a large part of how MSPs earn money outside the monthly fee. In Kaseya's 2024 MSP Benchmark Survey, 39% of respondents named project-based professional services as one of their top three revenue sources. Migrations, new offices, server and firewall replacements and security remediation all land here.
They are also where margin quietly disappears. A project quoted from a quick walkthrough meets an undocumented network, a line of business application nobody mentioned, or a client who assumed data cleanup was included. The same technicians who carry your recurring clients get pulled onto the overrun, so a bad project hurts service quality as well as profit.
The fix is a repeatable process: discover before you quote, write down exactly what you will and will not do, estimate from tasks rather than instinct, and control changes once work starts. Measure the result on every job with project gross margin, so the next estimate is better than the last.
Start With Discovery, Not a Quote
The biggest pricing errors happen before anyone opens a spreadsheet. If you have not seen the environment, you are guessing, and the client will hold you to the guess. For anything beyond a small, familiar job, run a discovery step first.
- Inventory what exists: devices, licenses, data volumes, network layout, integrations and who owns each application.
- Interview the people who use it, not only the owner, to learn how work actually flows and what cannot be down.
- Confirm the business goal and the deadline behind it, since a date driven by a lease or an audit changes how you plan.
- Identify dependencies on third parties: internet providers, software vendors, the landlord, the client's own staff.
For large or unclear projects, charge for discovery as its own small engagement and credit it against the project if the client proceeds. That filters out prospects who only want a free plan to hand to a cheaper competitor, and it pays for the hours that make your quote accurate. For an existing managed client, your documentation and the vCIO relationship often cover much of this already.
Write a Statement of Work That Holds
The statement of work is the contract for the project and the document you will return to when there is a disagreement. Write it so a technician who was not in the sales meeting can deliver it and a client who was not paying attention can understand it.
- Objective: the business outcome in one or two sentences.
- Deliverables: each thing you will hand over or complete, stated so it can be checked.
- Assumptions: what you are relying on being true, such as data volume, existing hardware condition or client availability.
- Exclusions: what is not included, named explicitly, especially the items clients tend to assume.
- Client responsibilities: approvals, access, staff time, purchases and decisions the client must make, and by when.
- Schedule and milestones: the phases, their order and what completes each one.
- Acceptance criteria: how both sides agree a milestone or the project is done.
- Price, payment schedule and the change order process.
Assumptions and exclusions do most of the protective work. When an assumption turns out false, the statement of work already says that a change order follows, so the conversation is about a known process rather than a favor. Keep project scope separate from the monthly agreement: work outside the managed plan is billed as a project, and the plan's exclusions list should say so, as covered in how MSPs price their services.
Estimate the Labor Honestly
Price follows effort, so the estimate is the heart of the quote. Build it from the bottom up rather than from a gut number for the whole job.
Break It Into Tasks
List every task at a size one person can finish in a day or less, and estimate each in hours. Include the unglamorous work: staging equipment, travel, user communication, documentation, testing and the handover to your help desk. Ask the engineer who will do the work to review the estimate, because they know which steps always take longer. The project engineer section of this site covers the role in more depth.
Add Management and Risk
Add project management time for planning, status updates, vendor coordination and client meetings. Then add a risk allowance sized to what you do not know: small for a job you have done many times on familiar hardware, larger for an old environment, an unfamiliar application or a client with a record of changing their mind. Name the risks in the assumptions so the allowance is explained rather than hidden.
Price the Hours at the Right Rate
Multiply hours by a rate that reflects what your people actually cost, including benefits, tools and the time they are not billable. Check what you earn on past projects with your effective hourly rate, then add hardware, software and any subcontractors with your markup. Work back from the margin you want, using our answer on what gross margin to target.
Choose How to Price It
The pricing structure decides who carries the risk of the unknown. Match it to how well you understand the scope.
| Structure | How It Works | Best For | Risk Sits With |
|---|---|---|---|
| Fixed fee | One price for the defined deliverables | Well understood, repeatable projects | The MSP, for anything inside scope |
| Time and materials | Hours billed at agreed rates plus parts | Unclear scope or troubleshooting work | The client |
| Capped time and materials | Hourly billing up to an agreed ceiling | Partly known scope where the client needs a budget limit | Shared, the MSP above the cap |
| Phased | Fixed fee for discovery or design, then a new quote for delivery | Large or unfamiliar projects | Shared, repriced after each phase |
Clients usually prefer a fixed fee because it is easy to approve, and it can earn you more when you deliver efficiently. It only works when discovery was thorough and the assumptions are written down. Where they are not, a phased approach lets you price what you know now and quote the rest once you have seen it.
Set payment on milestones rather than at the end: a deposit at signing that covers hardware, then payments tied to completed phases. That protects your cash flow and keeps the client engaged at each approval.
Control Change Once Work Starts
Scope creep rarely arrives as one big request. It arrives as a series of small ones, each reasonable on its own, asked of whichever technician is on site. Train your team to say yes to the client and route the request to the project lead, who writes a short change order with the added work, the price and the schedule impact, and gets it approved before the work happens.
Track actual hours against the estimate as the project runs, in your PSA, not only at the end. A project running over at the halfway point can still be rescued with a conversation; one discovered over budget at close cannot.
Close Out and Learn From the Numbers
Finish with a documented handover: updated documentation, credentials, a summary of what changed and a clean transfer to your help desk. For a new client, the project often flows directly into onboarding, and the client onboarding checklist picks up from there.
Then compare estimate to actual for every task. Where you were consistently wrong, adjust your estimating template, so each project makes the next quote more accurate. Review completed projects with the client at their next QBR, and use what you learned about their environment to recommend the next piece of work.
Common Questions
Should I charge for a project proposal?
For small, familiar jobs, no. For large or unclear projects, charge for discovery and credit it against the project if the client proceeds, since an accurate proposal takes real hours.
Do managed clients get a project discount?
You can offer managed clients a lower project rate, because the environment is documented and the work is easier to estimate. It also rewards clients for staying on a plan.
What if the client wants the price before discovery?
Give a range with the assumptions it depends on, and state that the firm price follows discovery. A single number without seeing the environment is a guess the client will hold you to.
How do I handle hardware on a project quote?
List hardware separately with your markup, require payment for it up front or at order, and state who owns it and who handles warranty claims.
Who should approve a change order?
Someone at the client with authority over the budget, named in the statement of work. Approval from whoever happens to be on site can be disputed later.
Should projects be priced by the same team that sells them?
Sales can own the proposal, but an engineer who will deliver the work should build or review the labor estimate. That separation catches optimistic numbers before the client signs.