AIReturn

AI ROI by team

AI ROI by Team: Where AI Pays Off — and Where It Burns

AI ROI has to be measured per team — output isn't comparable across functions. Here's the by-function signal model and Cost × Rework matrix CFOs use.

Rodrigo Paredes BassiPublished 15 min read

TL;DR

  • AI ROI can only be measured per team. A support team's output isn't comparable to an engineering team's, so there is no single company-wide AI ROI number — only a set of per-team returns, each measured against that team's own pre-AI baseline.
  • The pattern differs sharply by function: 66% of organizations report efficiency gains from AI while only 20% report revenue gains (Deloitte, 2026). Efficiency shows up almost everywhere; return shows up in specific teams.
  • What separates the teams where AI pays off from the teams where it burns is rework — and rework has a different signal per function: reverts and extra PR rounds in engineering, reopens and reassignments in support, stage regression in sales, requirements/spec volatility in product, redo cycles in marketing, exception handling in operations.
  • The decision artifact is a Cost × Rework matrix built one team at a time, yielding a per-team verdict — scale, keep, fix, or cut.
  • Only 28% of AI use cases fully meet their ROI expectations (Gartner, Apr 2026). Averaging that across the company hides which teams earn their spend and which quietly lose it.

Which teams actually get ROI from AI?

The ones whose AI output ships without being redone. AI ROI is not one number for the company — it is a return computed per team, as the useful output that team produces per dollar of AI spend, net of rework, measured against its own pre-AI baseline. Efficiency appears in almost every function; genuine return concentrates in the teams where the AI's output is accepted, not corrected. That distinction is the whole point of measuring by team. Deloitte's 2026 enterprise survey found 66% of organizations reporting productivity or efficiency gains from AI, but only 20% reporting revenue gains (Deloitte, State of AI in the Enterprise 2026). A company-wide "AI ROI" figure blends those two very different realities into a number that tells a CFO nothing about where to fund, remediate, or cut. The signal lives one level down — in the team.

Why AI ROI is not comparable across functions

Because the output of each function is denominated in a different unit. Engineering ships merged changes; support closes cases; sales advances deals; marketing ships assets; operations clears exceptions. You cannot put "pull requests" and "resolved tickets" on the same axis and call the taller bar "more ROI." Cross-team comparison is a category error. This is the mistake behind most AI dashboards: they roll individual or team activity up into one company-wide figure — seats, tokens, an aggregate "hours saved" — and lose the only comparison that means anything. The valid comparison is always this team, now, versus this team, before AI. We develop the reasoning in full in why the honest benchmark is a baseline, not a cross-team average; the short version is that a benchmark you borrow from another team, or another company, measures the wrong thing. Two consequences follow. First, there is no universal "good AI ROI" number to hit — the target is improvement over your own baseline, function by function. Second, the measurement method has to be built per function, because the way you detect useful output — and the way you detect rework — is specific to how each team works.

Definitions: the terms this framework runs on

Before the by-function view, the vocabulary. These terms carry the rest of the post. Per-team baseline is a function's own output-net-of-rework measured before AI, used as the only valid comparison point for that function's AI ROI. It is never a cross-team or cross-company average — output isn't comparable across functions, so the baseline is always the team versus its own history. Output-per-dollar-net-of-rework — in plain language, cost per good outcome — is the core ROI unit: the useful output a team ships per dollar of AI spend, after subtracting the cost of redoing flawed AI work. Cost is the denominator; the numerator is quality-gated output — a merged change that survives without a revert, a verified resolution, qualified or closed-won pipeline, a spec-validated shipped decision — because raw counts inflate under AI. The full unit is (business outcome delivered − rework cost) ÷ (AI cost + human cost to get it right), per team, continuously, across every AI vendor. Cost × Rework matrix is a 2×2 that plots each team on AI cost (high/low) against AI rework (high/low), producing a per-team verdict — scale, keep, fix, or cut. It is the decision artifact a CFO uses to allocate the AI budget team by team. Per-team AI budget is the practice of funding AI spend team by team based on proven output-net-of-rework, rather than one blanket "AI budget" no one can defend at the board. AI rework is the redo cost incurred when AI output looks done but isn't — the human time to correct, re-instruct, or re-do work an AI tool produced. Its signal differs by function, which is why it has to be defined per team.

The per-function signal model: same equation, different tells

Every function runs the same ROI equation — output per dollar, net of rework, versus its own baseline. What changes from team to team is the signal: the observable event that tells you AI output was accepted, and the observable event that tells you it had to be redone. The equation is constant:

AI ROI = (business outcome delivered − rework cost) ÷ (AI cost + human cost to get it right) — measured per team, continuously, against that team's own baseline. The two things you have to read off each function's own workflow are its outcome work item — the unit of useful output that team ships — and its rework signals — the events in that team's tools that mean the AI's work bounced back for correction. Get those two right and the equation is fillable for any function. Get them wrong and you are back to counting activity.

AI ROI by function: the outcome and the rework signals

