Skip to content

One ticket, end to end

Three of the 508, end to end

Real ticket types from the operating model, rendered as the plans Claudia executes before a human needs to step in — a person's outage, a pattern only the watchdog finds, an alert the security class is held back on. Every step, its check, and where the checkpoint sits.

Request a demoRead the whitepaper

Scroll sideways to see the full illustration.

The resolution stage, performing the first of the records below.

One ticket, end to end

This is one of the 508.

A real ticket type from the operating model, and everything Claudia knows about it before a human needs to step in: what it looks like, what causes it, the steps and the check that proves each one worked, who it needs, and where the checkpoint sits.

Service desk · Incident · Email/M365

Cannot Send / Receive Email

User is completely cut off from email — every minute of silence costs the business.

Priority
Critical
Handled by
Help Desk Technician (L2)
SLA, hours
0.5 respond · 1 plan · 4 resolve
Hands-on effort
45 min
Reach
2 of 2 tool classes through a connector · remote
Self-service
Guided: the user can fix it with Claudia walking them through it.

The squad, on the ramp

  1. Concierge
  2. Triage
  3. Dispatch
  4. Resolution
  5. Watchdog

What it looks like

  • User reports they cannot send messages — mail sits in Outbox or bounces with an NDR.
  • Incoming mail stopped arriving; colleagues say their messages went through but the user sees nothing.
  • Outlook shows 'Disconnected' or 'Trying to connect…' persistently after restarting the client.
  • User receives a delivery failure notification referencing their own address or domain.
  • Mobile mail app stopped syncing while the browser and desktop client also fail — ruling out a single-client issue.

What causes it

  • Mailbox disabled, license removed, or account blocked in Microsoft 365 admin center or Entra — frequently triggered by a licensing audit or offboarding error.
  • MFA or Conditional Access policy change that broke legacy auth or a specific client profile.
  • Outbound spam hold placed by Microsoft's service on the mailbox or tenant connector after a compromised-account sending burst.
  • DNS or MX record misconfiguration — especially after a domain renewal, registrar migration, or SPF/DKIM update.
  • On-premises or third-party mail gateway (Mimecast, Proofpoint, etc.) misconfiguration or expired certificate blocking relay.

Resolution plan · 7 steps, each with its check

  1. 01

    Check M365 Service Health Dashboard (admin.microsoft.com → Health → Service health). Confirm whether Exchange Online shows an active incident or advisory.

    CheckNo active Exchange Online degradation shown — or, if one exists, record the incident ID and set user expectation. Do not proceed to tenant-level changes while a platform incident is open.

  2. 02

    Scope the blast radius: test send/receive for 2–3 neighboring users in the same department via OWA (outlook.office.com). Do NOT touch Outlook desktop yet.

    CheckOWA confirms whether the failure is isolated to one mailbox or affects a group. This gates the next step — single-user vs. multi-user paths diverge here.

  3. 03

    In M365 admin center, verify the affected user(s) have a valid Exchange-capable license assigned and the Exchange mailbox status is Active. In Entra admin center, review Conditional Access policies recently modified that target Exchange or the affected user's group.

    CheckLicense shows assigned with no error state. No CA policy change in the last 24–48 hrs that would block Exchange auth — or, if one exists, it is identified as the root cause and its scope confirmed.

  4. 04

    In Exchange admin center, inspect the mailbox: quota status, litigation hold configuration, and any transport rules or connectors modified recently. Flag any rule targeting the affected sender/recipient domain.

    CheckQuota is not at limit. No transport rule or connector misconfiguration explains the block. If a rule/connector is the cause, revert or correct it and confirm the change takes effect (EAC shows updated config; allow 2–5 min propagation).

  5. 05

    In the email security gateway admin (Defender for Office 365, Mimecast, Proofpoint, or equivalent), pull delivery logs for the affected mailbox and domain. Look for policy blocks, connector rejections, or quarantine hits in the delivery window.

    CheckDelivery logs show successful inbound/outbound events after remediation — or the blocking policy is identified, corrected, and a test message passes clean through the gateway log.

  6. 06

    If OWA now works but Outlook desktop still fails, run Microsoft Support and Recovery Assistant (SaRA) against the affected Outlook profile to identify auth corruption, profile errors, or cached credential conflicts.

    CheckSaRA scan completes without blocking findings — or identifies and remediates a specific profile/auth issue. Outlook desktop sends and receives a test message successfully.

  7. 07

    Document root cause, affected window (start → resolution time), and remediation action in the ticket. Note any CA policy, transport rule, connector, or gateway policy change made, including who/when the change originated.

    CheckTicket notes contain: root cause category, scope (user count), timeline, and the specific config change made. No related users remain impacted per step-2 scope check.

