MSP documentation and runbook scope + pricing template

Price MSP documentation work by the systems, procedures, and validation you agree to deliver. Separate the initial cleanup from ongoing updates, and quote automation builds separately from written runbooks. A technician should be able to follow the finished procedure without calling its author. That is a more useful acceptance test than counting pages.

This worksheet is for the vCIO or account manager at a Connectwise Manage MSP that manages client endpoints and Microsoft 365. Use it when a QBR exposes missing recovery instructions, onboarding reveals contradictory records, or a documentation-platform decision turns into a cleanup project.

The prices below model the MSP's service labor. Documentation-platform licenses and automation subscriptions need their own cost lines.

Find out whose documentation problem you are pricing

Check the managed-services agreement before proposing an extra fee. Routine updates your team already owes belong in that delivery cost. Historical cleanup, a new acquisition, undocumented client changes, and a newly requested workflow may require separate scope. Agree on the boundary with the client before work starts.

Start with one client and a bounded inventory. Reconcile its PSA record, RMM inventory, Microsoft 365 tenant, and existing documentation. Keep discrepancies visible: two records for one firewall, an application with no owner, a backup job with no recovery procedure. A synchronized asset record can still leave the next technician unable to restore the service.

NIST's Cybersecurity Framework 2.0 includes maintaining hardware inventories in ID.AM-01, software and service inventories in ID.AM-02, and configuration-management practices in PR.PS-01. Those outcomes help explain why the records matter. They do not prescribe your documentation fee, certify the client, or make this worksheet a compliance assessment.

For the broader discovery process, use the existing MSP project scoping guide. This worksheet handles the documentation deliverables and the labor needed to make them usable.

Copy this documentation scope worksheet

Replace every bracketed field before sending the proposal. Quantities below are fields to fill in, rather than an assumed entitlement for every client.

Write the repository or documentation location into the scope. Also specify who can read, edit, approve, and export each class of record. Keep passwords, tokens, and recovery codes in an approved secrets system; a runbook should point to the authorized retrieval process.

A baseline for accessible systems cannot establish facts about a server the client refuses to let you inspect. List inaccessible systems, missing credentials, and unresolved ownership as explicit exceptions. Price further investigation after the client supplies access.

Make every runbook pass a handoff test

A runbook describes a repeatable procedure. It may be performed by a person, executed as automation, or combine both. Writing the procedure does not include building its automation unless the quote says so.

Use this card for each procedure:

Runbook name and version:
Client, site, and tenant:
Business owner and technical owner:
Trigger and authorized requester:
Systems touched and required permissions:
Inputs and prerequisite checks:
Ordered steps and expected result:
Approval required before a sensitive action:
Stop conditions and partial-failure handling:
Recovery or reversal steps, including irreversible actions:
Evidence to retain and storage location:
Test environment and acceptance cases:
Second technician and acceptance result:
Next review date and change triggers:

For example, scope a Microsoft 365 new-starter procedure around a named tenant and a defined employee type. Record who approves the request, which license choices the client authorizes, and what to do when the requested license is unavailable. Give the technician a stop condition for a missing manager approval or an ambiguous tenant.

Acceptance should include those failure cases. A happy-path walkthrough with the author watching proves less than a second technician using the procedure independently. Keep the test inside an authorized environment and avoid real hires or production account changes just to demonstrate the document.

Treat an offboarding runbook as a separate procedure with its own retention, access-removal, and business-approval requirements. Reversing the starter checklist is an unsafe substitute for agreeing what happens to the departing user's data.

Separate automation build work from documentation

Automate a procedure only after the inputs, approval rules, and exception path are stable enough to describe. Keep a human approval where the client decision cannot safely be inferred.

An automation quote needs additional scope:

• Named trigger, input format, target systems, and permission boundary.
• Build and testing effort, including missing inputs and partial failures.
• Duplicate-request handling, retry limits, and the evidence left in the ticket.
• Release approval, disable procedure, and recovery steps for each action.
• An owner for credential changes, API changes, monitoring, and retirement.