Here is the by-function overview — the outcome work item each team ships, and the rework signals that reveal when AI output had to be redone rather than accepted.

TeamOutcome work itemExample rework signals
EngineeringMerged change / shipped featureChurn and reverts · repeated PR review rounds · reopened bugs
Customer supportResolved caseTicket reopens · reassignments · escalations after an AI-drafted reply
SalesAdvanced / closed dealStage regression · lengthening time-in-stage · reworked proposals
Product & designShipped initiative / accepted designRequirements/spec volatility (specs changed, reopened, or re-cut after work started) · repeated review loops · items moving back through states as a hygiene sub-signal
MarketingPublished asset / campaignEdit and redo cycles · revision rounds before an asset ships
OperationsCleared exception / completed handoffExtra handoffs · exception rates · manual reprocessing
Read the table as a set of instructions, not a leaderboard. Nothing in it compares engineering to sales; each row is self-contained, because each function's numbers only make sense against that function's own baseline. The rework column is where AI ROI is won or lost: two teams can show identical AI adoption and identical AI cost, and the one with rising reopens, reverts, or stage regression is the one quietly losing money.
A caution that this brand's register depends on: these signals are proxies, and their maturity varies. In engineering, rework is concrete and well-instrumented — reverts, churn, extra review rounds, reopened bugs are unambiguous events. In deals, product initiatives, and support cases, the proxy for rework — and the harder problem of separating AI-caused rework from the baseline rework a team always had — is still being defined. Anyone claiming precise, universally validated rework attribution across every function in 2026 is overselling. The model is strongest in engineering today and expands function by function as the definitions mature.

Where AI pays off — and where it burns — by team

The 66%-efficiency / 20%-revenue split from Deloitte is not evenly distributed. It clusters by function. Here is the honest, directional read of where the return tends to show up and where the rework tends to eat it — always subject to each team's own baseline, never a promise for your specific org. Engineering is where the model is most built out and where both the gains and the rework are most measurable. AI-assisted coding can raise individual output, but individual gains don't automatically roll up to team-level return — more pull requests can mean more review rounds and more reverts. The teams that pay off are the ones whose merged-change rate rises without a matching rise in churn. See AI ROI in engineering. Customer support is a high-volume, high-signal function: AI-drafted replies are cheap to generate and easy to over-trust. The return is real when first-contact resolution holds; it burns when reopens, reassignments, and escalations climb because an AI reply looked complete but wasn't. See AI ROI in customer support. Sales is where rework hides inside the pipeline. An AI-generated proposal or follow-up that misses the mark shows up not as a "redo" but as a deal sliding backward a stage or sitting longer in one — stage regression and lengthening time-in-stage are the tells. See AI ROI in sales. Product and design pays off when initiatives move forward cleanly and burns when requirements and specs keep changing, reopening, or getting re-cut after work has started. That requirements/spec volatility — not merely a ticket sliding backward on the board — is the product-team equivalent of a revert; items moving back through statuses are a useful hygiene sub-signal. See AI ROI in product and design. Marketing produces the most visible "workslop" risk: polished-looking assets that need real editing before they ship. The return is in published assets; the rework is in edit-and-redo cycles counted before publication. See AI ROI in marketing. Operations measures return in cleared exceptions and clean handoffs. AI that adds handoffs, raises exception rates, or forces manual reprocessing is burning spend even if it feels faster. See AI ROI in operations. The pattern across all six: efficiency is common, but return concentrates in the teams whose rework signals stay flat while output rises. That is why the company-wide average misleads — it lets a paying-off engineering team subsidize a burning support workflow, and the CFO never sees either.

The mistake: one company-wide AI ROI number

Most AI reporting commits the same error — it produces a single, blended figure and calls it the return. Three specific failures follow from that.

  • It averages away the signal. A +30% team and a −20% team net to a comfortable, meaningless +5%. The whole value of measuring by team is to stop averaging.
  • It compares the incomparable. Any number that ranks functions against each other — "sales got more AI ROI than support" — is built on non-comparable units. It is noise dressed as insight.
  • It counts activity, not output net of rework. Seats, tokens, and self-reported hours saved are inputs. None of them subtracts the rework, so none of them is a return. 78% of finance executives can't fully tie AI spend to outcomes (CloudZero, 2026) — largely because the numbers they're handed are company-wide activity, not per-team output net of rework. The fix is not a better average. It is a per-team verdict.

The decision: the Cost × Rework matrix, one team at a time

Metrics don't allocate budget; a decision artifact does. Plot each team on two axes — AI cost (high/low) and AI rework (high/low) — and each quadrant yields a verdict for that team. You build one matrix per function, not one for the company.

