“Death of the ticket”: Atera says autonomous IT will reshape MSP economics

For decades, IT has revolved around the ticket. Tickets are how MSPs measure technician workloads, track SLAs, report performance, and, often, decide what to charge customers.

But Atera is questioning what happens to that model when AI starts resolving the work before it reaches the queue. The company took that argument to ServiceNow Knowledge in May, saying autonomous IT could push the ticket out of its central role in IT operations. Atera believes IT should spend less time managing tickets and queues. With autonomous IT, AI can find and fix some problems before a user reports them. That gives IT teams more time to focus on work that needs human judgment.

That raises some big questions for MSPs. How do you measure value when ticket volume starts falling? What happens to pricing when less work is tied to technician hours? And what does the technician’s role become when AI is handling more of the routine resolution work?

In this conversation with ChannelE2E, Tal Dagan, Chief Product Officer at Atera, breaks down how autonomous IT could change MSP operations, service models, and economics. He also gets into where endpoint-level automation works, where it still falls short, what controls MSPs need before letting AI act across customer environments, and how ITSM platforms may have to evolve as more work moves outside the traditional ticket queue.

ChannelE2E: Let's start with the ticket. IT has been built around tickets for decades. Why is that model starting to break down now? What changed?

Tal Dagan: IT has relied on tickets because they were the simplest way to make invisible work visible, and ticket volume was long treated as a proxy for IT workload and operational efficiency. That link has broken. The tickets still exist, but they no longer reflect the full scope of IT activity. A growing share of workplace issues never become tickets at all. Employees work around problems, resolve them informally, or avoid the support workflow when it feels too slow or cumbersome. In other cases, issues are resolved automatically in the background before a ticket is ever created.

Recent research from Atera shows that 50% of employees bypass IT ticketing systems entirely by using workarounds, and over a third choose not to submit a support ticket at all.

So ticket volume now reflects how people choose to engage with IT, not how effectively IT is operating. Two organizations can have similar ticket counts while having very different levels of automation, prevention, and self-resolution. That gap is only going to widen as resolution itself splits into two models. With Autonomous IT, tickets are still created and logged, but no technician needs to touch them. The ticket stops being a reliable measure of what IT is actually doing.

ChannelE2E: When you say IT is moving from ticket management to autonomous resolution, what does that look like in practice? What replaces the ticket when the issue is found and fixed before the user reports it?

Tal Dagan: With autonomous resolution, systems detect issues directly on the endpoint, in the service layer, or through usage patterns and resolve them automatically in the background without waiting for a user to submit a ticket. The system detects a problem, resolves it, and records what happened automatically.

That might be as simple as restarting a stalled service, correcting a misconfiguration, or restoring access before the user even realizes there was an interruption. The ticket doesn't get replaced by another workflow, but it stops being the primary unit of work.

Instead, what emerges is closer to an event-based record of resolution. Work is captured as system activity rather than user-reported incidents.

ITSM (Information Technology Service Management) moves into a governance and oversight layer. It becomes the framework that observes, validates, and audits automated actions across the environment instead of acting as the primary operating system for IT work.

ChannelE2E: For MSPs, ticket volume drives staffing, SLA design, technician utilization, and reporting. If Autonomous IT cuts ticket volume, what changes first? Is it the staffing model, the SLA structure, or how MSPs report value to clients?

Tal Dagan: The first shift is in measurement and reporting. As more resolution happens autonomously in the background, tickets stop reflecting actual operational activity. MSPs rely on measures like autonomous resolution rates, incident frequency, and overall environmental stability.

Once reporting changes, SLAs follow. They move away from purely ticket-based response metrics and toward broader service outcomes like reducing incident rates, containing issues faster before they impact users, and preventing repeat incidents across the environment.

Staffing models adjust last. For teams running Autonomous IT, technician roles shift from queue-based resolution to oversight of automated systems, exception handling, and service optimization.

ChannelE2E: Atera's Robin is being positioned as resolving 50% of Tier-1 and complex Tier-2 tickets within 90 days. If that changes the labor-hour model MSPs price against, what should they charge for now: outcomes, seats, devices, avoided tickets, or something else?

Tal Dagan: If Autonomous IT changes the link between labor hours and output, MSP pricing models don’t flip from one metric to another. Seats and devices will still matter as baseline capacity indicators, but they no longer explain value on their own. “Avoided tickets” are also incomplete. They capture friction reduction, not resolution performance.

The real shift is from effort-based pricing to resolution-based economics. As systems like Robin resolve a growing share of Tier-1 and Tier-2 issues autonomously, resolution becomes a measurable system output, independent of technician time.

MSPs move toward layered constructs: infrastructure scale, operational outcomes, and automation performance.  Differentiation comes from how much of the environment is resolved end-to-end without technician intervention.

ChannelE2E: ServiceNow is also pushing autonomous resolution. Atera's claim is that Robin can act at the endpoint, not just route work or summarize knowledge. Where does that endpoint-level execution really help MSPs and midmarket IT teams, and where are the limits?

