MSP project pricing starts with the cost of an hour you can actually sell. Assume the model's US project engineer earns $84,000, carries a 1.25 burden multiplier, and spends 85% of 1,660 available annual hours on productive project work. Annual labor cost is $84,000 × 1.25 = $105,000 and productive hours are 1,660 × 85% = 1,411; $105,000 ÷ 1,411 is about $74.42 an hour. A labor-only rate of ($105,000 ÷ 1,411) ÷ (1 − 50%) is about $149 an hour; the model's blended project rate is $185.
Those assumptions describe a dedicated project engineer without service-desk escalation duty. If the engineer's usable project hours are lower, the hourly cost rises. Don't divide salary by paid hours and call the answer a project rate.
Cost the Hour Before Setting the Rate
Burden is the employer cost added to salary, including the model's payroll taxes, benefits, and insurance assumptions. Productive utilization is the share of available hours used for the specified work. Keep those definitions separate: a salary multiplier doesn't turn every paid hour into a saleable hour.
| Calculation | Named Model Inputs | Result |
|---|---|---|
| Annual Burdened Pay | $84,000 × 1.25 = $105,000 | $105,000 |
| Annual Productive Project Hours | 1,660 × 85% = 1,411 hours | 1,411 hours |
| Monthly Productive Project Hours | 1,411 ÷ 12 = about 117.58 hours | About 117.58 hours |
| Burdened Labor Cost per Productive Hour | $105,000 ÷ 1,411 = about $74.42 | About $74.42 |
| Labor-Only Rate for a 50% Margin | ($105,000 ÷ 1,411) ÷ (1 − 50%) = about $149 | About $149 |
The model starts with 2,080 paid hours and reduces them to 1,660 available hours after leave and admin allowances. It then applies the project utilization assumption. Using the larger paid-hours figure as the denominator would spread the cost over hours the engineer cannot devote to the project work being priced.
Use your own loaded cost and usable project hours when you make the decision. If the same engineer handles service escalations, record that work and check the project hours left. The model's 70% service utilization and 85% project utilization describe different duties; the title on a payslip doesn't decide which one you achieved.
Check Margin on a Consistent Cost Basis
Project gross margin is project revenue less project delivery cost, divided by that revenue. For a 50% margin, the price must be twice the delivery cost. The labor calculation above is therefore a labor-only test; add any other direct costs included in the project before deciding whether the whole quote clears the target.
At the model's $185 rate, the labor-only margin is ($185 − (($84,000 × 1.25) / (1,660 × 85%))) / $185 × 100 = about 59.8%, using the unrounded hourly labor cost. That leaves a different question from whether the entire project line earns 50%, because unpaid work and other included costs still need somewhere to land.
Keep the estimate's revenue boundary consistent with its cost boundary. If hardware or a subscription is sold as a separate line, don't use that revenue to improve the apparent labor margin while leaving its purchase cost elsewhere. Record what the quoted price includes so you can compare the finished job on the same basis.
Separate a Rate Problem From an Estimate Problem
For a fixed-price job, calculate expected labor cost as estimated hours times your labor cost per productive hour. After delivery, replace estimated hours with the actual hours worked and compare the resulting margin. An hourly rate that works on the estimate cannot protect a fixed fee from unlimited additional labor.
Have technicians record the work actually performed, including rework and troubleshooting, even when the business decides not to bill it. Otherwise the estimate-to-actual comparison answers how much time was entered rather than how much labor you paid for. Keep the reason for any unbilled time with the job.
| What the Records Show | What to Investigate | What to Change |
|---|---|---|
| Hourly Cost Exceeds the Pricing Assumption | Burden, available hours, and duties taking time away from projects | Recalculate the rate using the cost and capacity you can support |
| Actual Labor Exceeds the Estimate | Missing tasks, scope changes, rework, and recorded dependencies | Repair the estimate and agree how additional scope is authorized |
| Billed Jobs Meet the Target but the Project Line Does Not | Unbilled work and costs assigned outside individual sold jobs | Budget that work explicitly and check the whole line again |
My view is that a rate increase should answer a cost calculation, not conceal an estimating problem. If the work changed, show the client the changed scope and seek the required approval while the decision can still affect the job. If the original estimate missed work already promised, record that miss rather than labeling it a new request.
Include the Onboarding Work You Give Away
The model puts new-client onboarding on project engineers, not in the support desk's spare capacity. It allows 60 engineer hours per new client and treats the quoted onboarding fee as waived for the signed managed agreement. Those hours still consume project capacity even though no project fee pays for them.
The stable US example brings in about 8.72 new clients annually using its unrounded acquisition calculation. Multiply about 8.72 by 60 hours and you get about 523 hours of onboarding work. The example therefore needs about 0.37 additional full-time equivalents, or FTE, meaning workload expressed as full-time roles.
Adding onboarding moves the example from 1.11 + 0.37 = 1.48 project engineer FTE. Its project revenue is $290,769, with $155,908 of project labor. Using those rounded annual amounts, labor exceeds the 50% cost allowance by $155,908 − ($290,769 × 50%) = $10,523.50, or about $10,524. The revenue-to-labor ratio is $290,769 / $155,908 = about 1.87, below the 2 needed for a 50% labor margin.
The billed hourly rate clears its labor test, but the whole project line misses the target once the unpaid onboarding work is included. That distinction matters when you choose a remedy. A quotation template won't make those 523 hours disappear.
Keep onboarding as the model's usual bonus concession instead of discounting the monthly managed fee. Cost the concession before offering it and reserve the delivery time. The question is whether the acquisition plan and the delivery budget can carry that work, not whether an engineer should stop recording it.
Test the Next Quote Against the Records
The model gives projects 8% of the example MSP's total revenue, producing the $290,769 annual line. Use that whole line as a reconciliation check after reviewing individual jobs. A collection of apparently profitable quotes isn't enough if shared project work has been left out of every one.
- Finance confirms the burdened cost assigned to project delivery for the period.
- The project lead reconciles productive hours with billed jobs, onboarding, and other unpaid work.
- The estimator compares completed jobs with their original labor estimates and explains the differences.
- The owner checks the proposed rate and the full project-line margin before approving the next pricing assumption.
Keep the cost, utilization assumption, and scope basis with the approved rate. Recalculate when those inputs change. If the rate clears the labor calculation but the project line remains below target, investigate the unbilled workload before assuming the number on the quote is the only problem.
mspoutpost.com/articles/msp-project-pricing-cost-the-hour-before-the-quote
Written by Graham Whitfield
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.