A draft or test label does not make execution harmless. Microsoft's Azure Automation runbook guidance says that testing executes the draft against real resources. Publishing replaces the published version. For an Azure Automation build, include safe test resources and release handling in the labor estimate. Check the execution behavior of whichever automation platform you actually use.

Documentation cleanup can reveal that the proposed automation should wait. If the client cannot name the approver or the required exception handling, finish the written procedure and resolve those decisions first. The quote should allow that outcome without promising an automation deployment.

Price the project and the maintenance separately

Estimate discovery, writing, testing, review, and handoff as work. Include the cost of the second technician's acceptance test. If the estimate assumes every record is accurate and every client answer arrives immediately, revise it before setting a fixed price.

Use your own loaded delivery costs and accounting policy. For a service-cost model:

Modeled delivery cost = labor cost + allocated tools + direct delivery costs
Sell price at target gross margin = modeled delivery cost / (1 - target margin)
Modeled gross margin = (sell price - delivery cost) / sell price

The following is an illustrative scenario in US dollars, not a market benchmark, a Scopable price, or a customer result. It assumes one client, a bounded baseline, three human-run procedures, and one included review round. Platform licenses, tax, travel, and after-hours work are excluded; add any costs your scope requires.

At a 40% modeled gross-margin target, the sell price is $2,640 / 0.60 = $4,400. That target is an assumption for this example, rather than a recommended industry margin. Margin and markup use different denominators; multiplying cost by 1.40 would produce a different result.

Four additional unpriced hours at $90 add $360 to delivery cost. At the same $4,400 price, modeled gross margin falls to 31.82%. Use that sensitivity check to decide how many review rounds and undocumented exceptions a fixed fee can carry.

Keep these follow-on lines separate from the initial project:

The monthly example assumes two hours of defined maintenance effort, not unlimited documentation requests. If three extra labor hours at $75 arrive without extra revenue, that month's modeled gross profit becomes negative $105. Define the work covered by the monthly line and how excess requests are approved. If maintenance is already included in the managed-services bundle, account for its cost there instead of charging for the same obligation again.

The optional automation price covers only the specified build and test effort. Add platform charges, continuing support, deployment work, and other direct costs when they apply. It carries no time-savings or return-on-investment promise.

Agree on what happens after handoff

Assign routine record updates to the person closing the related change or ticket. Give the documentation owner a scheduled review for records that can drift without a ticket, such as business contacts or supplier escalation paths. Choose the cadence based on the service and contract.

Separate corrections from new requests. If the MSP delivered a procedure that fails its agreed acceptance case, handle the defect under the agreed correction terms. A new application, extra tenant, changed approval policy, or additional automation is a scope change. The MSP change-order template gives that approval a written home.

For the client conversation, adapt this language to your agreement:

The project covers the listed systems and procedures, one review round, and the agreed handoff tests. The monthly service maintains the named records within the stated effort allowance. Additional systems, new procedures, automation builds, and changes to the approved workflow require a revised scope and price before work starts. Existing managed-service obligations remain unchanged.

Have the appropriate contract reviewer check the final terms. This is working scope language, not a substitute for legal advice.

Turn documentation findings into reviewable scope

At the next QBR, bring the unresolved items as decisions: authorize access, name an application owner, fund recovery instructions, or defer a defined risk. Each decision should have a responsible person and a next step. Avoid selling a vague cleanup project when the client can approve a specific deliverable.

Scopable's assessment and scoping workflow keeps client findings, assumptions, constraints, and reviewed recommendations together before quote work. Use it to carry the documentation gaps into a scope your delivery team can review. Your documentation platform holds the procedures, and your automation platform executes the approved workflows. Scopable does not write or run those procedures for you.

To start organizing a client's findings before the quote, start Scopable for free.