MSP patch management scope and pricing template
An MSP patch management quote needs a supported app list, an update process, an exception budget, and someone authorized to approve disruption. Put those in the scope before you price the endpoints. Otherwise, one awkward installer can turn a recurring service into a packaging project nobody sold.
This template is for the vCIO or account manager defining that service with delivery. It works whether your MSP uses RMM patching, Intune, or a separate app-management tool. Keep the client estate, app owners, and costs attached to the same service definition. In a Connectwise Manage shop, record which agreement and service item will carry the approved recurring work.
The useful output is a service your technician, client contact, and owner can describe the same way.
What belongs in the patch management scope?
Separate routine OS updates, supported third-party app updates, and custom packaging. Give each a delivery rule and a commercial treatment.
NIST's enterprise patch management guidance defines the work as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. That last step needs time in the service. A deployment job finishing is only one part of the evidence.
Use this table as the first page of the service definition. Replace every bracketed field before sending a quote.
| Scope field | Fill in before pricing | Evidence or acceptance |
|---|---|---|
| Managed estate | [Client], [sites], [eligible endpoint count], [supported OS versions], [management platform] | Reconcile enrolled devices with the client's agreed asset list; identify offline and unmanaged devices separately |
| Supported apps | [Named app list], [versions or release channels], [catalog or installer source] | Delivery confirms each app is supported by the chosen workflow |
| Routine OS updates | [Update types], [approval cadence], [maintenance window and time zone] | Record installation status, pending restarts, and unresolved failures |
| Third-party updates | [Named apps], [review cadence], [pilot group], [broad rollout rule] | Pilot results and named approval recorded before wider assignment |
| Custom packaging | [App and version], [configuration], [dependencies], [install and uninstall behavior] | Package tested against the agreed acceptance record |
| Restarts | [Permitted window], [notification], [deferral rule], [client approver] | Pending restarts remain visible until completed or accepted as an exception |
| Failed deployments | [Included investigation time], [retry approach], [escalation owner] | Record cause, action, next owner, and any separately approved work |
| Reporting | [Cadence], [recipients], [covered-device denominator] | Distinguish successful, failed, offline, excluded, and unreported devices |
| Service changes | [Request owner], [approval route], [effective date] | New apps, sites, or requirements receive an explicit scope and price decision |
Avoid a promise that every app on every machine will always be current. Define the supported estate and the exceptions you can actually manage.
The MSP scope of work template supplies the wider project structure. This worksheet owns the recurring patch/app service and its packaging boundaries.
Who owns the awkward app?
Ask these questions with delivery before the client meeting:
- Who supplies the installer, redistribution rights, license material, and vendor contact?
- Can the app install without user interaction? Does it require a database, driver, certificate, or another app first?
- Which user or system context does it need, and which business function must still work after the update?
- Who can provide a representative test device and approve the result?
- Who owns version changes, package maintenance, and vendor escalation next month?
- What happens if rollback is unavailable or requires a separate recovery process?
For Intune Win32 deployment, Microsoft requires silent installation. Interactive installers are unsupported. Its app setup also includes requirements, detection rules, dependencies, return codes, restart behavior, and assignments. Verify these against the actual package before treating it as routine recurring work.
A client saying "we have the installer" answers very little of that.
The Intune MSP pricing and scope guide covers the wider endpoint-management service. If you are still choosing packaging tooling, the Robopack vs Patch My PC comparison addresses that decision. Either way, the app owner and acceptance test belong in your scope.
Copyable app intake record
Client / service revision:
App / version / release channel:
Business function and client app owner:
Supported endpoint group / count:
Installer source / rights / license prerequisites:
Silent install / uninstall / execution context:
Dependencies / configuration / detection method:
Representative pilot devices:
Business acceptance test and approver:
Restart / outage window and time zone:
Recovery or rollback method and limits:
Package maintenance owner:
Included investigation allowance:
Separate-work approval route:
Ready for recurring service: yes / no / conditional
Unresolved items / owner / review date:
A conditional app needs a named condition and a deadline. Keep it out of the standard recurring app list until delivery accepts it.
Set the exception rules before rollout
Use a responsibility matrix to make the service operational. The choices below are a template, not a universal service-level commitment. Your delivery lead must set timings the MSP can staff.
| Situation | Proposed service treatment | Decision owner |
|---|---|---|
| Routine update to a listed, supported app | Follow the agreed pilot and maintenance process | MSP service lead; client app owner accepts business behavior |
| Client cannot supply a working silent installer | Hold packaging; assess an alternative or a separate project | Client app owner and MSP technical lead |
| Device remains offline | Report as outside current deployment reach; agree reconnect/escalation steps | Client contact and MSP service desk |
| User repeatedly defers a restart | Follow the agreed deferral and escalation policy | Client approver authorizes the next action |
| Update breaks a business workflow | Pause wider rollout and use the agreed recovery process | MSP incident lead and client app owner |
| Client requests a new app or custom configuration | Estimate packaging and ongoing maintenance before acceptance | Account manager, delivery lead, and client buyer |
| Urgent out-of-band update | Use the emergency change route; check staffing and commercial treatment | Authorized MSP lead and client emergency contact |
| Unsupported app must remain | Record business owner, temporary measures, review date, and replacement decision | Client risk owner with MSP advice |
Do not let a labor allowance become permission to abandon an incident. Follow the agreed escalation and safety process, then separate the included work from any additional commercial authorization. If the client cannot be reached, the emergency authority should already be documented.
Use the shared responsibility matrix when the client, MSP, and application vendor each own part of the fix.
Price the recurring service and packaging separately
Build the price from the actual client estate and delivery effort. Include tooling, routine operations, reporting, exception work, and a realistic labor cost basis. Exclude costs already recovered by another service line, or explicitly allocate them once. Double-counting a license is a particularly dull way to lose trust.
A useful quote has separate lines for:
- Recurring supported-estate management: eligible endpoints, named apps, maintenance windows, reporting, and a defined exception allowance.
- Initial custom packaging: app/version/configuration, dependencies, test effort, pilot acceptance, and handover.
- Ongoing custom-app maintenance: release monitoring, package changes, retesting, and the frequency or allowance you priced.
- Approved additional work: app remediation, a new version that materially changes requirements, or a separately scoped emergency service.
A per-endpoint price can be convenient for billing. The cost model still needs the work that varies by app and client.
Worked example: recurring patch and app management
Illustrative scenario only. These are invented planning inputs, not market prices, customer results, or Scopable pricing. Assume a client with 100 eligible endpoints, a defined supported app list, and an MSP planning direct gross margin of 40%. Finance should confirm which costs belong in your own margin definition.
| Monthly cost input | Scenario calculation | Cost |
|---|---|---|
| Allocated tooling | 100 endpoints at $2 each | $200 |
| Routine review, pilots, and reporting | 4 hours at $60 loaded labor cost | $240 |
| Included exception allowance | 2 hours at $60 loaded labor cost | $120 |
| Total planned direct cost | Tooling plus routine and exception labor | $560 |
Price from the cost and margin target:
Required revenue = direct cost / (1 - target gross margin)
Required revenue = $560 / (1 - 0.40) = $933.33... per month
Scenario quote rounded up to $940 per month
Per-endpoint equivalent at 100 endpoints = $9.40
Planned gross profit = $940 - $560 = $380
Planned direct gross margin = $380 / $940 = 40.43%
Now suppose that client needs six additional investigation hours that the MSP absorbs without another charge. The extra direct cost is $360. Total cost becomes $920, leaving $20 gross profit and 2.13% direct gross margin on the same $940 revenue.
That is the reason to discuss custom-app and failure handling before you sell an endpoint rate. A lower tool price cannot resolve an undefined labor promise.
Worked example: one-time custom packaging
For the same hypothetical client, assume a separate package needs five engineering hours and one pilot/acceptance hour. At $60 loaded labor cost, planned direct cost is $360. At the same 40% direct gross-margin target, the scenario price is $600.
That package fee covers the named version and configuration. Define what a later vendor change triggers. Do not imply that one successful package buys indefinite maintenance.
The MSP margin protection guide explains the wider quoting discipline. Keep this worksheet's costs visible when the service becomes a quote.
Copy the client-facing service summary
Adapt this operational summary to your agreement with the appropriate commercial and legal review. It is not legal advice or a ready-made contract.
Service: Patch and app management for [client / sites].
Covered estate: [eligible endpoint group and count].
Supported software: [OS list and named app schedule].
Routine process: [review cadence], [pilot approval],
[maintenance window / time zone], [restart policy].
Included operations: [routine tasks], [reporting cadence],
and [defined investigation allowance / escalation process].
Custom packaging: [named app / version / configuration],
priced separately at [fee], with [acceptance test / approver].
Ongoing package maintenance: [included scope and price, or excluded].
Exceptions: Offline devices, unsupported software, vendor defects,
and unmet prerequisites are recorded with an owner and next step.
Additional remediation follows [approval and pricing route].
Urgent issues follow [emergency authority and response process].
Recurring charge: [amount / billing unit / minimum / review trigger].
Estate and scope review: [cadence and material-change triggers].
In the QBR, show the buyer the decision: approve the recurring supported service, fund the custom work, or change the app requirement. Keep technical unknowns visible until someone resolves them.
Accept the service before handing it to delivery
Before the recurring charge starts, the account manager and service lead should be able to find:
- The approved estate and app schedule, linked to the service revision.
- The pilot devices, detection result, and client business acceptance.
- The restart window, failure escalation, emergency authority, and recovery limits.
- The packaging fee and future-maintenance treatment for each custom app.
- The cost model, quoted recurring amount, and scope-change trigger.
- The agreement/service item and owner who will keep that record current.
Scopable's assessment and scoping workflow organizes client findings, assumptions, and recommendations into reviewable scope before quote work. Use it to carry the service decision forward. Scopable does not patch endpoints or package applications; your delivery tools and team perform that work.
For connected-input context, the live client data quoting guide explains how client facts support a defensible quote. An app-specific acceptance test still needs the MSP and the client app owner.
Start a free Scopable account when you are ready to turn one client's app-management findings into reviewed scope and a quote.
