Every MSP has processes that happen dozens of times a week, follow roughly the same steps, and still require a technician to do them manually from start to finish. These are your highest-ROI automation candidates — not because they’re complex, but because they’re frequent. Automating a task your team does five times a day returns more value than automating something that happens once a month, no matter how sophisticated the monthly task is.
Runbooks turn those repeatable processes into structured, AI-assisted workflows. Instead of a technician executing every step from memory (or from a doc they may or may not check), a runbook defines the steps, gathers the context, and walks the process through to completion — with the technician approving rather than performing.
Here are the five runbooks that deliver the fastest payback for most MSPs, and what each one looks like when automated.
Password resets are the single most common help desk request at most MSPs. They’re simple, well-defined, and take a disproportionate amount of time relative to their complexity — not because the reset itself is hard, but because of the verification and documentation steps around it.
That’s 7 steps for a task whose core action — resetting a password — takes about 10 seconds.
When a ticket is classified as a password reset, the runbook:
The technician reviews, approves the reset, and the runbook executes the remaining steps. A 5-minute process becomes a 30-second review. Across 10-15 password resets per day, that’s over an hour of technician time recovered — daily.
Onboarding is where documentation and execution collide. Every client has a slightly different onboarding process — different applications, different distribution groups, different license tiers, different hardware assignments. The documentation exists in ITGlue (hopefully), but finding it at the right moment is the bottleneck.
This process touches ConnectWise, ITGlue, M365, the RMM, and potentially the client’s phone system. A thorough onboarding takes 30-60 minutes, and an incomplete one creates follow-up tickets for weeks.
The onboarding runbook pulls the client’s SOP from ITGlue, then walks through each step with pre-filled information:
The technician approves each stage rather than executing each step manually. The runbook handles the cross-tool orchestration — creating the account in M365, updating ConnectWise configurations, and documenting the completed steps in ITGlue — while the technician verifies that each action is correct for this specific user.
“My computer is slow” is the second most common ticket category at most MSPs, and it’s also the most variable in terms of how technicians handle it. Without a structured process, troubleshooting depends entirely on who picks up the ticket and what they think to check first.
The order and thoroughness of these steps varies wildly by technician. One tech might catch a failing disk immediately; another might spend 30 minutes on software issues before checking hardware health.
The device troubleshooting runbook standardizes the diagnostic sequence:
The technician sees a structured diagnostic report rather than starting from a blank slate. Common fixes — clearing temp files, restarting services, applying pending patches — can be approved and executed directly from the runbook. Only genuinely complex issues require manual troubleshooting.
Offboarding is onboarding’s mirror image, and it’s arguably more important to get right. A missed step during offboarding — an account that stays active, a shared mailbox that doesn’t get reassigned, a license that keeps billing — creates security risks and unnecessary costs.
Miss step 7, and the client pays for a license they’re not using. Miss step 3, and a former employee still has access. Miss step 6, and critical files disappear after the account retention period expires.
The offboarding runbook treats each step as a checklist item with pre-populated data:
Each step requires technician approval before execution. The runbook tracks completed vs. remaining steps, ensuring nothing gets skipped even if the offboarding is interrupted. When complete, it generates a comprehensive offboarding record for compliance documentation.
Security incidents require speed, thoroughness, and documentation — three things that are hard to deliver under pressure without a structured process. When a Sophos alert fires, the technician needs to assess the threat, contain it, investigate the scope, and communicate with the client — all while documenting every action for potential compliance review.
Under the stress of an active security incident, steps get skipped. Client notification requirements get forgotten. Documentation happens after the fact — if it happens at all.
The security incident runbook activates when a security alert is detected:
The technician still makes every critical decision — isolate or not, notify now or investigate further, remediate or escalate. But the runbook ensures that the information needed for those decisions is available instantly, and that every required step in the response process is tracked.
If you’re new to runbook automation, start with password resets. They’re the highest volume, the most straightforward, and the fastest to prove ROI. Once your team sees that a runbook can handle a 5-minute task in 30 seconds without sacrificing quality, the appetite for automating the next process follows naturally.
The order after that depends on your MSP’s specific volume and pain points. If onboarding is eating hours every week, prioritize that. If your team struggles with consistent offboarding, that’s your #2.
The common thread across all five is that the technician’s time shifts from execution to oversight. They’re still in the loop. They still approve every action. But the manual steps that consume the bulk of the process time — the lookups, the cross-tool navigation, the documentation — are handled by the runbook.
Ready to build your first runbook? Start with Junto and see the runbook documentation for step-by-step setup.