MSP project pricing works when you price managed services for predictability and project work for scope. A managed agreement covers ongoing, repeatable work at a steady monthly fee. A project covers a defined outcome with a start, an end, and a price based on effort, risk, and value. Mixing the two models without clear rules is how MSPs end up giving away labor.
Many small MSPs blur the line. They include “a little project time” in the monthly fee, or they quote projects with no margin for surprises. This guide explains how to price each type of work, where the boundary belongs, and how to keep both profitable.
What Each Model Is For
Managed services fund the steady care of an environment: monitoring, patching, support, backup, security operations, and routine advice. The client pays a predictable amount, and you agree to deliver a defined level of service. The revenue is recurring, and profitability depends on efficiency and discipline.
Projects handle work with a clear finish line, such as a migration, an office move, a network rebuild, or a security upgrade. They require planning, specialized skills, and often a burst of effort. Because scope, risk, and complexity vary, projects need their own pricing logic.
Draw the Line Clearly in the Agreement
The most common pricing problem is unclear scope. Write down what counts as routine and what counts as a project. A helpful rule is that anything with a defined business outcome, more than a few hours of effort, or a requirement for planning and testing is a project. Routine adds, moves, changes, and small fixes stay inside the managed fee. State the threshold in your agreement, and train your team to recognize when a request crosses it.
When clients hear this rule up front, they accept it. When they hear it for the first time during a big request, they feel surprised and resist.
How to Price Managed Services
Base managed pricing on the cost to deliver, the value to the client, and the market. Track your real cost per user and per device, including tools, labor, overhead, and the time your team actually spends. Set prices so gross margin lands where your business needs it. Many MSPs use per-user or per-device pricing because it scales with the size of the environment. Revisit prices yearly and raise them when costs rise, with clear notice to clients.
Do not price by guessing what competitors charge. Know your margin target, know your costs, and price accordingly. If a client cannot pay a sustainable price, that tells you something about fit.
MSP Project Pricing: How to Price Projects
A sound project price covers labor, tools, risk, and margin. Break the work into tasks, estimate the hours for each, and apply your blended rate. Then add a contingency for the unknown. The more uncertainty, the higher the buffer. For well-understood work you have done many times, a fixed price is efficient and clients love certainty. For work with major unknowns, consider a phased approach: price an assessment first, then price the build based on what you learn.
- Fixed price: best for defined, repeatable work with clear acceptance criteria.
- Time and materials with a cap: good when scope may shift but the client needs a ceiling.
- Phased pricing: useful when discovery must come before design.
Whichever model you use, spell out assumptions and what triggers a change order.
Protect Yourself With Assumptions and Change Orders
Every project quote should list its assumptions: access to systems, availability of client staff, the condition of the current environment, and the timeline. When an assumption proves wrong, a change order adjusts scope or price. Handle change orders quickly and professionally, and explain them with facts. Clients accept fair adjustments when they understand why they are needed. What they resent is a surprise invoice after the work is done.
Watch Your Margins Separately
Track profitability for managed services and projects as different things. A managed agreement that looks healthy might hide unpaid project work, and a project that looks profitable might have consumed hours that should have been billed. Review actual hours against estimates after every project and adjust your estimating. Look at agreement profitability regularly, because a slow slide is easier to fix early than late.
Let the Roadmap Drive Projects
The best projects do not come from emergencies. They come from a strategic plan. A vCIO who keeps a technology roadmap can forecast projects a year ahead, help clients budget for them, and schedule the work at good times. That planning turns projects from a source of stress into a predictable stream of revenue, and it keeps clients from treating every large need as an unplanned cost.
Keep Advice Honest
There is a temptation to recommend projects because they earn revenue. Clients can sense this. Recommend work because it serves the client’s business and risk profile, and be willing to say when a project is not needed. That honesty builds the trust that makes future recommendations easier to accept. The idea is explored further in the fiduciary standard for vCIOs.
Communicate Pricing With Confidence
How you present a price matters. Explain what the client gets, why it costs what it does, and what happens if they choose a lower-cost option. Offer good, better, and best when appropriate. Avoid apologizing for your price. If you have built it on real costs and real value, you can defend it calmly.
Common Pricing Mistakes
- Including project work in the monthly fee without limits.
- Quoting projects with no contingency.
- Failing to document assumptions.
- Never comparing estimated hours with actual hours.
- Discounting to win work and then struggling to deliver profitably.
A Worked Example of MSP Project Pricing
Say a client wants to move file servers to a cloud platform. Under a managed agreement you already monitor the servers and support users. The migration itself is a project. You break it into assessment, design, pilot, migration in waves, user training, and decommissioning, then estimate hours for each and apply your blended rate. You add a contingency because permissions in older file structures are always messier than they look. You state assumptions, such as the client providing a decision maker for each department, and a change order process for anything discovered outside the plan. Once it is finished, the ongoing cloud management rolls into the monthly fee at a new rate. The client sees both prices clearly, and you protect your margin on each.
Set Rates That Reflect Skill
Not all hours are equal. A senior engineer designing a migration costs more than a technician handling routine setup. Use a blended rate for simple projects, but split rates by role when the mix is uneven. Review your rates each year against costs and demand. Rates that never change shrink your margin by inflation alone.
Use Deposits and Milestones
Large projects create cash flow risk. Ask for a deposit before ordering hardware or starting work, and tie the remaining payments to milestones. Clear payment terms reduce disputes and keep you from financing your client’s project. State them plainly in the proposal and hold to them, since a client who sees discipline early tends to respect the process later.
Review Every Project Afterward
When a project ends, hold a brief review. Compare estimated and actual hours, list what surprised you, and record lessons for the next quote. Over time your estimates improve, and you start to see which types of work are consistently profitable. Share the results with the team so estimating becomes a skill everyone builds.
Related Reading
New to the role? Start with what a vCIO is and why the role matters, then see how the vCIO services hub ties the pieces together.
Frequently Asked Questions
What is the difference between a managed service and a project?
A managed service is ongoing work delivered for a recurring fee. A project is a defined piece of work with a start, end, and specific outcome, priced separately.
Should MSPs price projects at fixed prices?
Fixed prices work well for defined, repeatable work with clear scope. For uncertain work, use a phased approach or a time-and-materials quote with a cap.
How much contingency should a project quote include?
It depends on uncertainty. Well-understood work needs a small buffer, while unfamiliar environments need more. Use past estimates versus actuals to calibrate.
What is a change order?
A change order is a written adjustment to a project’s scope, price, or schedule when conditions or requirements change after the quote is accepted.
How do you stop giving away project work inside managed agreements?
Define the boundary in the agreement, train your team to spot requests that cross it, and quote those requests as projects.
About Brent Lacy: Brent Lacy is a technology advisor and the voice behind Rewired MSP. He helps MSPs operate with greater maturity and helps business owners make IT choices that make them more secure and more efficient. He is the author of Out of Cycle: A Field Guide to Strategic IT Continuity, vCIO Rewired: Virtually Conquering IT Obstacles, and Near Miss: Preventable IT Failures Threatening Your Business Security.