Tal Dagan: Both platforms’ approaches sit in the same broader shift toward Autonomous IT, but they operate at different layers of the stack. In many enterprise models, autonomous resolution operates at the ITSM and workflow layer: classifying incidents, orchestrating remediation, and accelerating human or system-driven actions. This approach improves resolution speed, but execution happens elsewhere.

Robin’s model moves that execution layer to the endpoint itself. Instead of stopping at diagnosis or orchestration, it can perform remediation directly where the issue occurs, applying fixes, restarting services, or correcting configurations without routing work through a central queue.

That difference matters most in high-volume, redundant endpoint scenarios common in MSP and midmarket environments like password resets, service restarts, and routine Tier-1 and complex Tier-2 incidents. In these cases, executing at the endpoint eliminates entire categories of tickets before they escalate into a technician workflow. The issue may still be logged, but it doesn’t become a manual intervention for IT teams.

The limits of endpoint-level execution show up where problems are cross-system, policy-sensitive, or require coordination across multiple layers of infrastructure. In those cases, extra orchestration and human oversight are necessary, and endpoint-level automation becomes one part of the resolution path, alongside escalation to ITSM workflows, cross-system coordination, and technician-led intervention.

ChannelE2E: How does this shift play out differently for enterprise IT teams versus MSPs? Enterprise IT may focus on employee experience, but MSPs also have to think about packaging, profitability, and customer trust. What changes most for each side?

Tal Dagan: The shift plays out differently because enterprise IT and MSPs are optimizing for different outcomes, even when they’re adopting the same underlying capabilities.

For enterprise IT teams, the focus is employee experience, productivity, and operational risk. Autonomous resolution matters because it reduces friction in day-to-day work: issues are resolved faster, downtime is reduced, and employees spend less time interacting with support processes. The goal is to keep internal users productive with minimal interruption.

For MSPs, the impact is more structural and economic. They deliver services across multiple customers, each with different environments and expectations, which puts pressure on pricing models, service packaging, and trust. Value shifts toward consistently maintaining stable environments at scale. This means fewer recurring incidents, reduced repeat ticket volume, and fewer systemic issues resurfacing across customer environments, often with minimal visible technician involvement.

What changes most for both is the definition of IT work itself. Both enterprise IT and MSPs shift away from managing tickets to then managing the behavior, reliability, and performance of autonomous systems that resolve issues directly.

ChannelE2E: MSPs manage live client environments across many tenants. Before they let an AI agent take action on their behalf, what should they require around rollback, audit trails, and tenant-level isolation? Where does Atera meet that bar today, and where are you still building?

Tal Dagan: At a minimum, autonomous systems must provide visibility into what actions are being taken, enforce strict operational boundaries between customer environments, and allow technicians to intervene or override decisions in real time. As autonomy increases, governance has to be embedded into the operational layer itself rather than treated as a post-hoc compliance requirement.

We position these controls through configurable resolution policies that determine when Robin can act autonomously versus when issues are escalated, often based on defined confidence or risk thresholds. We also provide visibility into AI-driven actions and recurring issue patterns through our AI Center, allowing teams to monitor performance across environments.

From a security and data governance perspective, our customer data is kept within isolated environments and is not used to train shared models, reinforcing tenant separation and data privacy expectations.

Autonomous IT is still an evolving operational model. As agents gain the ability to execute actions directly, governance, transparency, and human oversight become not just compliance requirements, but core design constraints that determine where and how autonomy can safely scale.

ChannelE2E: Atera's AI Center shows AI actions, recurring issues, and knowledge gaps. Are MSPs turning that into a real service line yet -proactive operations, ticket reduction programs, something else? What does that look like in the field?

Tal Dagan: MSPs use data to move beyond individual tickets and identify systemic patterns such as repeated endpoint errors, misconfigurations, and recurring Tier-1 incidents. Tools like our AI Center make these patterns visible by surfacing AI-driven actions, recurring issues, and knowledge gaps across environments.

MSPs group repeat problems and address them through broader fixes, automation, or reusable remediation steps. This shifts work away from repetitive ticket resolution and toward reducing underlying causes at the source.

This shows up as fewer repeat incidents, more preventative work built into managed service offerings, and a shift in MSP value from resolving issues to reducing the conditions that create them.

ChannelE2E: If Autonomous IT starts doing more of the work directly, what does ITSM become? Is it still the system of record, or does it become the control layer for autonomous action, and what does that mean for ServiceNow's role?

Tal Dagan: ITSM won't disappear, but its role in the stack changes.

Traditional ITSM systems were designed as systems of record for coordinating human-driven work: tracking incidents, routing tasks, managing changes, and providing a structured workflow layer across IT operations. The assumption behind that model is that work is created, assigned, and resolved by people within the system.

As resolution moves closer to autonomous systems operating at the endpoint or infrastructure layer, ITSM shifts away from being the primary execution layer and becomes a governance and control layer for that automated work. ITSM platforms still matter for standardization, policy, and visibility. But they are no longer where most operational work happens.

For platforms like ServiceNow, the priority is no longer managing tickets and workflows. It is defining, governing, and integrating autonomous actions across enterprise systems. The shift is less about replacement and more about repositioning from executing and tracking work to governing systems that resolve work autonomously or support technicians in resolving it faster.