IT managed services · Service delivery
Monthly patch management
Patch every client the same way each month, without a bad update reaching the whole office. Patches go to a pilot group first, the client confirms the window and the devices that must not restart, and the rollout waits for approval.
- Duration: 1 to 2 weeks
- How often: Every month, for each client
- Steps: 7 steps
- AI agents: 1 AI agent
- Approvals: 2 approvals
Free plan, no credit card needed.
What changes with this template
Without it
Patches go to every device at once, and a bad update hits the whole client.
Staff lose work when a machine restarts in the middle of a long job.
The monthly patch report is a raw export nobody at the client reads.
Nobody remembers why a patch was held back last month.
With it
A pilot group gets the patches first, and the rollout waits for approval.
The client names the devices to leave out before the window.
An AI agent drafts a plain-language report, and the service delivery manager approves it.
Every held patch has its reason on the run.
The template, step by step
Each step says who does it: someone on your team, an AI agent, or the client through a shared link. An approval keeps every later step locked until it is given.
- Done by your team
- Done by an AI agent
- Done by the client, through a shared link
Starts when
The vendors release their monthly updates. The systems engineer starts a run for the client with this month's patch list.
- 1
Review this month's patches
Day 1Systems engineer · Team
Read the vendor release notes and known issues, decide which patches to deploy and which to hold, and send the client contact the shared link.
Checklist
- Security updates listed
- Known issues checked
- Each held patch has a reason
- Shared link sent to the client contact
Fields to fill in
- Patches to deploy (required)
- Patches held back and why
- 2
Confirm the window and the exclusions
Days 1 to 3Client contact · Shared link
Through the shared link, the client confirms this month's maintenance window, agrees which devices patch first as the pilot group, and names any devices that must not restart, such as a machine running a long job.
Checklist
- Pilot devices agreed
- Staff told about the restarts
Fields to fill in
- Confirmed maintenance window (required)
- Devices to leave out
- Contact during the window
- 3
Patch the pilot group
Days 2 to 4Systems engineer · Team
Deploy the patches to the pilot devices the client agreed, then check that their users can work and that no new alerts appear in the RMM tool.
Checklist
- Pilot devices patched
- Pilot users can work
- No new alerts in the RMM tool
Fields to fill in
- Pilot result (required)
- Problems found in the pilot
- 4
Approve the rollout
Hidden from the shared linkDay 5Service delivery manager · Team
Check the pilot result, the client's window and the exclusions, and approve the rollout or hold it until the problem is solved.
Checklist
- Pilot passed
- Window confirmed by the client
- Exclusions set in the RMM tool
Approval: The rollout to the client's other devices stays locked until the service delivery manager approves it.
- 5
Roll out the patches and follow up failures
In the windowSystems engineer · Team
Deploy the approved patches in the window, retry the devices that failed and follow up pending restarts.
Checklist
- Patches deployed in the window
- Failed devices retried
- Pending restarts followed up
- A ticket for each device still failing
Fields to fill in
- Devices patched (required)
- Devices not patched and why (required)
- 6
Draft the patch report
Day after the windowPatch report writer · AI agent
The patch report writer drafts the client report: what was installed, what was held back and why, which devices failed and what happens next.
Fields to fill in
- Draft patch report (required)
Checked by: The service delivery manager corrects and approves the report in step 7.
- 7
Approve and send the report
Hidden from the shared linkWeek 2Service delivery manager · Team
Check the draft against the RMM tool, correct it, approve it and send it to the client contact.
Checklist
- Numbers match the RMM tool
- Held patches explained in plain language
- Each failed device has a ticket
Fields to fill in
- Report sent on (required)
Approval: The report goes to the client only after the service delivery manager approves it.
Done when
The approved patches are installed, every device that failed has a follow-up ticket, and the client has an approved report of what was installed and held back.
Make it yours. Rename steps, change owners and add checklist items, fields or approvals. The template is a starting point for the way your team works.
The AI agents in this template
An agent only works on its own steps, and a person on your team checks what it did. Anything an agent writes to a connected app waits for approval unless you allow it.
Patch report writer
Turns the month's patch decisions and results into a report the client can read.
What it does
- Reads the patch list, held patches, pilot result and rollout result on the run
- Follows the report outline in its step instructions
- Writes the draft report in plain language into its step
- Completes its step, so the review can start
Checked by: The service delivery manager corrects and approves the report in step 7.
Questions this template answers
Review the patches, test them on a pilot group, get the rollout approved and report to the client, in the same order every month. Steps 1 to 7 run that cycle, with the production rollout locked until it is approved.
Patch a small pilot group first and check that those users can work before anyone else gets the update. Step 3 records the pilot result, and step 4 approves the rollout only after the pilot passes.
Agree the window every month and let the client name the machines that must not restart. In step 2 the client contact confirms the window and the exclusions through the shared link, and step 4 checks that the exclusions are set in the RMM tool.
It should say what was installed, what was held back and why, which devices failed and what happens next. In step 6 the patch report writer drafts exactly that, and in step 7 the service delivery manager approves it before it goes to the client.
Write the reason down when you decide, not when the client asks months later. Step 1 records each held patch with its reason, and the approved report from step 7 explains it to the client.
Retry them, find out why, and turn every remaining failure into a ticket with an owner. Step 5 records the devices not patched and the reason, and step 7 checks that each one has a follow-up ticket.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.