MSP monthly review checklist for small teams

Short answer: A useful monthly MSP review turns recurring service into evidence and decisions. Review client health, security exceptions, backup proof, ticket patterns, aging work, scope drift, pricing flags, and the owner of every next action; skip dashboard theater that changes nothing.

Monthly review is proof, not a meeting

A monthly review is not valuable because it has a slide deck, a dashboard screenshot, or a calendar invite. It is valuable when it turns recurring service into visible evidence, open decisions, and next actions.

For a small MSP, the monthly review is where hidden work becomes manageable. It shows which clients are drifting, which tickets repeat, which backups are only assumed to work, which controls need attention, and which promises are starting to exceed the monthly price.

Do not build this as a heavy QBR process if you are a solo operator or a two-to-five person team. Build it as a short operating rhythm you can repeat.

Define the monthly review boundary

Before the checklist, define what the review is supposed to answer:

• Is the client still inside the service promise?
• Did the MSP perform the recurring work it sells?
• Which risks are open and waiting on the client?
• Which issues should become project work?
• Which tickets, alerts, or backup events require process changes?
• Which pricing or scope assumptions are no longer true?

This connects back to the client onboarding checklist. If onboarding did not capture systems, contacts, backups, vendors, exceptions, and supported scope, the monthly review will be forced to reconstruct the client from memory.

Client health snapshot

Start with a plain client health snapshot. This is not a satisfaction score. It is the operator view of whether the account is supportable.

Review:

• Primary business contact and technical contact still valid.
• Emergency contact and after-hours expectations still valid.
• Supported sites, users, endpoints, servers, and core applications.
• Known unsupported systems.
• Open vendor dependencies.
• Open project candidates.
• Open client decisions.
• Recent business changes that affect support.

If the snapshot exposes missing data, do not bury it. Send it back into onboarding-style cleanup. The client may already be live, but the work is still the same: identify the owner, the system, the risk, and the next action.

Security and identity evidence

The CISA CPG Checklist is useful because it turns security goals into items that can be checked. A small MSP should not copy every control into a client report. Use it to keep the review practical: identity, access, backups, logging, patching, and response path.

Review:

• Admin accounts added, removed, or changed.
• MFA exceptions.
• Remote access exceptions.
• Vendor accounts with privileged access.
• Former employees, contractors, or vendors still present.
• Break-glass or emergency account status.
• Security alerts that created tickets.
• Open client risk decisions.

If Microsoft 365 is in scope, Microsoft Secure Score can help identify posture changes and recommended actions. Treat it as a signal, not as the whole story. A score does not replace knowledge of client scope, accepted exceptions, or what the MSP is actually paid to manage.

For Google Workspace clients, the Workspace reports and audit and investigation tool can support review of usage, security events, admin activity, and sharing patterns when those areas are in scope.

Tie this section to the security baseline for small MSPs. If a control is sold as recurring service, the monthly review should show whether it was checked.

Backup and restore proof

Backups are one of the easiest areas to misunderstand. A dashboard can be green while the client still has uncovered data, stale credentials, broken restore assumptions, or unclear retention expectations.

The CISA StopRansomware Guide reinforces a practical point: recovery planning matters before the incident, not after. For an MSP, that means the monthly review should show backup status and restore confidence, not just product presence.

Use the backup restore testing checklist to define test depth, cadence, evidence, failure handling, and the commercial boundary behind that confidence.

Review:

• Which backup jobs succeeded, failed, or were disabled.
• Which systems or data locations are not covered.
• Which Microsoft 365 or Google Workspace data is covered.
• Which restore-path checks were performed.
• Which restore test failed or was postponed.
• Which backup alerts created tickets.
• Which retention or recovery expectations changed.
• Which client decisions are still open.

Do not say "backup is healthy" if no one knows what would be restored first during an outage. Say what was checked, what remains unknown, and what action is needed.

Ticket queue patterns

