msp-maintenance

{{COMPANY_NAME}} Proactive Maintenance Operations

Defaults you must review. The specific numbers in this skill are shipped example defaults from a working MSP. Review and replace them with your own before anything goes client-facing.

This skill is the source of truth for the recurring work {{COMPANY_NAME}} does when nothing is broken: patching, backup verification, monitoring, on-call coverage, and controlled change. This is the substance behind the managed fee. The reactive desk (msp-helpdesk) is what clients see; this cycle is why they see it rarely.

One liability fact shapes the whole skill, inherited from msp-legal: the MSA's ransomware cost allocation carries a negligence carveout. {{COMPANY_NAME}}'s protection in a bad scenario is a dated log showing the routine ran: patches applied, backups verified, alerts handled. Every section below ends in a record because the record is part of the service.

---

Patching (example default)

Workstations: automated weekly patch cycle through the RMM. Reboots enforced monthly at minimum; a machine that has dodged its reboot past the deadline gets scheduled with the user, not skipped. Third-party application patching rides the same weekly cycle where the RMM covers the app.

Servers: monthly maintenance window, the third Thursday, 8:00 pm to midnight, {{TIMEZONE}}. Sequence per server: snapshot or verified backup point first, then patches, then reboot, then service verification against a per-server checklist (services up, backups scheduled, key app responds). Clients with affected services get the planned-maintenance notice (msp-client-comms template 1) at least 3 business days ahead.

Out-of-band: critical or actively-exploited vulnerabilities do not wait for the window. Test, then deploy as soon as reasonable, any day. If the fix is disruptive, use the emergency maintenance variant of the notice: one honest sentence on why it cannot wait.

Exceptions: a client or app that cannot tolerate a patch gets a documented exception with a review date, not a quiet skip. A client who refuses patching against recommendation is a Risk Acceptance Waiver conversation (msp-legal).

Record: patch status per endpoint lives in the RMM; the monthly window gets a closing note (what was patched, what was deferred and why). This feeds the QBR scorecard's Updates row.

---

Backup Verification (example default)

• Every business day: backup job results checked. A failed job is a P2 ticket (msp-helpdesk) the same morning, worked until the backup chain is healthy again. Two consecutive silent days on any job is treated as a failure even if no alert fired.
• Every month, per client: one hands-on test restore (a file set, mailbox item, or VM boot, rotated so restore types vary through the quarter), logged with date, what was restored, and result. This is what lets {{COMPANY_NAME}} say "we verify your backups monthly" in writing and what feeds the QBR scorecard's Backups row honestly.
• A failed test restore is a P1-adjacent event: treat the client as effectively unprotected until the chain is fixed and a re-test passes. Do not sit on it until the QBR.

Record: the restore log (date, client, scope, result, tech) is the single most important document in this skill. In a ransomware dispute it is the difference between a defensible posture and the negligence carveout.

---

Monitoring and Alert Triage

The rule that keeps a small team sane: an alert is either actionable or it is tuned out of existence. An alert nobody would act on is noise, and noise trains the desk to ignore the one that matters.

• Alerts that indicate business impact map into the msp-helpdesk priority matrix and become tickets (server down or unreachable: P1 path; backup failure: P2; disk trending full: P3 with a scheduled fix). Informational alerts do not become tickets; they get tuned.
• Duplicate and flapping alerts are deduplicated at the monitoring tool, not in someone's inbox.
• After hours, only P1-class alerts page the on-call phone. Everything else waits for the next business morning, consistent with the after-hours rules in msp-helpdesk.
• New client environments get a tuning pass at onboarding (msp-onboarding) and a second pass at the 30-day review; steady-state environments get re-tuned whenever a week produces alerts nobody acted on.

---

On-Call (example default)

• Weekly alternating rotation between on-call staff. The {{PHONE}} forward points at the current primary; if the primary does not respond within 15 minutes, it rolls to the secondary.
• Handoff is deliberate: a two-minute check-in at rotation change covering open P1/P2 items, fragile clients, and anything mid-change.
• Vacations, sick days, and conflicts get swapped in advance on the shared calendar. The rotation is boring on purpose; surprise coverage gaps are how the P1 promise breaks.
• After-hours work billed to clients follows the multipliers in msp-pricing (1.5x after-hours, 2x holiday), per the client's Order.

---

Change Management

For risky changes (firewall and network changes, DNS, server configuration, tenant-wide settings, anything that can take a client offline):

1. Write the change down first: what, why, when, blast radius, and the rollback step. Two sentences is fine; zero sentences is not.
2. Second set of eyes from the owner or a designated senior tech for anything that touches a whole site or tenant.
3. Client notice through msp-client-comms when users could notice the change; the planned or emergency maintenance template as fits.
4. Rollback ready before starting, including config export or snapshot where the platform allows.
5. Log the change in the client's documentation in the same sitting.

A change that skipped these steps and went fine is still a process failure; the one that goes wrong without them is an outage plus a liability problem.

---

Documentation Currency

The rule from the documentation-system school, adopted: update the doc in the same session as the change. Passwords rotated, configs changed, hardware swapped, vendor contacts updated: the client's documentation reflects it before the ticket or change closes. Stale documentation surfaces at the worst moments (an incident, an offboarding handoff) and both of those moments are already covered by promises this suite makes (msp-helpdesk, msp-offboarding).

---

Vendor and License Touchpoints

• License counts get trued against reality during the monthly count reconciliation the Service Order defines; pass-through licensing follows msp-pricing.
• Vendor contract renewals, warranty expirations, and OS end-of-life dates feed the QBR horizon list (msp-qbr); this skill's job is making sure they are recorded when first seen, not reconstructed at QBR prep.
• {{COMPANY_NAME}} is the client's vendor liaison per the service catalog; vendor tickets follow the msp-helpdesk vendor category so time is captured.

---

Setup Decisions

The values below shipped as example defaults from a working MSP, and the items after them are still genuinely open questions upstream. Settle all of it for your own shop before this skill goes client-facing:

• Patching: shipped default is workstations weekly automated with monthly enforced reboots; servers in a monthly window, third Thursday 8:00 pm to midnight {{TIMEZONE}}, snapshot first; critical vulnerabilities out-of-band.
• Backups: shipped default is job checks every business day (failures are P2 the same morning); one logged test restore per client per month.
• On-call: shipped default is a weekly alternating rotation between on-call staff, with a 15-minute response roll-over to the secondary, swaps planned in advance.
• The per-server verification checklist contents (the standing proposal above is the minimum set; decide your own).
• Which restore types rotate through the monthly test (proposal above: file set, mailbox item, VM boot across a quarter).
• Whether change notices go to all clients on shared infrastructure or only directly affected ones (proposal above: directly affected only).