Every MSP has a best technician. The one who handles onboarding without missing a step, who knows the exact sequence for troubleshooting VPN issues at that one difficult client, who remembers the compliance notification requirements during a security incident. Their process is consistent, thorough, and fast.
Now think about what happens when that technician is on vacation. Or when they leave. Or when you hire three new people and need them to handle the same tasks with the same quality. The process that lived in one person’s head becomes a gap in your service delivery — and you feel it in missed steps, inconsistent quality, and longer resolution times.
Runbooks solve this by encoding your best processes into structured workflows that anyone on the team can execute. Junto’s runbook system goes further: it makes those workflows AI-assisted, so the steps aren’t just documented — they’re actively guided, with context pulled from your tools and actions prepared for approval.
A runbook is a defined sequence of steps for handling a specific type of task. It’s more structured than a wiki article and more flexible than a rigid automation script. Think of it as a recipe that adapts to the ingredients at hand.
In Junto, a runbook has several components:
What causes the runbook to activate. This could be a ticket classification (password reset, new user onboarding), a specific alert type (Sophos malware detection), a scheduled event (monthly patch verification), or a manual trigger by a technician.
The ordered sequence of actions that make up the process. Each step can be:
Who “runs” the runbook — this is one of Junto’s most important design choices, and we’ll cover it in detail below.
Dynamic data that gets populated when the runbook runs. The client name, user details, device information, ticket context — all pulled automatically so the runbook adapts to each specific instance.
Building a runbook in Junto follows a deliberate process designed to capture institutional knowledge and validate it before it goes live.
Start with what your team already does. The best runbooks begin as documentation of an existing process — the steps your best technician follows for a password reset, or the onboarding sequence that an operations manager has refined over years. Junto’s drafting interface lets you define steps, specify which tools each step interacts with, and set decision logic.
You can also draft from scratch using Junto’s AI assistant. Describe the process — “create a runbook for onboarding a new user at a client with M365 and ITGlue documentation” — and the assistant generates a starting draft based on common MSP workflows. You then customize it for your specific operation.
Before a runbook goes live, it goes through review. Junto supports a review workflow where team leads or operations managers can examine the runbook, test it against sample scenarios, and suggest changes. This catches edge cases that the original author might have missed and ensures the process aligns with your MSP’s standards.
Run the runbook against real or simulated tickets in a test mode where all actions require manual approval regardless of the audience mode setting. This verifies that each step gathers the correct data, presents the right options, and produces the expected outputs — without risk of an untested runbook executing actions on real client systems.
Once reviewed and tested, the runbook is published and available for use. Published runbooks are version-controlled — every change creates a new version, and you can roll back to any previous version if a change introduces problems. You can also see who modified a runbook and when, maintaining an audit trail of your operational processes.
This is where Junto’s runbook system diverges from traditional automation. Every runbook has an audience mode that determines the balance between AI execution and human involvement.
The runbook runs end-to-end with AI handling the execution. Each step is completed automatically based on the defined logic and the data gathered from your tools. The technician receives a summary of what was done, with the ability to review and override any action after the fact.
This mode is appropriate for high-volume, low-risk processes — closing spam tickets, categorizing routine alerts, or generating standard reports. The AI handles the repetitive execution; the human reviews the output.
The runbook runs with AI handling information gathering and routine steps, but pauses at designated approval points for human review. This is the most common mode for production MSP workflows.
A hybrid onboarding runbook might automatically pull the client’s SOP, identify the correct license tier, and draft the account creation parameters — then pause for the technician to review and approve before the account is actually created. The next block of steps (group assignments, application provisioning) runs automatically, then pauses again at the communication step where a client notification needs to be reviewed before sending.
You control which steps require approval and which run automatically. The granularity is per-step, so you can be precise about where human judgment matters most.
The runbook serves as a guided checklist. Each step presents the technician with context and instructions, but no actions are taken automatically. The technician completes each step manually, marking them done as they go.
This mode is useful for processes where automation isn’t appropriate — complex escalations, sensitive client interactions, or tasks that require physical actions (hardware setup, on-site work). The runbook still adds value by pulling context, tracking progress, and ensuring no steps are skipped, even though the human does the actual work.
Not all runbooks are reactive. Some processes need to run on a schedule rather than in response to a ticket.
Monthly patch compliance audits, weekly license utilization reports, daily backup verification checks — these are processes that should happen on a cadence regardless of whether a ticket triggers them. Junto’s scheduler lets you set runbooks to execute on a defined schedule, with results surfaced as reports or tickets depending on what the runbook finds.
Beyond simple schedules and ticket classifications, runbooks can trigger on compound conditions. “Run this runbook when a ticket from a healthcare client is classified as a security incident” combines client attributes with ticket classification to activate the appropriate process. This lets you build industry-specific or client-specific workflows without creating separate triage rules for every scenario.
Runbooks aren’t static. As your MSP grows, adds clients, and evolves its processes, runbooks need to change. Junto’s version control system ensures that changes are tracked, attributable, and reversible.
When a process changes — a client updates their onboarding requirements, a new compliance regulation takes effect, a better troubleshooting sequence is discovered — the runbook is updated. The previous version is preserved. If the update introduces a problem, you roll back with one click.
This also serves as a record of institutional knowledge evolution. New team members can review runbook version history to understand not just what the current process is, but how and why it changed. “We used to do X, but switched to Y because of Z” is captured in the version history rather than lost when the person who made the change moves on.
In many MSPs, process documentation and operational execution are separate. SOPs live in ITGlue; actual work happens in ConnectWise. The two drift apart because updating documentation is always lower priority than working tickets.
Runbooks collapse this gap. The documentation is the execution. When a runbook changes, the process changes. There’s no separate document to update, no risk of an SOP describing a process that nobody actually follows anymore.
The MSPs that get the most value from runbooks aren’t the ones with the most runbooks — they’re the ones where creating and refining runbooks is part of how the team works.
When a technician solves a tricky ticket using a process that isn’t yet a runbook, they draft one. When a runbook works but could be improved, the team discusses the change and updates the version. When a new client onboards with unique requirements, the existing onboarding runbook gets a client-specific branch.
This culture turns your team’s experience into organizational capability. Knowledge doesn’t leave when people leave. Quality doesn’t depend on who’s working the queue. Your MSP’s best practices are encoded, versioned, and executable — not trapped in someone’s head or buried in a document that nobody reads during a live incident.
Ready to encode your best practices into AI-assisted runbooks? Start building with Junto and explore the runbook documentation for detailed setup guides.