--- title: "Measuring AI ROI: time saved isn't money saved" description: "Measure AI ROI in hours per deliverable from your own time tracking, review included. Time saved only turns into money once the team puts it to work." url: https://carl-wuerfel.de/en/notes/ai-roi-in-an-agency author: Carl-Uwe Würfel --- 1. [Home](https://carl-wuerfel.de/en) 2. [Notes](https://carl-wuerfel.de/en/notes) 3. AI infrastructure # Measuring AI ROI: time saved isn't money saved Measure AI ROI in hours per deliverable from your own time tracking, review included. Time saved only turns into money once the team puts it to work. [Carl-Uwe Würfel](https://carl-wuerfel.de/en/about)First published November 28, 2024 · Updated November 5, 2026 · 5 min read[Deutsche Fassung](https://carl-wuerfel.de/notizen/ki-roi-in-der-agentur) You measure [AI ROI](https://carl-wuerfel.de/en/glossary/roi-ki) in hours per deliverable, from your own time tracking and across the whole workflow, review included. The usual math looks different. A vendor quotes a flat percentage, and someone turns it into headcount savings. Both measure the wrong thing, because AI takes the busywork, not the people, and time saved isn't money saved yet. When we started moving SUMAX onto AI in 2023, we built the plan on the company's own time tracking. For me that moves every AI discussion from opinions to hours. ## Measure only the model and you measure the smallest part. The first thing people notice about an AI application is how fast the model works. For the business case that matters least. The model takes seconds. The work before and after often takes much longer: preparing inputs, checking results, fixing errors, looking after the system. Before anyone passes on an AI result, they check it. That review time is effort, and an ROI calculation without it is padded. Book review and corrections to the same deliverable as the actual work. ## Your baseline is already in your time tracking. A fair comparison needs the same task and the same quality bar before and after the launch. Almost every company already has the data for it. Time tracking shows how many hours a deliverable has taken so far, who worked on it and where rework came up. It also shows where unplanned routine work piles up and which task eats the most hours. That's where you start. The comparison only holds if the tracking categories stay the same for the whole period. The job mix has to match too, because a quarter full of easy jobs always looks more efficient. And you measure only once the new workflow has settled in, because a team is often slower than before in the first weeks after a launch. Measure before and after the same way, or skip the comparison altogether. ## Time saved isn't money saved. This is the most common mistake in the math. An hour an application saves only becomes money when something changes: more work with the same team, better client service, a cost that goes away. If the time goes unused, the company has the cost of the application and no return. > A hypothetical example: AI produces a report faster, but reviewing it takes more effort because the results need closer checking. Both effects belong in the math. If time is left over, the real question comes up. Can the team use it for more work or better client service? If not, the saving is a number on paper. No software answers that question. What freed-up time gets used for is a leadership decision, and it belongs before the launch. Decide what the team will do with the hours before you roll out the first application. Time saved isn't money saved. _Figure: Calculation: hours per deliverable before, from time tracking, minus hours per deliverable after, review and corrections included, gives the time saved. It only turns into money once the team puts it to work, for example on more work, better client service or because a cost goes away. Otherwise it stays a number on paper._ ## The math, with sample values. The examples in this table are hypothetical and given only as orders of magnitude. They only show the method and come from no real project. Step | Example, order of magnitude ---|--- 1\. Pick the deliverable | a recurring monthly client report 2\. Hours per deliverable before, from a long enough stretch of time tracking | most of a working day per report 3\. Hours per deliverable after, review and corrections included | about half of that 4\. Time saved: difference per deliverable times volume | with two dozen reports, a high double-digit number of hours a month 5\. Put a value on it: hours saved times internal hourly rate, minus the running cost of the application | a mid five-figure amount per year 6\. Payback: one-off investment divided by the monthly effect | with a low five-figure investment, a few months 7\. Reality check | What does the team do with the hours saved? Without an answer, step 5 exists only on paper. The cost side covers development or licenses, model usage billed by [tokens](https://carl-wuerfel.de/en/glossary/token), training for the team and ongoing upkeep. Calculate each application on its own, so a concrete amount sits next to the time saved. ## Every application needs a date to prove itself. Whatever you assumed at launch has to hold up in operation. So every AI application gets a fixed date for deciding whether to expand it, rework it or end it. On that date the hours per deliverable, the review effort and the costs go on the table. If an application is barely used or keeps needing fixes, it gets reworked or shut down. What has already been invested counts, but it doesn't decide on its own. Without a date, applications keep running because nobody stops them. Set the date on launch day. ## What time tracking can't see. Time tracking measures effort. It doesn't capture quality, client satisfaction or new possibilities. An application that makes a text much better but not faster looks worthless in the time entries. That calls for expert judgment, for example experienced people rating samples. I keep time, quality and new possibilities separate in the assessment, because they don't add up. Some things don't belong to any single application. The foundation everyone uses (users, permissions and access), plus security and the option to switch models later, serve every application at once. That needs a strategic call. So there's no typical ROI and no standard payback period for mid-sized companies. And the method is only as precise as the tracking. Track in round numbers and you get a round-number comparison. Assess quality and the foundation separately instead of forcing them into the hours. An AI ROI without your own time tracking is a claim. Take the deliverable that ties up the most hours today, pull its time entries for the last few months, and write down what the team should do with the time saved before you pick an application for it. How those data points turn into a plan with fixed decisions is on the [AI roadmap](https://carl-wuerfel.de/en/ai-roadmap) page. ## Further reading * [Leading an AI transformation in the middle market](https://carl-wuerfel.de/en/ai-mid-market) * [AI cost management: know the cost per call or fly blind](https://carl-wuerfel.de/en/notes/controlling-ai-api-costs) * [Shutting down an AI system: keeping it is a decision too](https://carl-wuerfel.de/en/notes/when-we-switch-off-an-ai-system) ## Contents 1. Measure only the model and you measure the smallest part. 2. Your baseline is already in your time tracking. 3. Time saved isn't money saved. 4. The math, with sample values. 5. Every application needs a date to prove itself. 6. What time tracking can't see. 7. Further reading **Carl-Uwe Würfel** COO & Chief AI Officer, SUMAX [Questions about this piece](https://carl-wuerfel.de/en/contact) ## Read next. * [**AI answers by language: the market in the query decides**](https://carl-wuerfel.de/en/notes/ai-visibility-by-language-market) * [**Shutting down an AI system: keeping it is a decision too**](https://carl-wuerfel.de/en/notes/when-we-switch-off-an-ai-system) * [**Running AI: catch failures, respond under control**](https://carl-wuerfel.de/en/notes/self-healing-ai-systems)