How AI drafting actually reduces mean-time-to-resolution — and where it doesn't help at all

Every vendor deck has a slide claiming AI cuts mean-time-to-resolution by some tidy percentage. We're not going to do that, and not out of false modesty — it's that MTTR isn't one measurable interval you can point a model at. It's a chain of distinct phases, each with its own bottleneck, and a drafting agent only ever touches a couple of links in that chain. Knowing which ones is more useful than any aggregate stat, because it tells you exactly when a drafting agent earns its keep and when it's decoration on a problem that was never about drafting speed.

The phases nobody breaks out

• Time to acknowledge — how long a ticket sits before a human looks at it at all
• Time to context — how long it takes to assemble what's already known: monitoring history, prior tickets on that asset, the client's environment
• Time to diagnosis — turning that context into a specific, testable explanation of what's actually wrong
• Time to action — applying the fix, which might mean a signed job, a phone call, or a part on order
• Time to close — confirming the problem is actually resolved and writing it up so the next person doesn't start from zero

A drafting agent's real leverage sits almost entirely in the second and third phases. Because Nexus keeps one tenant-isolated record for ticketing, monitoring, and history instead of syncing data between separate tools, an agent picking up a ticket already has the alert that generated it, the asset's recent job history, and prior tickets on that client sitting in the same record — no tab-switching, no waiting on a second system to load, nothing to reconcile. It can draft a diagnosis that references all of that before a technician has finished reading the ticket title. That's a real, mechanical time saving, and it's the part of the pipeline where an AI agent genuinely has an advantage over a human doing the same lookup by hand.

Where the clock doesn't move at all

None of that touches the phases that dominate MTTR on the tickets that actually take a while.

• A genuinely novel problem — nothing in history resembles it — still requires real investigation; a draft built from pattern-matching against known cases has nothing to match against
• Waiting on a client to call back, confirm a maintenance window, or answer a clarifying question doesn't compress no matter how fast the draft was produced
• A destructive or irreversible fix still needs human approval under the tenant's policy before it executes — the draft can be instant, the review step is deliberately not
• Confirming a ticket is actually done, not just that a symptom cleared, is a judgment call — we've written before about why that stays a human action even when the technical fix obviously worked

A drafting agent shortens the distance between 'the context exists somewhere' and 'a technician understands it.' It does nothing for the distance between 'nobody has seen this before' and 'somebody has now figured it out.'

What we can say honestly, from running this inside our own practice rather than a lab environment, is that drafting reliably removes a specific kind of dead time — the minutes spent reconstructing context a system already had. It does not touch the ticket where the real cost was investigation, coordination, or waiting. If a vendor gives you one MTTR number without telling you which phase it measured, that's the question worth asking back.