Writing Tier-1 Runbooks for an MSP Service Desk

Managed service providers grow by keeping senior engineers on projects, escalations and client strategy. The obstacle is the volume of routine tickets: password resets, MFA re-enrollments, new-user setups, shared-mailbox access, printer issues. Tier-1 staff can resolve many of these — but only if the "how" is written down clearly enough to follow safely.

That's what runbooks are for. This guide explains how to write tier-1 runbooks that a remote helpdesk technician can follow, with security built in.

What a runbook is (and isn't)

A runbook is a step-by-step procedure for a specific, recurring request. It isn't general documentation or a knowledge-base article for end users. A good runbook tells a technician:

• When this procedure applies.
• What to verify before acting.
• The exact steps.
• What to do if something doesn't match.
• When to stop and escalate.

Start with your top ticket categories

Pull a report from your PSA — ConnectWise, Autotask, HaloPSA or similar — of ticket categories over a recent period. Sort by volume. The top categories are your first runbooks. Typical candidates:

1. Password reset.
2. MFA reset or re-enrollment.
3. Account lockout.
4. New-user onboarding.
5. User offboarding.
6. Shared mailbox or distribution-list access.
7. License assignment.
8. Printer and mapped-drive issues.
9. Software installation from an approved catalog.
10. VPN connection issues.

The runbook template

Use the same structure for every runbook:

Title: e.g., "Password reset — Microsoft 365 user."

Applies to: Which clients, environments and user types. Note exceptions (for example, clients with privileged-access policies or regulated environments).

Prerequisites: Required permissions, tools and client-specific notes.

Identity verification: How to confirm the requester is who they say they are. This is the most important section for password and MFA resets. Social engineering of help desks is a well-known attack technique, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has published advisories describing attackers impersonating employees to help desks. Define a verification method per client — for example, a callback to a number on file, a manager approval, or verification through an existing authenticated channel. Never accept verification based only on information the caller provides.

Steps: Numbered, specific, with screenshots where helpful.

Verification of success: How to confirm the fix worked.

Communication: What to tell the user, from a template.

Escalate if: Clear conditions that stop the procedure — the request doesn't match, verification fails, the user is a privileged account, the client has a special policy.

Ticket notes: What must be documented.

Example: MFA reset runbook (abbreviated)

Applies to: Standard users at clients on Microsoft 365. Not for global admins or accounts flagged as privileged — escalate those.

Identity verification:

1. Do not act on the inbound call or email alone.
2. Call the user back at the phone number in the client's documentation (not one provided in the request).
3. Confirm with the user's manager via a known contact method if required by the client's policy.

Steps:

1. Confirm the ticket includes the user's UPN.
2. In the admin portal, locate the user and confirm the account status.
3. Require re-registration of authentication methods per the client's standard.
4. Guide the user through re-enrollment.

Verify: User signs in successfully with MFA.

Escalate if: Verification fails; user is privileged; sign-in logs show suspicious activity; user reports they did not request the reset.

Notes: Record verification method used, time, actions taken.

Least privilege for tier-1

Runbooks pair with permissions. Give tier-1 staff only the roles their runbooks require — for example, a helpdesk administrator role rather than global admin. Log privileged actions. Review access quarterly and remove what's unused.

Client-specific exceptions

Some clients have contracts or regulatory obligations that restrict who can access their environment — for example, clients handling criminal justice information under the FBI's CJIS Security Policy, or contracts that prohibit offshore access. Mark these clients clearly in your PSA and documentation platform so tier-1 staff never pick up their tickets.

Keep runbooks alive

Runbooks rot as platforms change. Build in maintenance:

• Each runbook has an owner and a review date.
• Technicians flag steps that no longer match the interface.
• A tier-1 assistant can propose updates; a senior engineer approves them.

Documentation platforms such as IT Glue and Hudu make it easier to link runbooks to client configurations.

Measure the effect

Track:

• Tickets resolved at tier 1, by category.
• Escalations with complete information versus incomplete.
• Time to resolution for runbook categories.
• Reopened tickets.

Use these to decide which runbooks to write next.

Where a remote tier-1 technician fits

A dedicated, full-time tier-1 technician working your US hours can triage, categorize, resolve runbook tickets and escalate the rest with full details. They can also maintain documentation and onboarding checklists. ExecWing tier-1 helpdesk assistants work only in your tools, with least-privilege access and MFA.

Frequently asked questions

Will they have admin rights? Only the roles you assign. We recommend scoped helpdesk roles.

Can they handle privileged accounts? We recommend escalating privileged-account requests to senior staff.

Which PSAs do they use? ConnectWise, Autotask, HaloPSA and others.

What does it cost? Core $1,900, Growth $2,300, Executive $2,700 per month.

Onboarding a new tier-1 technician

Give a new technician read-only access to your PSA and documentation platform in week one and have them shadow live tickets. In week two, let them resolve a narrow set of runbook categories — often password resets and license assignments — with every ticket reviewed. Expand categories as quality holds. Track escalation quality from the start; complete escalations are the best early signal that a technician understands the environment.

Quick answers

How many runbooks should we start with? Five to ten covering your highest-volume categories. Expand based on ticket data.

Who should write them? A senior engineer drafts or approves; a tier-1 assistant can help document and keep them current.

Key takeaways

• Write runbooks for your highest-volume ticket categories first.
• Identity verification is the most important section of any reset runbook.
• Pair runbooks with least-privilege roles and logged actions.
• Mark clients with access restrictions clearly so tier-1 never picks up their tickets.
• Give every runbook an owner and a review date.

The bottom line

Tier-1 success depends on runbooks: clear scope, strong identity verification, numbered steps, success checks and explicit escalation conditions. Pair them with least-privilege access and regular review, and routine tickets stop reaching your senior engineers. See IT & MSPs and IT helpdesk tier-1.

A practical pilot is to write runbooks for your top five categories, assign a dedicated tier-1 technician to only those for the first month, and measure escalation quality and reopen rates before expanding scope.