Closed when

  • Affected mailbox sends and receives a live test message via both OWA and Outlook desktop — not just one client.
  • At least 2 neighboring users in the same department confirmed unaffected (or, if they were affected, confirmed restored).
  • M365 Service Health shows no active Exchange Online incident, or any platform incident is fully resolved and the advisory is closed.
  • Root cause is documented in the ticket with the specific change (CA policy, transport rule, connector, gateway policy, license) and the originating event — sufficient for a post-incident review without re-investigation.

Skills it needs

  • Exchange Online Administration · Intermediate
  • Incident Management · Intermediate
  • M365 Tenant Administration · Intermediate
  • DNS Troubleshooting · Junior
  • Email Security (DMARC/DKIM/SPF + Gateway) · Junior
  • Service Level Management · Junior

Consoles and access

  • Identity verification / caller authorizationConfirm affected user identity and authorization to act on mailbox
  • Microsoft 365 admin centerUser Admin role (view/manage users, licenses, service health)
  • Exchange admin center (EAC)Exchange Administrator role (mailbox status, mail flow, message trace)
  • Microsoft Entra admin centerSecurity Reader or Global Reader (sign-in logs, Conditional Access review)

Where the human checkpoint sits

Claudia starts supervised on every MSP, and your team raises the level on evidence. For service desk work the model permits up to L2 Supervised.

  1. L0 Advisory
  2. L1 Copilot
  3. L2 Supervised
  4. L3 Guardrailed
  5. L4 Autonomous

The model's reasoning for that ceiling, verbatim: “Per-ticket scope on high-volume, mostly reversible work. L1 required a human to approve every single ticket classification, which is not defensible for triage. L3 only for read-only deflection.”

NOC · Problem · Pattern Analysis

Recurring WAN Circuit Degradation (Same Site)

A pattern of WAN slowdowns at one site that keeps reopening as incidents without a permanent fix.

Priority
High
Handled by
NOC Engineer
SLA, hours
1 respond · 2 plan · 8 resolve
Hands-on effort
180 min
Reach
5 of 5 tool classes through a connector · remote
Self-service
Needs an agent; not a self-service ticket.

The squad, on the ramp

  1. Concierge
  2. Triage
  3. Dispatch
  4. Resolution
  5. Watchdog

What it looks like

  • Users report internet slowdowns that resolve on their own but come back within hours or days.
  • VoIP call quality degrades predictably at certain times of day or under specific workloads.
  • Throughput tests show normal bandwidth at baseline but sharp drops during business hours.
  • The same site's WAN incident has been reopened or duplicated more than once this month.
  • Monitoring alerts fire on interface utilization or latency spikes at irregular but repeating intervals.

What causes it

  • ISP last-mile provisioning fault or chronic congestion on a shared segment the carrier hasn't remediated.
  • Failing or end-of-life CPE (modem, NTU, or customer-premises router) producing intermittent CRC errors or interface resets.
  • Physical layer degradation at or near the demarc — weathered outdoor cable, corroded connectors, or a marginal fiber splice.
  • QoS policy misconfiguration that allows a single application class (backup jobs, video conferencing, bulk transfer) to saturate the circuit during peak windows.
  • BGP or routing instability upstream causing path flapping that looks like local degradation on bandwidth graphs.

