Fixed-fee project pricing for small MSPs

Short answer: For SMB projects, a fixed fee works when the outcome is bounded. Price the estimated labor at an internal sell rate, add direct costs and a risk contingency, collect payment in milestones that protect cash flow, and define changes before work starts. Use the project to earn trust and discover the environment, but put recurring support and operational responsibility in a separate monthly agreement.

Projects can open the door without becoming the whole business

A new solo MSP may find it easier to sell a Microsoft 365 migration, firewall replacement, or Intune rollout than a full managed agreement. The client can see a finite problem and a defined result. The MSP gets paid to learn the environment and demonstrate how it operates.

That is a useful entry point, but project revenue is uneven. A healthy MSP still needs predictable revenue to fund availability, tools, documentation, security review, and follow-up between emergencies. Treat projects as one acquisition and delivery channel—not as proof that recurring service can wait forever.

The project should end with one of three clear outcomes:

• The client accepts the result and takes over operations.
• The client buys a defined support or maintenance add-on.
• The client signs a managed services agreement for the recurring responsibility revealed by the project.

Do not make the recurring agreement a surprise condition at the end. Present it as an option in the proposal so the client understands who will own the environment after acceptance.

Fixed fee starts with a bounded result

Small businesses often prefer a number they can approve and budget. A fixed fee can provide that clarity, but only when the proposal defines what completion means.

Write down:

• The deliverables the client will receive.
• The systems, users, sites, tenants, or endpoints included.
• Assumptions about licenses, access, source data, hardware, and vendor cooperation.
• Client responsibilities and decision deadlines.
• The planned work window and cutover constraints.
• Acceptance tests and the acceptance period.
• Exclusions, especially custom development, remediation, training, data cleanup, and after-hours work.
• What triggers a change order, pause, or re-estimate.

Microsoft's project planning guidance describes a project plan around scope, schedule, resources, deliverables, dependencies, owners, and feedback. An SMB proposal can be much shorter, but it still needs those decision boundaries.

If you cannot describe the result and the boundary, you do not yet have a fixed-fee project. You have an unknown environment with a hopeful number attached.

Build the price from your own economics

Use a simple internal model:

```text

Fixed project fee =

(estimated hours × internal sell rate)

+ direct project costs

+ risk contingency

```

The internal sell rate is not just technician wages. It must help fund payroll burden, owner time, administration, tools, training, non-billable work, and the profit contribution the business needs. If your rate represents only loaded labor cost, add the required profit contribution as a separate line in the calculation.

Direct costs may include temporary licenses, migration tooling, subcontractors, travel, shipping, disposal, or hardware handling. Do not hide a vendor cost inside labor and hope it survives.

The contingency is not an arbitrary markup. Tie it to identifiable uncertainty:

• Weak or missing documentation.
• Unknown data volume or quality.
• Legacy authentication and unsupported systems.
• A third-party vendor controlling a dependency.
• Tight cutover windows.
• New work your team has not delivered repeatedly.
• Client delays that can force rescheduling.

The U.S. Small Business Administration break-even guidance connects pricing to fixed costs, variable costs, and contribution margin. That is the right discipline here: a project price must cover the work and contribute to the business, not merely look acceptable beside a competitor's number.

Do not borrow somebody else's project number

A community example such as 2,500 dollars per project is not a price list. The same label can hide radically different work.

An M365 security assessment for 12 users with one tenant is not the same as an assessment for 80 users, unmanaged admin accounts, several domains, legacy applications, and no documentation. A firewall setup can mean a clean replacement with known rules, or it can mean discovering the client's network while the business is already down.

Use outside numbers as a reasonableness check after your estimate, never as the estimate itself. If your price is much higher or lower, identify why: scope, geography, risk, experience, tools, travel, schedule, or the level of evidence being delivered.

Use paid discovery when uncertainty is too high

Do not force every opportunity into one fixed fee. Sell a small discovery phase when you cannot yet verify the inputs.

Discovery can produce:

• Asset and user counts.
• Current-state diagrams.
• Data volume and migration-source findings.
• Licensing and prerequisite gaps.
• Known vendor dependencies.
• Risk and remediation list.
• Recommended project plan and final quote.

The client receives a useful deliverable even if the implementation does not proceed. The MSP avoids giving away the hardest thinking and avoids absorbing unknowns inside a premature fixed price.

