How do you measure IT ticket deflection ROI when there's no ticket?

You measure it at intake, not at close. When an autonomous IT engine resolves a request before a ticket is opened, your ITSM never records the win — so the ROI has to come from a source upstream of the ticket system. The three usable sources are the resolver's own activity log (every action it took, timestamped, under policy), the underlying Microsoft 365 audit logs (the change actually happening), and the baseline queue volume from the months before deployment. ROI is the delta between that baseline and the queue that still arrives, multiplied by your loaded cost per ticket.

Why doesn't my ITSM record deflected tickets?

Because an ITSM is a system of record for work that becomes a ticket, and deflected work never becomes one. If Dex resets a locked account inside Microsoft Teams and the user goes back to work, there is no ticket to count, no queue entry to age, and no close code to report. The ITSM is architecturally blind to work that resolves before it enters the queue — which is exactly the work you're trying to quantify. That's the reporting gap: your biggest win is the one your dashboard can't see.

How do I set a deflection baseline before deploying agentic IT?

Pull 3 to 6 months of ticket history from your ITSM before you deploy, and categorize it: volume by request type, tier mix, and loaded cost per ticket. That frozen baseline is the only 'before' number you'll get, because once Dex is live the routine categories stop generating tickets and the historical trend line breaks. Capture it first. After deployment, the deflection count is baseline volume by category minus the residual queue that still arrives in each category.

Does the audit trail count as proof of deflection for a CFO or auditor?

Yes, and it's stronger proof than a ticket close code. Dex writes an audit entry for every action to both the native Microsoft 365 logs and its own Activity Log — what it investigated, which policy authorized the action, and what it executed. That record is independently verifiable in your own tenant logs, which a ticket status is not. For an ROI review or a compliance audit, the activity log is the primary evidence that the deflected work was real work, done correctly.

The Ticket That Never Existed: How to Measure Deflection You Can't See in Your ITSM

Q: What's the difference between deflection and end-to-end resolution?

Deflection often just means a request was kept out of the human queue — a chatbot answered, a user was sent to a knowledge-base article, a ticket was auto-closed. End-to-end resolution means the request was actually completed against the backend system, under policy, with an audit trail. Dex's number is 90%+ end-to-end resolution across the L1-through-L3 surface, not containment. When you build the ROI case, count only resolutions you can trace to a real action in the Microsoft 365 logs.

The single most valuable thing an autonomous IT engine does is also the hardest thing to put on a slide: it resolves a request so early that no ticket is ever created, which means your ITSM — the tool you'd normally use to prove the win — never records it. This is the reporting gap every IT leader hits the moment deflection starts working. This post is about closing it: why deflected work is invisible to a ticket system by design, where the real evidence actually lives, and how to build an IT ticket deflection ROI case out of tickets that never existed. If you're the person who has to defend this number to a CFO, this is the methodology.

The measurement paradox at the heart of deflection

The better your deflection, the less your reporting shows.

That sounds like a bug. It's the direct consequence of how ITSMs work. An ITSM is a system of record for work that becomes a ticket — it counts opens, ages queues, tracks SLAs, and reports close codes. Every metric it produces is downstream of a ticket existing. So when Dex resolves a request before the ticket — a locked account cleared inside Microsoft Teams, an access grant executed and logged, a device policy fixed in the time it takes to describe it — there is nothing for the ITSM to record. No open. No queue entry. No close code. The user goes back to work, and the win evaporates from the one dashboard everyone trusts.

The result is a paradox that stops ROI conversations cold: the requests that used to cost you the most are now the ones you have the least data on. Your ticket volume drops, which reads on the dashboard like less work happening, when what actually happened is the same work, resolved before it could be counted. If you measure deflection with the ITSM, you will systematically undercount your biggest wins.

Before and after funnel comparing a traditional ITSM where every request becomes a ticket with Dex resolving requests before a ticket is ever created

An ITSM measures the queue. Deflection empties the queue before it forms.

This isn't a limitation to fix — it's the correct division of labor. The ITSM stays authoritative for the work that genuinely needs tracking, routing, and remembering: escalations, change approvals, compliance reporting, and the historical record. It's a system of record, and a system of record can only record what enters it. Asking it to report on tickets that never existed is like asking a turnstile to count the people who took the stairs.

So the instinct to "just pull the deflection report from ServiceNow or SysAid" fails at the first step. The number isn't hiding in the ITSM. It was never routed there. To measure deflection you have to move upstream of the ticket system entirely — to the layer where the work actually happened.

Where the evidence actually lives

Deflected work leaves three traces. None of them are in your ITSM, and all three are independently verifiable.

The resolver's activity log

Dex writes an audit entry for every action it takes — what it investigated, which policy authorized it, and what it executed, each one timestamped and attributed. This is the direct count of deflected work: every closed action that never became a ticket is one line in the Activity Log. It's the closest thing to a "deflection report" that exists, and unlike a ticket close code, it records the reasoning chain, not just the outcome. The audit trail is the product precisely because it's the only place the invisible work becomes visible.

