Pricing managed services without undercharging

Short answer: Price managed services around the operating promise, not only the tool bill. A sustainable price must cover recurring support, review, documentation, risk decisions, vendor coordination, and the technician time needed to keep the promise.

Price the responsibility, not the tool bill

Managed services pricing is not tool cost plus a little markup. It is the price of an operating promise.

That promise includes response, judgment, risk review, documentation, access control, backup monitoring, patching, vendor coordination, client communication, and technician time when something does not behave cleanly.

If the promise is unclear, the client will define it later. Usually during an urgent issue, renewal conversation, or invoice complaint.

Define the service before the price

Before quoting, write the service boundary in plain language. The U.S. Small Business Administration's market research and competitive analysis guidance is a useful reminder that pricing is shaped by buyer context, alternatives, demand, and competitive pressure. For an MSP, that market work matters, but it cannot replace scope discipline.

Define:

• Supported users, devices, servers, sites, cloud tenants, and applications.
• Included support channels.
• Business hours and emergency rules.
• Patch and maintenance windows.
• Backup monitoring and restore expectations.
• Security baseline and excluded security work.
• Reporting and review cadence.
• Vendor coordination boundaries.
• Project work, after-hours work, onsite work, and incident rules.
• Client approvals, accepted risks, and excluded systems.

The price only makes sense after the boundary exists. Use the client onboarding checklist to discover the real environment before treating a quote as final.

Start with labor reality

Small MSP owners often calculate software cost carefully and then undercount labor. That is backwards. Tools matter, but technician time is usually the expensive constraint.

Use labor math before package math:

• Expected monthly tickets per client.
• Average technician minutes per ticket.
• Recurring maintenance time.
• Patch review time.
• Backup review and restore-test time.
• Security alert triage and identity review time.
• Vendor coordination time.
• Client communication and monthly review time.
• Documentation time.
• Escalation and owner time.
• Administrative time for billing, renewal, and account work.

The U.S. Bureau of Labor Statistics Occupational Outlook Handbook for computer support specialists is a useful reality check when estimating labor cost. Wage data is not your full loaded cost, but it helps prevent the fantasy that skilled support time is cheap. Add payroll taxes, benefits, owner time, management overhead, training, tools, non-billable time, and profit requirement before deciding whether a monthly price works.

If the monthly fee cannot fund the labor pattern, the contract is usually already strained.

Build a minimum viable price

Before presenting a package, calculate a minimum viable price. Keep it simple enough that you can explain it and repeat it.

Use this model:

1. Direct tool cost: RMM, PSA, documentation, backup, security, remote access, email security, reporting, and any per-client platform cost.
2. Expected service labor: support tickets, maintenance, patch review, backup review, documentation, vendor follow-up, and client communication.
3. Review labor: monthly evidence review, security exceptions, backup proof, queue patterns, and client decisions.
4. Admin and non-billable load: billing, agreement updates, renewals, internal cleanup, scheduling, and owner oversight.
5. Risk buffer: noisy environments, legacy systems, difficult vendors, weak documentation, high-touch users, and after-hours pressure.
6. Margin requirement: the gross margin the account must protect after labor, tools, and normal friction.

A practical formula:

```text

Minimum monthly price =

tool cost

+ expected labor cost

+ review/admin cost

+ risk buffer

+ required margin

```

Do not treat this as a public rate card. Treat it as the floor below which the account starts consuming the business.

The SCORE pricing and business model resources are useful because pricing is not only arithmetic. The model has to match the value delivered, the customer segment, and the way the business earns margin. For a small MSP, that means a price must fund the operating promise, not just look acceptable next to a competitor's package name.

Price the ordinary bad month

A good price should survive normal friction. Test the package against ordinary scenarios:

• One backup failure every week.
• One vendor case every month.
• One onboarding gap discovered after start.
• One after-hours request.
• One security alert that needs investigation.
• One aging workstation or unsupported app.
• One client contact who bypasses the queue.
• One monthly review that exposes a decision or exception.

If the package fails those ordinary scenarios, the price is too low or the scope is too broad.

Separate recurring, project, incident, and exception work

Undercharging often starts when every kind of work falls into the monthly plan.

Create four buckets:

• Recurring service: predictable support, monitoring, maintenance, patch review, backup review, access review, documentation upkeep, ticket handling, and monthly evidence.
• Project work: migrations, new deployments, cleanup of inherited problems, major application changes, network redesign, onboarding remediation, and planned upgrades.
• Incident work: ransomware, account takeover, active malware, data exposure, major business interruption, and response work that interrupts normal service.
• Accepted exceptions: risks the client chooses not to fix yet, with owner, date, next review, and impact.

The monthly review checklist should expose which bucket work belongs in. If the same exception appears every month, it is no longer background noise. It is a scope, risk, or pricing decision.

Where small MSPs undercharge

Undercharging rarely comes from one missed line item. It usually comes from responsibility leaking through unclear scope.

