5 runbook templates every support team should have

Starting a knowledge base from zero is the hardest part. An empty KB feels hopeless — where do you even begin? This post solves the cold-start problem with five runbook templates that apply to almost every SaaS support team.

Use them as-is for your first week. Adapt them as you learn what your team actually handles. They're not meant to be final — they're meant to give you a running start.

Template 1: Customer can't log in

Login issues are the #1 inbound category for almost every SaaS. The runbook should cover the three most common root causes and decision-tree through them quickly.

Symptoms

• Customer says they can't log in
• Customer enters correct password and gets 'invalid credentials'
• Customer gets redirected back to login page
• Customer sees 2FA prompt unexpectedly
• Customer account is locked

Preconditions

Customer is using a supported browser. Customer has an active account (check account status before anything else).

Steps

1. Confirm email address. Check for typos. Confirm they're logging into the right environment (prod vs. staging, workspace-specific subdomain, etc.).
2. Check account status in the admin panel. If locked, unlock it. If disabled, escalate per policy.
3. Check for recent 2FA changes. If they reset their device, guide them through backup codes.
4. Clear cookies / incognito test. Rules out local session corruption.
5. If all above fails, generate a one-time magic link and verify they can use it.

Resolution

Customer logs in successfully. Document the actual root cause in the case (typo, expired password, 2FA reset, account lock) so we can track patterns.

Template 2: Data sync is stuck or delayed

If your product pulls data from external sources (calendars, CRMs, email), 'sync isn't working' is a recurring ticket. A runbook saves hours.

Symptoms

• Recent changes from source aren't appearing
• Sync status shows 'last synced 6 hours ago' or older
• Items appearing but with stale data
• Specific records missing while others sync fine

Steps

1. Check integration status page. Is the upstream provider having an incident?
2. Look up the customer's sync job logs. When was the last successful sync? What was the error on the latest attempt?
3. If OAuth token expired, walk them through reconnecting.
4. If rate-limited, confirm with engineering whether to raise the limit or wait.
5. For single-record issues, pull the record and check permissions on the upstream side.

Template 3: Permission denied / access errors

Symptoms

• Customer sees '403 Forbidden' or 'You don't have permission'
• Customer can see a resource but can't edit it
• Admin action fails with access error
• Customer says 'this used to work'

Steps

1. Identify the exact action that fails and the exact error.
2. Check the customer's role in the workspace. Members, admins, and owners have different permissions.
3. Check resource-level permissions — is this a shared item with explicit access controls?
4. Check for recent role changes. A teammate may have demoted them unintentionally.
5. If the customer is an owner and still sees this, escalate — it's likely a bug.

Template 4: Attachment or file upload fails

Symptoms

• Upload progress bar stalls
• Upload completes but file doesn't appear
• File appears but is corrupted or empty
• Error: 'File too large'
• Error: 'Unsupported file type'

Steps

1. Confirm file size and type. Cross-reference against published limits.
2. Ask for browser + network context. Slow upload = client-side issue; fast-then-fail = server-side.
3. Check for adblocker / VPN interference. These frequently block S3 pre-signed URLs.
4. Try a different file type as a control.
5. If the error is 'corrupted,' request the original and inspect via a support-side upload.

Template 5: Notifications aren't arriving

Symptoms

• Customer expected an email, text, or push notification and it didn't arrive
• Notifications work intermittently
• Customer sees in-app notifications but not external ones

Steps

1. Verify the customer's notification preferences — did they disable this type of notification?
2. For email: check spam folder, check our email provider's bounce logs, check the recipient's domain for greylisting.
3. For push: check device registration status. Push tokens expire silently.
4. Check the customer's contact preferences and the workspace's notification policy.
5. If the notification provider confirms delivery but the customer didn't receive it, it's on the customer's side (filters, rules, deliverability).

How to adapt these

Every runbook above is deliberately generic. To make them useful for your team, customize three things:

1. Symptoms: Rewrite the symptom list using the exact phrases your customers use in their tickets. This is the single highest-leverage edit — symptoms are the search keys.
2. Steps: Replace generic advice with product-specific steps. 'Check account status in the admin panel' becomes 'Open admin.yourcompany.com/users/{id} and check the status column.'
3. Escalation: Every runbook should have a bailout step. 'If all of the above fails, escalate to L2 with the case, the customer context, and what you've already tried.' Make the path explicit.

Do this once per template. You'll have a working knowledge base skeleton in an afternoon.