Low reworkHigh rework
Low costKeep — quiet and efficient. Leave it running.Fix — cheap but sloppy. The output needs work before it's worth scaling.
High costScale — expensive but clean. This is where return compounds; fund it.Cut — expensive and getting redone. The clearest case for pulling spend.
The rework axis is read from each function's own signals — reverts for engineering, reopens for support, stage regression for sales, requirements/spec volatility for product, redo cycles for marketing, exceptions for operations. The cost axis is the AI spend attributed to that team, granularly, by skill and model and product. Put the two together and a support workflow with rising reopens on high token spend lands in "Cut," while an engineering team shipping clean merges on the same spend lands in "Scale."
This is the artifact that turns 78%-can't-tie-it-to-outcomes into a defensible, team-by-team allocation. The CFO scales the "Scale" teams, remediates the "Fix" teams, and cuts the "Cut" teams — funding a per-team AI budget instead of one org-wide line item nobody can defend. That is exactly how a CFO governs the AI budget per team, and you can see the verdict rendered as a deliverable in a sample per-team AI ROI report.

How the per-team measurement actually works

Two rules make the by-team method real rather than aspirational, and both come straight from our framework for measuring AI ROI. Cost the AI usage granularly, per team — as a denominator, not a headline. An aggregate token bill can't tell you which team, which workflow, or which model is generating the spend. Cost has to be attributed by skill, by model, and by product — including multiple products at once — so each team's denominator is precise. OpenTelemetry (OTEL) instrumentation is what captures usage cost at the level of the work rather than the invoice. In AIReturn's model this is v1 scope — AI-usage (token) cost across Copilot, ChatGPT, Claude, Cursor, and in-house agents; fully-loaded human/salary cost is v2 and deliberately out of scope today. Measure output against the team's own baseline — never against another team. Output is the throughput of the function paying for AI; rework is a normalized index of the friction and touchpoints it takes to reach an accepted outcome, compared only to that team's history. The comparison that means anything is this team, now, versus this team, before AI. A cross-team leaderboard is not a stricter version of this — it is a different, invalid measurement. Because the signals differ by function, the method is applied function by function, deepest first. Engineering is fully instrumented today; support, sales, product, marketing, and operations expand area by area as each function's outcome-and-rework definitions mature. The equation never changes — only the tells it reads do.

Where AIReturn fits

AIReturn is AI-work intelligence: it proves whether AI spend pays off, team by team, by measuring output net of rework across every AI vendor — not just engineering, and not through a single-vendor dashboard. This is the horizontal claim: the same per-team method spans engineering, product, support, sales, and operations, which is precisely where velocity-only tools (built for engineers alone) and adoption-only tools (built to count seats) stop. Cost is its denominator — attributed granularly by skill, model, and product via OTEL, across every vendor employees actually use. Rework-adjusted output is its numerator, read from each function's own signals. The result is a Cost × Rework verdict per team and a per-team AI budget the CFO and Chief AI Officer can defend. Each function's spoke — engineering, support, sales, product and design, marketing, operations — works the same equation with the signals specific to that team.

Frequently asked questions

Which teams get the most ROI from AI? There is no fixed ranking, because output isn't comparable across functions — a team "wins" by beating its own pre-AI baseline, not another team. Directionally, engineering shows the most measurable return today because its rework signals (reverts, churn, extra review rounds) are concrete. Deloitte found 66% of organizations see efficiency gains but only 20% see revenue gains (2026); return concentrates in the teams whose rework stays flat as output rises. Can you measure AI ROI with one company-wide number? No. A single blended figure averages a paying-off team and a burning team into a meaningless middle, and it compares functions whose output uses different units. Measure AI ROI per team, each against its own baseline, then allocate the AI budget team by team. Only 28% of AI use cases fully meet their ROI target (Gartner, 2026) — the average hides which ones. How do you compare AI ROI across departments? You don't compare the level of output across departments — pull requests and resolved tickets aren't the same unit. You compare each department's improvement over its own baseline, and you compare its position on the Cost × Rework matrix (scale/keep/fix/cut). That gives a CFO a defensible, like-for-like decision — improvement and verdict — without the category error of ranking functions against each other. What are AI rework signals, and why do they differ by team? Rework signals are the events in a team's own tools that reveal AI output had to be redone rather than accepted: reverts and extra PR rounds in engineering, reopens and reassignments in support, stage regression in sales, requirements/spec volatility in product, redo cycles in marketing, exceptions in operations. They differ because each function ships a different outcome work item, so "getting redone" looks different in each. Rework is the denominator that decides whether AI paid off. Why do only some teams see AI revenue gains? Because efficiency and revenue are different outcomes, and most functions produce efficiency, not revenue, directly. Deloitte's 2026 survey put efficiency gains at 66% of organizations versus revenue gains at 20%. Revenue-facing return tends to appear where AI advances a deal or retains a customer without adding rework; support and sales can show it, but only when reopens and stage regression stay flat. What is a per-team AI budget? A per-team AI budget funds AI spend function by function based on proven output-net-of-rework, instead of one blanket org-wide "AI budget." Each team's position on the Cost × Rework matrix sets the move — scale the clean-and-expensive teams, fix the sloppy-but-cheap ones, cut the expensive-and-reworked ones. It turns AI spend from an indefensible line item into a governed, evidence-based allocation the board can review.

Sources

See the return on your own numbers.

Get a clear, per-team return-on-AI picture in weeks — output net of rework, reconciled to your invoice.