The ticket queue tells you whether the service model is working. One ticket can be noise. A repeated pattern is an operating signal.

Review:

• Top recurring ticket types.
• Tickets reopened after closure.
• Tickets waiting on client.
• Tickets waiting on vendor.
• Tickets blocked by scope.
• Tickets that should have been projects.
• Tickets that bypassed approved intake channels.
• Security events handled as normal support.

Use the small MSP service desk model to decide what the pattern means. If work enters through chat, calls, direct technician messages, and memory, the monthly review should not pretend the queue is healthy.

One useful question: what work would disappear if the client approved a project, changed a process, replaced a tool, or accepted a clearer support boundary?

Tool and vendor drift

Tools drift. Vendors change contracts. Alerts get noisy. Integrations break quietly. A monthly review should catch the operational drift before it becomes a margin problem.

Review:

• RMM coverage gaps.
• PSA queue or workflow friction.
• Documentation stale areas.
• Backup platform alerts or billing changes.
• Security tool alerts that are ignored because they are too noisy.
• Vendor renewals or price changes.
• Tools with poor export or exit paths.
• Integrations that no longer carry the work they were expected to carry.

This is where the tool stack selection framework becomes useful after the sale. A stack is not good because it looked complete in the demo. It is good when it still supports the work every month.

Exceptions and accepted risk

The monthly review should keep exceptions visible. If an exception disappears from the review, it has not been solved. It has only moved into memory.

Review each exception:

• Is the risk still present?
• Who owns the decision?
• Is the next action clear?
• Is the item still included, out of scope, or project work?
• Has the business impact changed?
• Does the client need to accept, reject, or approve work again?

Accepted risk does not mean the MSP agrees the risk is harmless. It means the client has made a visible decision. That decision needs a date, owner, and review rhythm.

Scope and pricing flags

Monthly review is also margin protection. If recurring service keeps absorbing project work, vendor wrangling, incident response, or unsupported applications, the agreement is drifting.

Look for these pricing flags:

• Ticket volume is higher than the account can fund.
• The client added users, devices, sites, or applications.
• Security review work expanded.
• Backup coverage expanded.
• Vendor coordination became recurring labor.
• Onsite work is being treated as included.
• Incident work is being handled as normal support.
• The client expects reporting that was never priced.

Use the managed services pricing guide when the review shows the monthly plan no longer funds the promise.

MSP business health check

The client review should not ignore your own business. The SBA guidance on managing business finances is a useful reminder that cash flow, receivables, and financial records need a regular rhythm. For a small MSP, that rhythm belongs near client health because operational drift becomes margin drift.

Review:

• Invoices unpaid by managed clients.
• Accounts below margin expectation.
• Tool costs that increased.
• Non-billable hours by account.
• Project work that has not been quoted.
• Agreements missing scope updates.
• Clients that need a price conversation.

This does not need to become accounting theater. It just needs to stop the MSP from discovering margin problems months late.

What to send to the client

Do not send every internal detail. Send what helps the client make decisions.

A useful monthly note can include:

1. What was reviewed.
2. What changed.
3. What is healthy.
4. What needs client approval.
5. What remains accepted risk.
6. What should become project work.
7. What the MSP will do before the next review.

Keep the language plain. A client does not need every alert ID. They need to understand what matters, who owns it, and what happens next.

Common mistake

The common mistake is turning the monthly review into a vendor-style QBR full of charts that do not change decisions.

If the review cannot produce a next action, an accepted risk, a project candidate, a scope correction, or evidence that recurring work happened, it is probably too decorative.

When to change level

Raise the monthly review process when a client has regulated data, frequent user changes, multiple locations, recurring security exceptions, cyber insurance requirements, or leadership asking for stronger reporting.

Raise your MSP process when reviews take too long to prepare, technicians collect evidence differently, clients repeatedly misunderstand scope, or pricing conversations happen only after the account is already unprofitable.