Resolution plan · 7 steps, each with its check

  1. 01

    Pull 30 days of WAN telemetry from the NMS/SNMP platform (SolarWinds, LibreNMS, PRTG, Auvik, etc.) for the affected site: interface error counters, utilization graphs, and latency trending. Export with timestamps.

    CheckRaw data in hand covering the full 30-day window including all known incident timestamps. Both error-counter series and utilization series are present before proceeding.

  2. 02

    Open the edge router or firewall admin (SonicWall NSM, FortiGate, Palo Alto Panorama, Cisco IOS CLI, Meraki Dashboard, pfSense, etc.) and pull WAN uplink interface statistics, error counters, and logs for the same 30-day window. Flag any CRC errors, input/output errors, or interface reset events.

    CheckError-counter verdict is definitive: either (a) CRC/reset events correlate with incident timestamps — physical or CPE fault pathway confirmed — or (b) counters are clean throughout — utilization/QoS pathway proceeds.

  3. 03

    Correlate degradation spike timestamps against scheduled business events: backup windows, video-conferencing blocks, large file sync jobs, patch distribution. Check scheduler in the RMM or backup admin (Datto, Veeam, Acronis, etc.) for job timing at the affected site.

    CheckEach spike is either explained by a scheduled event (document the event name and time delta) or ruled out — no recurring business-event pattern present. This determination is recorded in the Problem record.

  4. 04

    If error counters are clean and utilization is the primary signal, review QoS policy and traffic-shaping config on the WAN uplink in the firewall or edge router admin. Verify DSCP markings, bandwidth reservations, and queue drop statistics during peak windows.

    CheckQoS config either (a) shows misconfigured or absent prioritization rules — a change candidate is identified — or (b) is correctly configured — carrier circuit capacity is the limiting factor and ISP engagement is required.

  5. 05

    Compile an evidence package: packet-loss percentages, latency graphs, and error-counter exports with timestamps aligned to each incident window. Open a carrier NOC ticket (or ISP portal diagnostic case) and attach the package. State the recurrence pattern explicitly in the ticket body.

    CheckCarrier ticket is open with a case number recorded in the Problem record. Evidence package is attached or pasted inline. Carrier has acknowledged receipt — not just auto-acknowledged.

  6. 06

    If CPE hardware or physical demarc is suspected based on error-counter analysis, coordinate a Field Services dispatch for on-site inspection before continuing remote diagnosis. Document the dispatch ticket number in the Problem record and pause carrier escalation until inspection results are returned.

    CheckField Services ticket is created and linked to this Problem record, OR physical pathway is ruled out based on clean error counters and a confirmed carrier-side signal — dispatch decision is explicitly documented either way.

  7. 07

    Assemble the full root-cause chain in the Problem record: contributing factors, timeline, evidence summary, and either the permanent fix implemented or a formally accepted workaround (e.g., failover policy enabled, carrier SLA escalation path documented, QoS rule deployed). All linked incident tickets must reference this Problem record before closure.

    CheckProblem record contains: root cause statement, evidence references, fix or workaround description, and names of all linked incident tickets. No linked incident ticket is still open without a cross-reference.

Closed when

  • Site has completed one full 30-day recurrence window after the fix or workaround was implemented with no new WAN degradation incidents firing at that site.
  • Root cause is documented in the Problem record with supporting evidence — not just 'carrier issue' or 'circuit saturated' but a specific, traceable finding (e.g., carrier fiber splice degradation confirmed on span X, backup job rescheduled off business hours, QoS DSCP rule deployed).
  • A permanent fix is in place OR a formally accepted workaround is documented with an owner, a review date, and any required change ticket reference — an open-ended 'monitoring' state is not acceptable for closure.
  • All incident tickets that triggered this Problem record are closed and each contains a back-reference to this Problem record's ID in the resolution notes.

Skills it needs

  • Problem Management · Senior
  • Network Monitoring & Diagnostics · Senior
  • LAN/WAN Edge Routing · Senior
  • Network Fundamentals · Intermediate
  • Alert Correlation & Noise Reduction · Senior
  • Runbook Execution & Checklist Discipline · Intermediate
  • Customer De-escalation & Service Recovery · Intermediate

Consoles and access

  • Network Monitoring System / SNMP platform (SolarWinds, Auvik, PRTG, LibreNMS)Read-only analyst access — interface error counters, utilization graphs, latency trending, 30-day historical telemetry
  • Edge router / firewall admin console (FortiGate, SonicWall NSM, Meraki Dashboard, Cisco IOS CLI, Palo Alto Panorama, pfSense)Read-only or Network Admin — WAN uplink interface statistics, CRC error counters, event logs, BGP/routing table
  • ISP / carrier support portal or NOC lineAuthorized circuit contact — ability to open carrier trouble ticket, request circuit performance data, escalate to carrier engineering
  • PSA / RMM platform (ConnectWise, Autotask, HaloPSA + RMM)Technician — create and update Problem record, link related Incident child tickets, document root cause and workaround

