The Spreadsheet That Eats Your Practice Lead

In every MSP with more than ten ServiceNow tenants, there is a spreadsheet. It lists every customer instance, the current release, the current patch level, the next patch the customer is due to take, and the change window when it might happen. The practice lead updates it manually. Customers occasionally update their own row. The spreadsheet is wrong within two weeks of being finalised. A patch lands that nobody had on the roadmap. A different patch is held back because the customer skipped two of them and now needs a coordinated jump.

Patch Manager is the scheduled MSP Agent that replaces that spreadsheet with a generated, evidence-backed monthly roadmap. It runs across every connected tenant, reconciles their current release and patch level against ServiceNow's public patch metadata, and produces a single prioritised roadmap that a service delivery manager can take into their monthly governance meeting.

This article describes what Patch Manager looks at, how it sequences the work, and where it hands off to humans.

What Patch Manager Sees Per Instance

For each tenant connected to your SnowCoder workspace, Patch Manager pulls the same six categories of data every month.

Current release and patch level: Source release (Zurich, Australia, or later), patch identifier, hotfix identifier.
Patch eligibility: What patches are available for that release line, including security patches that ServiceNow has marked as recommended or required.
Pending update sets: Open and in-progress update sets that would be affected by a patch.
Plugin and store app inventory: All installed plugins and store apps, including version state.
Recent ATF runs: Pass rate and failure clusters that indicate whether a patch can be safely applied without first remediating tests.
Change calendar: Approved change windows already booked against the instance.

None of these inputs are new. What is new is having them reconciled across the entire estate in one place, every month, without a human curating the data.

How the Roadmap Is Sequenced

Patch Manager does not just list available patches. It sequences them. The output is an ordered, time-boxed roadmap with a recommended window per tenant. The sequencing logic prioritises four signals.

Security severity: Patches that close a published CVE or a ServiceNow security advisory move to the top regardless of customer preference.
End-of-support proximity: Instances on a release that loses ServiceNow support within the next two quarters get prioritised over instances that are comfortably in support.
ATF readiness: Tenants with a healthy ATF baseline are scheduled earlier because the regression risk is lower.
Change window availability: Tenants with already-approved change windows are scheduled into those windows rather than having a new window negotiated.

The sequencing is visible in the output. The roadmap notes why a tenant is scheduled in week one versus week three, so when a customer pushes back the SDM has the rationale ready.

Sample Roadmap Output

The monthly artifact looks like this. It is generated as both a structured JSON payload that can be imported into your delivery tooling and a human-readable summary for the SDM.

Monthly Patch Roadmap - June 2026
Estate: 52 tenants connected

Week 1 (priority: security)
  - acme-prod (Zurich Patch 6 -> Patch 7): CVE close, ATF green
    window: Sat 06 Jun 22:00-02:00 UTC (already approved)
  - globex-prod (Australia Patch 1 -> Patch 2): CVE close, ATF green
    window: Sun 07 Jun 03:00-05:00 UTC (already approved)

Week 2 (priority: end-of-support)
  - initech-prod (Zurich Patch 4 -> Patch 7, two-step): no CVE, ATF amber
    window: pending negotiation, recommend Sat 13 Jun
    notes: Skipped patches 5 and 6. Patch Manager recommends
           staging via test instance first.

Week 3 (priority: ATF readiness)
  - umbrella-prod (Zurich Patch 5 -> Patch 7): no CVE, ATF green
    window: Sat 20 Jun 22:00-02:00 UTC
  - hooli-prod (Australia Patch 1 -> Patch 2): no CVE, ATF green
    window: Sun 21 Jun 03:00-05:00 UTC

Held (manual review required): 4 tenants
  - waystar-prod: ATF failures > 50 in last run
  - pearson-prod: 12 open update sets, recommend close before patching

Held tenants are the ones the agent will not schedule automatically. They get a recommendation and an owner, and they stay held until the recommendation is actioned.

Coordinating With Upgrade Readiness

Patches and full-release upgrades are different beasts, but they share a roadmap. When Patch Manager spots a tenant approaching the end of its release line, it triggers a hand-off to the on-demand Upgrade Readiness Agent. The handoff is a recommendation in the roadmap that says "run Upgrade Readiness now so a full release upgrade can land in the next quarter."

The two agents share the same connected estate, so when the Upgrade Readiness Agent produces its audit report, Patch Manager picks up the result the next month and adjusts the patch sequencing. A tenant that has a confirmed Zurich-to-Australia upgrade in week eight does not get a Zurich patch in week six unless it is a security patch.

What Patch Manager Does Not Do

Patch Manager does not apply patches. It does not change customer change windows without approval. It does not bypass governance. The agent is a planning tool, not an actuator. The application of patches still happens through ServiceNow's native upgrade flow, controlled by your delivery team. That is by design. The point of the agent is to make the decision rigorous and the roadmap defensible. The execution stays where the SOC 2 controls already exist.

Patch Manager is part of the Enterprise tier of SnowCoder, alongside the rest of the MSP Agents and the Yeti Build Agent. Yeti AI Chat and the MCP integration are available across every tier.

Patch Manager for MSPs: Estate-Wide Upgrade Roadmaps Every Month