# IT Automation ROI: How to Quantify It and Build the Business Case _2026-08-07_ **Categories:** Automation, ITSM A practical framework for quantifying IT automation ROI: cost-per-ticket math, deflection economics, a copyable model, and how to win over your CFO. Most IT automation business cases fail for the same reason: they lead with capability and bury the math. A CFO does not care that an AI agent can reset passwords in Slack. They care that your service desk costs $2.4 million a year, that 38% of that spend goes to requests a machine can resolve, and that you can show the before-and-after on one page. The good news is that service management is one of the easiest domains in IT to build a defensible ROI case for. Ticket volumes are logged. Handle times are logged. Salaries are known. Unlike, say, a data platform investment, you are not projecting speculative value - you are reallocating a cost you already measure every month. This guide walks through the components of that case: cost-per-ticket math, the value of faster resolution, deflection economics, the soft benefits worth including, a simple model you can copy, and how to package it for a finance audience. ## Start with your fully loaded cost per ticket Cost per ticket is the anchor metric of every automation business case. The formula is simple: **Cost per ticket = total monthly service desk operating expense ÷ monthly ticket volume** The critical word is _total_. Benchmarking firms like MetricNet define operating expense to include salaries and benefits (typically the large majority of the total), plus technology, telecom, facilities, training, and management overhead - not just agent wages. Published benchmark data shows how wide the spread can be: one North American dataset put the average at $15.56 per ticket, with a low of $2.93 and a high of $46.69. Your number depends on labor market, ticket complexity, and how much work escalates past level 1. That last point matters most for automation math. Costs climb steeply with each escalation tier. A password reset handled by a level 1 agent is cheap; the same issue bounced to desktop support or an infrastructure engineer can cost several times more, because you are now paying senior-engineer rates for commodity work. This is why "shift left" has been service desk orthodoxy for a decade - and automation is shift left taken to its logical end: shift to zero human touch. Do this exercise before you build anything else: 1. Pull twelve months of ticket data and categorize by type (password resets, access requests, software provisioning, hardware, how-to questions, incidents). 2. Calculate cost per ticket overall, then estimate it by tier using loaded salaries. 3. Flag every category that is repetitive, well-documented, and low-risk. In most enterprises this covers 30-60% of volume. That flagged volume, multiplied by your cost per ticket, is your addressable spend. Everything else in the business case builds on it. ## Time-to-resolution is a business cost, not an IT metric Cost per ticket only counts what IT spends. It ignores the other side of every ticket: an employee who cannot work at full capacity while they wait. When a salesperson is locked out of the CRM for four hours, the cost is not the $15 ticket - it is four hours of a salesperson's loaded cost, plus whatever pipeline activity did not happen. You do not need precision here; you need a defensible, conservative estimate: **Downtime value = tickets per year × average productive hours lost per ticket × average loaded hourly cost of an employee** Be deliberately conservative. Assume only a fraction of wait time is truly unproductive - people work around problems. Even at 25-50% productivity loss during resolution windows, this line item routinely dwarfs the IT-side savings, because you are multiplying across the entire employee population rather than the IT team. Automation attacks this number differently than headcount math. An [AI-native service desk](/insights/what-is-ai-itsm) resolves common requests in seconds or minutes, around the clock, in the channel where the employee already works. Moving median resolution for automatable categories from hours to minutes is where the business - not just IT - feels the difference. Include it as a separate line so the CFO can discount it independently without weakening your hard-savings case. ## Deflection economics: resolution is not the same as deflection "Deflection" gets used loosely, and sloppy definitions produce inflated business cases that fall apart under scrutiny. Separate three outcomes: - **Deflected:** the employee found an answer (knowledge article, chatbot response) and never filed a ticket. Valuable, but hard to attribute cleanly - some of those people would have given up anyway. - **Auto-resolved:** a request was filed and completed end-to-end by software - the password was actually reset, the license actually provisioned, the group membership actually granted - with no human touch. This is fully attributable savings. - **Assisted:** automation drafted a response or gathered context, but a human closed the ticket. Count this as a handle-time reduction, not a resolved ticket. Legacy chatbots mostly deflect: they surface an article and hope. Agentic platforms resolve: they take the action. When Harmony resolves roughly 90% of routine employee requests natively in Slack or Teams, those are completed outcomes, not suggestions - which is exactly the distinction a skeptical finance partner will probe. Model each outcome at its own value: ```json { "_key": "it-automation-roi-business-case-b27", "_type": "table", "rows": [ { "_key": "it-automation-roi-business-case-b27-r0", "_type": "tableRow", "cells": [ "Outcome", "What to count", "Suggested value" ] }, { "_key": "it-automation-roi-business-case-b27-r1", "_type": "tableRow", "cells": [ "Auto-resolved ticket", "Full avoided cost", "100% of cost per ticket for that tier" ] }, { "_key": "it-automation-roi-business-case-b27-r2", "_type": "tableRow", "cells": [ "Deflected contact", "Partial avoided cost", "40-70% of cost per ticket (haircut for attribution)" ] }, { "_key": "it-automation-roi-business-case-b27-r3", "_type": "tableRow", "cells": [ "Assisted ticket", "Time saved", "Handle-time reduction × loaded agent rate" ] }, { "_key": "it-automation-roi-business-case-b27-r4", "_type": "tableRow", "cells": [ "Avoided escalation", "Tier cost difference", "L2/L3 cost minus L1 cost" ] } ] } ``` Two second-order effects belong in the narrative even if you keep them out of the spreadsheet. First, automation absorbs volume growth: as headcount and SaaS sprawl grow, ticket volume grows, and automation lets you hold IT headcount flat instead of hiring. Model "cost avoidance of the next two service desk hires" explicitly - CFOs respond to avoided requisitions more than to abstract efficiency. Second, automated resolutions are consistent: no skipped steps, full audit trails, fewer rework tickets. ## Soft benefits: real, but present them honestly Soft benefits belong in the business case - below the line, clearly labeled. Presenting them as hard savings is the fastest way to lose credibility. **Employee experience.** Waiting on IT is one of the most visible frictions in daily work. Instant resolution in Slack or Teams changes how employees perceive IT, which shows up in CSAT and internal NPS. If your company tracks employee experience scores, tie the initiative to that existing goal rather than inventing a dollar figure. **IT team morale and retention.** Nobody joined IT to reset passwords. Teams that automate the repetitive tier consistently report better retention and an easier time hiring, because the remaining work is engineering, not queue-grinding. Attrition has a real replacement cost - recruiting, ramp time, lost knowledge - so even a modest reduction is meaningful. Flag it qualitatively unless you have your own attrition data to model. **Capacity for project work.** Hours returned to the IT team do not vanish; they move to backlog items - security hardening, integrations, the [ESM rollout](/insights/what-is-enterprise-service-management) other departments keep asking about. Express this as "engineer-hours redirected to the project backlog," which finance can value against contractor rates if they choose. ## A simple ROI model you can copy Here is a one-page model. Replace the assumptions with your own data; the structure is what matters. **Assumptions (example mid-size enterprise):** - 4,000 employees, 40,000 tickets/year - Fully loaded cost per ticket: $18 (calculated from your own opex, not a benchmark) - Automatable share of volume, year one: 45% (18,000 tickets) - Realistic auto-resolution rate within that share: 85% (15,300 tickets) - Platform cost: use your actual quote - including implementation - Downtime recovery: 15,300 tickets × 1.5 hours saved × $55/hour loaded × 30% productivity haircut **Model:** ```json { "_key": "it-automation-roi-business-case-b44", "_type": "table", "rows": [ { "_key": "it-automation-roi-business-case-b44-r0", "_type": "tableRow", "cells": [ "Line", "Calculation", "Year 1" ] }, { "_key": "it-automation-roi-business-case-b44-r1", "_type": "tableRow", "cells": [ "Hard savings: auto-resolved tickets", "15,300 × $18", "$275,400" ] }, { "_key": "it-automation-roi-business-case-b44-r2", "_type": "tableRow", "cells": [ "Hard savings: avoided escalations", "your escalation delta × volume", "(your data)" ] }, { "_key": "it-automation-roi-business-case-b44-r3", "_type": "tableRow", "cells": [ "Cost avoidance: deferred hires", "2 FTE × loaded cost", "(your data)" ] }, { "_key": "it-automation-roi-business-case-b44-r4", "_type": "tableRow", "cells": [ "Below the line: downtime recovered", "formula above", "~$378,700" ] }, { "_key": "it-automation-roi-business-case-b44-r5", "_type": "tableRow", "cells": [ "Less: platform + implementation cost", "vendor quote", "(your quote)" ] }, { "_key": "it-automation-roi-business-case-b44-r6", "_type": "tableRow", "cells": [ "Net hard ROI", "(savings + avoidance − cost) ÷ cost", "-" ] } ] } ``` Three rules keep the model credible. State every assumption on the page, so finance can stress-test rather than distrust. Run a sensitivity table at 60/85/100% of your projected resolution rate - if the case only works at 100%, it is not a case. And time-phase it: automation ramps over one or two quarters as integrations and knowledge come online, so a hockey-stick month-one projection reads as naive. ## Presenting the case to a CFO A few principles separate the business cases that get funded from those that stall: **Lead with the cost you already incur.** Open with current-state spend: "We spend $720K a year processing tickets, and 45% of that volume is automatable." Anchor in a real number before introducing any projection. **Separate hard savings, cost avoidance, and soft value.** Let the hard number carry the approval and the soft benefits carry the enthusiasm. A case that clears the bar on auto-resolution savings alone, with everything else as upside, is nearly impossible to argue against. **Propose a measured pilot.** Offer a 90-day deployment against your top ten ticket categories with agreed exit metrics: auto-resolution rate, cost per ticket, median time to resolution, CSAT. Modern agentic platforms deploy in weeks, not the quarters legacy suites require, so a genuine pilot - not a paper exercise - is a realistic ask. (If you are comparing vendors, our guide to the [best IT automation tools of 2026](/insights/best-it-automation-tools-2026) covers evaluation criteria.) **Commit to reporting the same numbers afterward.** Nothing builds finance trust like a team that returns in a quarter with the identical dashboard, actuals against projections - including the misses. ## Frequently asked questions ### What is a good ROI benchmark for IT automation? There is no universal benchmark, because cost per ticket varies enormously - published North American data ranges from under $3 to over $46 per ticket. What matters is your own baseline: organizations with high ticket costs and high repetitive volume routinely see payback within the first year, because savings scale with every avoided ticket while platform costs are comparatively flat. ### How do I measure deflection without overclaiming? Distinguish deflected contacts (an answer surfaced, no ticket filed) from auto-resolved tickets (the action was completed by software). Count auto-resolutions at full value, apply a 30-60% haircut to deflection, and validate quarterly by checking whether total inbound volume per employee actually fell. ### Should soft benefits like employee experience go in the ROI model? Yes - as clearly labeled, below-the-line items. Quantify them with conservative assumptions (downtime recovery, redirected engineer-hours) but never let the case depend on them. The hard case should stand on auto-resolution savings and cost avoidance alone. ### How fast can automation ROI show up? It depends on deployment model. Legacy ITSM suites with bolt-on AI often take six to twelve months to configure before savings begin. AI-native platforms that connect to existing tools and work inside Slack or Teams typically show measurable auto-resolution within the first month, with ROI cases maturing over one to two quarters. ### What resolution rate should I assume in the model? Assume less than the vendor claims and build a sensitivity range. If a vendor demonstrates ~90% resolution of routine requests, model your blended case at 60-85% of addressable volume in year one and let overperformance be upside. ## See the math on your own tickets The fastest way to pressure-test this business case is with your actual ticket data. Harmony resolves roughly 90% of routine employee requests automatically, natively in Slack and Microsoft Teams - and a demo can map your top ticket categories to expected auto-resolution before you commit to anything. [Book a Harmony demo at harmony.io](https://harmony.io) and bring your ticket export.