Where the human checkpoint sits

Claudia starts supervised on every MSP, and your team raises the level on evidence. For endpoint / device ops work the model permits up to L3 Guardrailed.

  1. L0 Advisory
  2. L1 Copilot
  3. L2 Supervised
  4. L3 Guardrailed
  5. L4 Autonomous

The model's reasoning for that ceiling, verbatim: “Gated at the ACTION grain: the RMM script autonomy triad keeps approval-required and human-only scripts human-gated whatever the agent's level. Highest operational blast radius.”

Security · Incident · Endpoint Security

Ransomware Indicators

Endpoint telemetry has flagged ransomware-pattern behavior; every minute of delay widens blast radius.

Priority
Critical
Handled by
Cybersecurity Engineer
SLA, hours
0.5 respond · 1 plan · 4 resolve
Hands-on effort
240 min
Reach
6 of 6 tool classes through a connector · remote
Self-service
Needs an agent; not a self-service ticket.

The squad, on the ramp

  1. Concierge
  2. Triage
  3. Dispatch
  4. Resolution
  5. Watchdog

None of the service-desk 5: this board is the specialists' own.

What it looks like

  • User reports files suddenly have unfamiliar extensions or are inaccessible and showing a ransom note
  • EDR console (SentinelOne, CrowdStrike, Defender for Endpoint, etc.) fires a high-confidence ransomware behavioral alert
  • SIEM (Splunk, Microsoft Sentinel, Elastic SIEM, etc.) correlates rapid file-write events with vssadmin or wbadmin execution
  • Backup admin (Datto, Veeam, Acronis, etc.) reports snapshot jobs failing or shadow copies missing
  • Unusual outbound connections to unknown IPs spiking from a single host around the time of alert

What causes it

  • Phishing email with a malicious attachment or link that delivered the initial payload
  • Exposed RDP or VPN credential compromise used as the initial access vector
  • Unpatched vulnerability on a public-facing service exploited for initial foothold
  • Malicious macro or script execution via a LOLBin (living-off-the-land binary) that evaded signature detection
  • Lateral movement from a previously compromised but undetected host within the same environment

Resolution plan · 7 steps, each with its check

  1. 01

    Isolate the flagged host in the EDR console (SentinelOne, CrowdStrike, Defender for Endpoint, etc.) before any investigation begins. Do not defer isolation to triage the alert first — lateral spread starts immediately.

    CheckHost status shows 'Isolated' (or vendor equivalent) in the EDR console. EDR telemetry continues streaming from the isolated host, confirming the agent is still reporting.

  2. 02

    Trigger a forensic snapshot or live memory acquisition from the EDR console while the host is isolated and still live. Do not reimage, remediate, or run cleanup tooling before this artifact is confirmed in storage.

    CheckSnapshot or memory artifact is confirmed in EDR storage or exported to a secured location. Artifact filename and hash are recorded in the ticket.

  3. 03

    Query the SIEM (Splunk, Sentinel, Elastic SIEM, etc.) and EDR for lateral movement originating from the isolated host over the prior 24–72 hours. Search for matching IOCs — anomalous file-rename bursts, shadow-copy deletion (vssadmin / wmic), C2 beacon destinations — across all other managed endpoints, not just the initially flagged host.

    CheckLateral movement search is complete and the blast radius is documented in the ticket as either 'no additional hosts confirmed' or a named list of affected hosts. Scope is not declared contained until this search is finished.

  4. 04

    Open Windows Event Viewer on the affected host (if accessible) and review the Security log for logon events (4624/4625), Process Creation (4688), and PowerShell execution. In AD Users and Computers and Microsoft Entra admin center, check for new accounts or credential changes since the earliest confirmed IOC timestamp.

    CheckSuspicious logon, process-creation, or PowerShell events are identified or explicitly ruled out and noted in the ticket. Any unauthorized AD or Entra accounts or credential changes are flagged and actioned.

  5. 05

    Notify the client of containment action under the 1-hour plan SLA. Deliver a scope summary: hosts isolated, IOCs observed, initial assessment of encryption activity (present or not yet confirmed). Obtain explicit written go/no-go authorization for extended or expanded isolation.

    CheckClient acknowledgment is recorded in the ticket with a timestamp. Authorization to maintain or expand isolation is explicitly documented — not assumed.

  6. 06

    Verify backup integrity in the backup admin (Datto, Veeam, Acronis, etc.) — identify the last clean restore point for all affected hosts, confirmed earlier than the earliest IOC timestamp. Engage the BDR team and open a recovery ticket if full reimage-and-restore is the remediation path.

    CheckClean restore point is identified and its timestamp predates the earliest confirmed IOC. BDR team is notified or a formal recovery ticket is opened and linked. If no clean restore point exists, that finding is escalated to the client immediately.

  7. 07

    Remediate each affected host — reimage from known-clean image plus restore-point recovery, or validated threat removal if reimaging is not authorized. Document every action with precise timestamps. Produce and deliver the written incident summary: timeline, IOCs identified, containment and remediation actions, recovery status, and recommended follow-on hardening.

    CheckEDR console shows no active detections or behavioral alerts on all remediated hosts. Incident summary is attached to the ticket and delivery to the client is confirmed.