For migrations, Microsoft's Microsoft 365 migration overview separates scenarios and workloads, while its SharePoint migration guidance emphasizes assessment, remediation, target preparation, migration, and user onboarding. That sequence is a reminder that “move us to M365” is not one task.

AYCE applies to defined support, not unlimited change

All-you-can-eat support is not an agreement to build anything the client can imagine. It is a pricing approach for defined, in-scope support activity.

The agreement can include password resets, user support, monitoring, routine maintenance, patch review, licensing administration, and other predictable work. It can exclude custom applications, Power Apps, website integrations, major migrations, new-site buildouts, inherited remediation, and large changes.

Use the scope and SLA boundaries guide to separate:

• Recurring support.
• Planned project work.
• Incident response.
• After-hours work.
• Client-approved exceptions.

The recurring plan should finance a stable promise. Project pricing should finance a finite change. Mixing the two without a written boundary makes both harder to deliver.

Decide where common SMB projects belong

Some services have an implementation phase and a recurring operating phase. Split them deliberately.

• M365 security assessment: a standalone paid assessment when the client wants findings, or part of paid onboarding when it feeds a managed plan.
• Google Workspace to M365 migration: project work with discovery, prerequisites, data scope, cutover, validation, user communication, and explicit out-of-scope data.
• New M365 tenant: a project or onboarding deliverable; recurring identity, licensing, support, and security review belong in the monthly service if included.
• Intune rollout: implementation project for enrollment, policy, testing, exceptions, and deployment; ongoing policy maintenance and alert handling are recurring work.
• Firewall setup: project for design, installation, rules, testing, documentation, and handoff; monitoring, firmware review, configuration backup, and vendor coordination can be recurring.
• Defender, EDR, or hardening rollout: project or onboarding remediation for deployment and baseline configuration; alert triage, exclusions, policy review, and evidence require recurring ownership.

This split keeps the client from paying project rates forever and keeps the MSP from providing operational responsibility for free.

Protect cash flow with a payment schedule

A new MSP should not finance a client's project from its own cash. Match payment to exposure.

Reasonable structures include:

• Full prepayment for small, short, clearly bounded work.
• A non-refundable discovery fee followed by an implementation quote.
• A deposit before scheduling, a payment before cutover, and a final acceptance payment.
• Prepayment of hardware, licenses, subcontractors, and other committed third-party costs.

Define what happens if the client delays access, misses a decision date, cancels after licenses are purchased, or leaves the project idle. Also define whether the final payment depends on objective acceptance criteria rather than an open-ended feeling that “everything is perfect.”

Review every estimate against actual work

Early estimates will be imperfect. The cure is not a giant permanent contingency. It is disciplined job costing.

After each project, record:

• Estimated versus actual hours by phase.
• Unplanned vendor and client coordination.
• Rework and its cause.
• Travel and after-hours impact.
• Tools or licenses missed in the estimate.
• Assumptions that failed.
• Changes approved versus work absorbed.
• Gross contribution after direct costs and labor.

Update the estimating template before quoting the next similar project. After several comparable jobs, the MSP should know which discovery questions predict effort and which work should never be sold without a paid assessment.

Proposal checklist

Before sending a fixed-fee proposal, confirm:

• The result and acceptance evidence are explicit.
• Quantities and included systems are listed.
• Assumptions and client dependencies are visible.
• Exclusions cover custom work and unknown remediation.
• The internal rate reflects real business cost.
• Direct costs are included.
• Contingency is tied to named risks.
• Change-order rules are usable.
• Payment timing limits cash and collection exposure.
• The post-project owner is named.
• Any managed services option has its own scope and price.

Common mistake

The common mistake is using a fixed price to create certainty for the client while leaving all uncertainty with the MSP. The proposal promises an outcome but does not cap quantities, name assumptions, define client duties, or price risk.

That is not customer-friendly simplicity. It is an unpriced guarantee.

When to change level

Move from informal estimating to paid discovery, standard project templates, job-cost reporting, and stronger change control when projects repeat, outside vendors control more dependencies, cutovers affect business continuity, or one missed estimate can erase a month of profit.

Move suitable clients toward recurring service when the completed project creates ongoing responsibility for monitoring, maintenance, identity, security, backup, vendor follow-up, or user support. The signal is not that the client bought a project. The signal is that somebody must own the next operational action after the project is closed.