Report week at the MSP
Every month, a junior engineer spends days producing client reports. For each client, they run the patch report in the RMM, export it, trim the columns, paste it into a Word template with the client's logo, add a paragraph saying 'patching is up to date', and save it as a PDF. For clients with devices that failed to patch, they add a note, often without checking why.
The reports are long, technical and read by almost nobody. Then a client's cyber insurer sends a questionnaire asking for evidence of patching within a set period, and the report cannot answer it, because it shows patch status today rather than how long each patch took.
Why the RMM's reports are not enough
RMM tools have good data and generic reporting. What a client or insurer wants to see is simpler than the RMM's report and also slightly different.
- RMM reports list every patch on every device, which is more than a client can read.
- Exceptions are not explained: offline devices, deferred feature updates, failed installs.
- Third-party application patching is reported separately from operating system patching.
- The time from release to install is not shown, only current status.
- Branding and layout need manual work every month.
Insurers and clients' own customers also phrase their questions differently. One asks whether critical patches are applied within a set number of days, another asks for the share of devices fully patched, a third asks about third-party applications specifically. A single RMM export rarely answers any of them directly.
What manual patch reporting costs
| Problem | Cost to the MSP |
|---|---|
| Days spent formatting | Engineer time not spent fixing the exceptions |
| Exceptions not explained | Failed patches left for months |
| No time-to-patch figure | Cannot answer insurer or audit questions |
| Reports unread | Clients do not see the value of the service |
| Inconsistent reports | Each engineer produces a different version |
What patch timing a client must meet is set by their own policy or insurer. The report shows the facts against whatever target you and they agree.
The patch report we build
- A monthly pull of patch data per client from your RMM's API (NinjaOne, Datto RMM, N-able or similar), including operating system and third-party applications.
- A summary page in plain language: devices in scope, fully patched, pending, failed and offline, with a comparison to last month.
- Time from patch release to install for critical updates, shown against a target you and the client agree.
- An exceptions table listing each device not fully patched, with the reason from the RMM and a field for the engineer's action.
- Branded PDF output, emailed to the client contacts you choose, and saved to your documentation tool.
- An internal exceptions list across all clients for the service desk to work through, created a few days before reports go out.
Report week, reduced to exceptions
A few days before month end, the service desk receives the cross-client exceptions list: devices that failed a patch, laptops offline for weeks, a server where updates are deferred on purpose. Engineers fix what they can and note the reason for the rest. On the first of the month, every client receives a two-page report in your branding, with a clear summary and the exceptions explained.
When an insurer's questionnaire asks about patching within a certain period, the account manager has months of time-to-patch figures to attach. And the reports make visible the work your service desk does quietly every month.
The exceptions table is where the report earns trust. A laptop that has been offline for six weeks is listed with its user and last check-in, and the action says the client has been asked whether it is still in use. A server with feature updates deferred says why, and who agreed it. A client reading that can see the difference between a problem you are handling and one you have missed, and the engineer has to write the action only once, because it carries forward until the device is fixed.
Signs your patch reporting needs work
- An engineer spends days each month producing client reports.
- Your reports are RMM exports with a logo on top.
- Failed patches appear on reports month after month.
- You cannot show time-to-patch when an insurer asks.
- Clients have told you they do not read the reports.