Closed when

  • EDR console shows no active threats, behavioral detections, or active isolations on any host in the environment — including all hosts identified during the blast-radius review, not only the initially flagged host.
  • SIEM and EDR lateral-movement telemetry confirms no unresolved pivot paths, active C2 beacons, or matching IOC signatures remaining across the environment.
  • Client has received and acknowledged the written incident summary covering: confirmed timeline, IOCs observed, containment actions taken, remediation outcome, and any recommended hardening steps.
  • No EDR re-alert matching the original IOC signatures (file-rename behavior, shadow-copy deletion, C2 beacon to the same destination) has fired across any managed endpoint within the post-remediation monitoring window.

Skills it needs

  • Malware / Ransomware Remediation · Expert
  • Endpoint Security / EDR · Senior
  • Incident Management · Senior
  • Major Incident Management · Intermediate
  • Security Monitoring / SIEM / MDR · Intermediate
  • Network Monitoring & Diagnostics · Intermediate
  • Customer De-escalation & Service Recovery · Intermediate
  • Executive Communications · Senior

Consoles and access

  • EDR console (SentinelOne / CrowdStrike / Defender for Endpoint)Incident Responder — Response Actions enabled (network isolation, forensic snapshot, threat-intel pull)
  • SIEM (Splunk / Azure Sentinel / Elastic SIEM)Security Analyst — threat-hunt query access (log search, correlation rule review, 72-hr host timeline)
  • Active Directory / Azure AD admin centerUser Admin (disable compromised accounts, force credential reset on affected identities)
  • Backup / DR portal (Datto BCDR / Veeam / Azure Backup)Read + snapshot integrity reviewer (verify last-clean recovery point before any restore decision)

Where the human checkpoint sits

Claudia starts supervised on every MSP, and your team raises the level on evidence. For security (soc) work the model permits up to L2 Supervised.

  1. L0 Advisory
  2. L1 Copilot
  3. L2 Supervised
  4. L3 Guardrailed
  5. L4 Autonomous

The model's reasoning for that ceiling, verbatim: “HELD DELIBERATELY at L2. A wrong containment action isolates a healthy production host. L3 only ever for detection and enrichment, never for containment.”

Records helpdesk-13, noc-298, soc-80 from The Agentic MSP Operating Model, version 4.361.0, licensed CC BY 4.0. The model's cost and benchmark figures are omitted here under its licence.

The list · 26 pages · PDF

The 10 ticket types that cost an MSP the most

The ten ticket types that cost your desk the most, with the lever for each.

Get the list

Want to take Claudia for a spin in your IT environment?

Claudia is invite-only for a limited supervised launch. Invited MSPs receive a 30-day free trial in an agreed test or pilot environment — no card, and no onboarding fee. Scope is confirmed before access.

Join the waitlistSchedule a demo