• "Quick question" work that becomes daily consulting.
• Devices that are not counted but still supported.
• After-hours support treated like normal service.
• Vendor tickets that consume MSP time but are not priced.
• Backup expectations that include restore responsibility without restore testing.
• Security language that sounds broader than what the team actually verifies.
• Onsite work assumed included because the client is nearby.
• Old servers and unsupported apps priced like clean modern environments.
• Client-caused delays that look like MSP SLA misses.
• vCIO-style planning included accidentally through unlimited advisory calls.

Each leak may look small. Together they erase margin.

Pricing models and tradeoffs

No model saves a weak scope. Pick the model your team can explain, operate, and audit monthly.

• Per user: easy for client budgeting, but risky when device count, shared workstations, or support behavior varies widely.
• Per device: closer to endpoint workload, but can miss heavy user support and SaaS administration.
• Per site: useful when network, internet, and onsite expectations vary by location.
• Flat monthly: simple to sell, but dangerous without tight exclusions and a clear asset baseline.
• Hybrid: useful when you need a base fee plus variables for users, devices, sites, security controls, backups, or after-hours coverage.

If your tool stack selection framework adds per-endpoint cost, alert review time, reporting obligations, or contract minimums, the pricing model has to reflect that. A cheap stack that creates noisy tickets is not cheap.

Security is not free language

Security words create responsibility. The NIST Cybersecurity Framework 2.0 separates governance, identification, protection, detection, response, and recovery. If your monthly plan uses security language, decide which of those functions are actually included and which require a project, incident response scope, or client approval.

The FTC cybersecurity guidance for small businesses reinforces practical basics such as access, data protection, backups, and response preparation. Those basics still require MSP labor: configuration, review, alert handling, documentation, client explanation, and follow-up.

Tie every security promise to the security baseline for small MSPs:

• MFA review.
• Admin account review.
• Endpoint alert ownership.
• Patch exceptions.
• Backup failure review.
• Restore-path checks.
• Offboarding exceptions.
• Open client decisions.

If those items are included, price them. If they are not included, do not let the proposal sound like they are.

Service desk load belongs in the price

Pricing and service desk design are the same conversation from two angles. The small MSP service desk model should tell you what the monthly plan must fund:

• Ticket intake.
• Triage.
• Priority handling.
• Owner assignment.
• Waiting-on-client and waiting-on-vendor follow-up.
• Escalation.
• Closure evidence.
• Queue review.

If every support request is treated as urgent and included, the price is not a managed services price. It is an unlimited labor promise with a monthly invoice.

Boundaries that should be explicit

Write these boundaries into the offer before the client needs them:

• Onsite work: included visits, travel limits, emergency visits, and minimum charges.
• After-hours work: what qualifies, who can approve it, and how it is billed.
• Vendor coordination: what is included, what becomes project work, and what depends on the vendor.
• vCIO or strategy work: review cadence, planning sessions, budget support, and what is outside normal support.
• Incident response: when normal SLA language stops and incident handling begins.
• Remediation: inherited risk, unsupported systems, missing backups, weak identity controls, and cleanup discovered during onboarding.

This is where pricing connects back to what is a small MSP. The business is small because capacity is visible. A boundary is not a lack of service. It is how the MSP keeps the service real.

Discount rule

Before discounting, remove responsibility.

A cheaper plan should include less scope, slower response, fewer included channels, fewer managed systems, lighter reporting, fewer security controls, or less advisory access. It should not be the same promise with worse margin.

Examples:

• Remove after-hours support instead of discounting the same response promise.
• Exclude onsite work instead of absorbing travel and interruption.
• Move restore testing to a paid add-on if backup monitoring is the only included recurring task.
• Reduce monthly review depth if the client chooses a lighter plan.
• Require paid remediation before including unsupported systems in the managed scope.

Discounts also need an expiration rule. A temporary ramp, migration period, or nonprofit accommodation should have a date, scope, and reason. Otherwise the discount becomes the real price.

Client explanation

Use plain language:

This monthly service is priced around the systems we manage, the response level you expect, the security controls we verify, and the time needed to keep the environment supportable. Items outside that boundary are handled as projects, incidents, or separate approvals.

That is better than hiding behind package names. Clients may not love every boundary, but unclear boundaries create worse conversations later.

Common mistake

The common mistake is pricing from fear: fear of losing the deal, fear of looking expensive, or fear that a smaller client cannot afford the real cost.

If the price cannot fund the promise, the contract is usually not affordable for the MSP either.

When to change level

Raise pricing when ticket volume grows without scope change, vendor coordination increases, endpoint count drifts, security review becomes heavier, clients bypass the queue, after-hours work becomes normal, or monthly review keeps exposing unpriced risk.

Also raise pricing when your own delivery gets better. Better documentation, stronger security review, cleaner backup proof, and disciplined service desk work are not just operational improvements. They are part of the promise the client is buying.