← Back to It Services Managed It Modules
It Services Managed It Guide
Making Your Business Run Without You
Master the core concepts of making your business run without you tailored specifically for the It Services Managed It industry.
💡 Core Concepts & Executive Briefing
Understanding the Franchise Rule
In Managed IT, the “Franchise Rule” means your company can deliver reliable service even when you are not online to triage tickets, approve work, or answer “quick questions.” Think of it like a franchise kitchen: the food still comes out consistent, on time, and to spec—because the process is documented and the team knows what to do.
In your world, consistency looks like this: a technician follows a known runbook, a client gets clear updates, and issues are resolved using the same steps every time—whether it’s Tuesday morning or Friday night.
The Importance of Systems
Managed IT is repeatable work. Most of your day is not new inventions—it’s the same categories of work: onboarding, patching, endpoint monitoring, email security, backup validation, network troubleshooting, and user support. Systems turn that repeatable work into a predictable machine.
A “system” in Managed IT is more than a checklist. It’s the full path from trigger to resolution:
- When a ticket should be created (and by whom)
- Which checks to run first
- What tools to use (RMM alerts, logs, dashboards)
- How to decide next steps
- How to document the fix and outcome
- What to communicate to the client, and how
If you’ve ever thought, “I know what to do, but I can’t explain it fast enough,” that’s your sign you need a system.
Building a Self-Sufficient Business
Start by identifying your bottleneck areas—the places where your team waits on you. In Managed IT, bottlenecks usually show up in a few common spots:
- Approvals: you are the only one who can greenlight exceptions (“Go ahead and rebuild it.”)
- Escalations: your team doesn’t know what to do after the first diagnosis step
- Customer communication: technicians pause because they’re unsure what you would say
- Technical decisions: only you can interpret certain alerts or logs
Once you find the bottleneck, build a playbook that others can run. A good IT playbook includes:
- Inputs: what data must be collected before you proceed (screenshots, RMM report, event logs)
- Decision points: “If X happens, do Y”
- Standard fixes: step-by-step runbook actions
- Edge cases: what you do when the standard path fails
- Sign-off rules: when the team can resolve, and when they must escalate
Real-World Scenario
Imagine a mid-market MSP that supports 120 endpoints across 20 clients. One Friday, an employee reports their VPN won’t connect. The helpdesk creates a ticket, but then the tech calls the owner because “the last time this happened, you fixed it a certain way.”
Here’s what the Franchise Rule changes:
- The playbook tells the tech exactly where to check first in the RMM (service status, tunnel settings, auth failures)
- It provides a decision tree for common causes (expired certs, credential lockout, firewall policy mismatch)
- It includes the exact email template the tech uses to update the client
- It defines escalation only for rare cases (for example: domain controller issues that require deeper investigation)
Now the ticket doesn’t turn into an owner interruption. The team resolves it using the documented process.
The Role of Documentation
In Managed IT, documentation is how you convert individual knowledge into company capacity.
Good documentation is:
- Short enough to use during a ticket
- Specific enough that a new tech can follow it without guessing
- Located where technicians already work (in your ticketing system or your internal knowledge base)
- Updated after real incidents (“We learned this on Tuesday, so the runbook changed”)
Your documentation should cover outcomes, not just steps. For example, it should state what “done” looks like (services restored, monitoring confirms stability, backup tested, user verified, client notified).
The Benefits of a Franchise Model
When the Franchise Rule is real in your MSP:
- Your team becomes faster because they stop waiting for you
- Quality improves because the same runbooks are used every time
- Risks drop because escalation rules are clear and consistent
- Growth becomes possible because adding clients doesn’t automatically add “owner time”
The goal isn’t to remove your expertise. It’s to make your expertise reusable—through systems.
Conclusion
The Franchise Rule in Managed IT is simple: build runbooks and decision trees so your service delivery works without your constant involvement. Document the steps, define escalation boundaries, and turn your best thinking into playbooks the team can run. That’s how your MSP becomes predictable, scalable, and calm.
⚠️ The Industry Trap
### The Hero Syndrome
In Managed IT, the Hero Syndrome looks like this: every time something breaks, your team immediately pings you—because you’re the only one who knows the “real fix.” Picture a Monday where two clients both have issues: one can’t log into email, and another’s computers stop receiving alerts. Your team escalates to you for every decision, even when the first-tier checks are already documented.
At first, it feels efficient—until you notice the pattern. Tickets pile up in your inbox, technicians delay their own judgment, and the team never practices solving. You become the single point of failure. Worst of all, customers start to experience slower response times, because the “fastest brain” is always stuck waiting for the owner to answer.
In Managed IT, the Hero Syndrome looks like this: every time something breaks, your team immediately pings you—because you’re the only one who knows the “real fix.” Picture a Monday where two clients both have issues: one can’t log into email, and another’s computers stop receiving alerts. Your team escalates to you for every decision, even when the first-tier checks are already documented.
At first, it feels efficient—until you notice the pattern. Tickets pile up in your inbox, technicians delay their own judgment, and the team never practices solving. You become the single point of failure. Worst of all, customers start to experience slower response times, because the “fastest brain” is always stuck waiting for the owner to answer.
📊 The Core KPI
Owner On-Call Interruptions This Week: Count of times the owner is directly contacted for a decision or action on an active ticket during the week. Target: 0–2 owner interruptions per week for a 4-week average. Formula: total owner direct pings (calls, texts, DMs, emergency ticket escalations) about ticket handling during the week.
🛑 The Bottleneck
### Execution Level
Most Managed IT owners get stuck as the bottleneck because they end up owning the “last mile” of every problem—especially the messy middle where a technician is unsure. If your team has to ask you every time an alert looks unfamiliar, you’ve accidentally built a business where speed depends on your attention.
A common scenario: your helpdesk can handle password resets and basic printer issues, but when it’s an endpoint that won’t patch, or a backup that’s “not quite failed,” the team waits. They don’t want to guess, so they stop. That means your SLA performance becomes tied to your availability, and the team’s technical confidence never grows.
The fix isn’t “work harder.” It’s to move those decisions into documented runbooks and clear escalation rules so tickets keep moving even when you’re offline.
Most Managed IT owners get stuck as the bottleneck because they end up owning the “last mile” of every problem—especially the messy middle where a technician is unsure. If your team has to ask you every time an alert looks unfamiliar, you’ve accidentally built a business where speed depends on your attention.
A common scenario: your helpdesk can handle password resets and basic printer issues, but when it’s an endpoint that won’t patch, or a backup that’s “not quite failed,” the team waits. They don’t want to guess, so they stop. That means your SLA performance becomes tied to your availability, and the team’s technical confidence never grows.
The fix isn’t “work harder.” It’s to move those decisions into documented runbooks and clear escalation rules so tickets keep moving even when you’re offline.
✅ Action Items
1. **Build a “No-Owner-Needed” runbook set for top ticket types (10 first)**
- Pick your 10 most common ticket categories (ex: VPN auth failure, patch stuck, backup missing, MFA issues, email quarantine).
- For each, write: first checks in the RMM, pass/fail decision points, and what you do when the standard fix doesn’t work.
2. **Create an escalation map that technicians can follow**
- Define Level 1, Level 2, and “Owner only” criteria (rare cases).
- Put it inside your ticket workflow (custom fields or tags like “Escalation Allowed: Yes/No”).
3. **Remove the owner from approvals using pre-set boundaries**
- Set dollar/time limits for technician actions (example: reinstall/cleanup steps up to a defined impact).
- Use templates for client messaging so technicians can communicate without asking you what to say.
4. **Run a 3-day “Owner Offline Drill” every month**
- Tell the team you will not answer owner pings except true emergencies.
- After each drill, review every ticket that contacted you and either: (a) improve the runbook, or (b) tighten the escalation rule.
5. **Update runbooks weekly based on what actually happened**
- During triage, add “what we learned” to the relevant KB article before the week ends.
- Measure progress by reducing owner interruptions (not by writing more documents).
- Pick your 10 most common ticket categories (ex: VPN auth failure, patch stuck, backup missing, MFA issues, email quarantine).
- For each, write: first checks in the RMM, pass/fail decision points, and what you do when the standard fix doesn’t work.
2. **Create an escalation map that technicians can follow**
- Define Level 1, Level 2, and “Owner only” criteria (rare cases).
- Put it inside your ticket workflow (custom fields or tags like “Escalation Allowed: Yes/No”).
3. **Remove the owner from approvals using pre-set boundaries**
- Set dollar/time limits for technician actions (example: reinstall/cleanup steps up to a defined impact).
- Use templates for client messaging so technicians can communicate without asking you what to say.
4. **Run a 3-day “Owner Offline Drill” every month**
- Tell the team you will not answer owner pings except true emergencies.
- After each drill, review every ticket that contacted you and either: (a) improve the runbook, or (b) tighten the escalation rule.
5. **Update runbooks weekly based on what actually happened**
- During triage, add “what we learned” to the relevant KB article before the week ends.
- Measure progress by reducing owner interruptions (not by writing more documents).
Ready to scale your It Services Managed It business?
Unlock the full Modern Marks Curriculum and join hundreds of other founders.