The Microsoft 365 audit logs

Every action Dex takes is a real change in your tenant — a password reset in Entra ID, a group membership change, a license assignment, a mailbox permission. Those changes are logged natively in Microsoft 365, in your own logs, outside of any Dex system. This is your corroborating source: the activity log says Dex did the work; the M365 logs prove the work happened. For a skeptical CFO or an auditor, the fact that the evidence lives in your own tenant — not a vendor dashboard — is what makes the number defensible.

The frozen baseline

The last trace is the one you have to capture before deployment, because it disappears afterward. Your pre-deployment ticket history — volume by request type, tier mix, loaded cost per ticket — is the "before" picture. Once Dex is live, the routine categories stop generating tickets and the historical trend breaks, so there's no reconstructing it later. Freeze 3 to 6 months of ticket history the week before you deploy. That baseline is the denominator for every deflection number you'll ever report.

The deflection formula that survives a CFO review

Deflection ROI is a subtraction problem, not a counting problem.

You can't count tickets that don't exist, but you can count the ones that still arrive and subtract from a known baseline. For each request category:

Deflected volume  =  baseline volume (category)  −  residual queue (category)

Deflection ROI    =  deflected volume  ×  loaded cost per ticket

The loaded cost is the number most orgs get wrong, and it's why the ROI case usually understates itself. The invoice cost of a Tier 1 ticket ($20–$30 per the most-cited HDI benchmarks) is a fraction of the real cost once you add user wait time, engineer interruption, and escalation overhead — typically 3 to 5x the invoice. We worked that number all the way through in the IT helpdesk math, and it's the multiplier that turns a modest-looking deflection count into a real financial case. Use the loaded number, not the invoice number, or you'll leave most of the ROI on the table.

Two guardrails keep this honest. First, count residual queue by category, not in aggregate — new ticket types will appear and you don't want them contaminating the deflection math for password resets. Second, reconcile the deflected volume against the activity log. If your subtraction says 1,100 password tickets were deflected and the activity log shows 1,100 password resets executed, the number is real. If they diverge, trust the log.

Deflection is not containment — measure the right thing

The reason vendor deflection numbers are so often useless is that "deflection" quietly gets defined as "kept out of the human queue," which is trivially easy to inflate. A chatbot that replies "I'm not sure, try the knowledge base" has deflected the ticket and resolved nothing. If you build your ROI case on containment, you're multiplying loaded cost by requests that were never actually handled — and the moment someone spot-checks it, the whole number collapses.

The only figure worth putting in front of a CFO is end-to-end resolution: the request was completed against the backend system, under policy, with a traceable action. Dex's number is 90%+ end-to-end resolution across the L1-through-L3 surface — not just password and access work, but the deeper Tier 2 and Tier 3 troubleshooting, configuration, and engineering-adjacent tasks that used to require a senior technician. That distinction is what makes the deflection auditable: every unit is backed by a real action in the M365 logs, so the ROI number and the evidence are the same number. When you evaluate any tool, ask for end-to-end resolution and ask to see it in the tenant logs.

For MSPs, the invisible number is the P&L

The stakes on this measurement rise sharply for managed service providers, because for an MSP the deflected ticket isn't just a cost saved — it's a technician-hour freed to serve the next client. The MSP tenant math shows what happens when one engineer runs 40 Microsoft 365 tenants instead of five: the entire margin gain comes from work that no longer generates a ticket in any tenant. If an MSP measures only the residual queue, it will completely miss the source of its own margin expansion. The deflection number is the business case, and it lives entirely in the activity logs across every tenant — which is exactly why per-tenant audit trails matter as much as the resolution itself. This is measured, and governed, in Dex Pro, where each tenant carries its own policy set and its own auditable record.

What to do Monday morning

Three moves turn invisible deflection into a number you can defend:

Freeze your baseline before you deploy. Export 3 to 6 months of ticket history categorized by request type and loaded cost. This is the only "before" you'll ever get — capture it while the tickets still exist.
Report from the activity log, not the ITSM. Make the resolver's audit trail, corroborated by your own Microsoft 365 logs, the primary source for the deflection count. The ITSM stays the system of record for what escalates; it is not your deflection meter.
Insist on end-to-end resolution, tenant-verifiable. Count only work you can trace to a real action in your logs. A deflection number you can point an auditor at is worth more than a bigger number you can't.

The ticket that never existed is the whole point of agentic IT — and the reason it's easy to undervalue. When IT gets fast enough, it gets quiet, and quiet doesn't show up on a queue report. The work to do is to move your measurement upstream of the ticket, to the layer where the work actually happens. Do that, and the most invisible thing your IT function does becomes the most defensible number on your budget.