At Infobip, more than 90% of employees are monthly active AI users. Adoption turned out to be the easy part. The much harder question is what all that usage actually delivers. AI spend is centrally visible; the value it creates is not. 

Value can show up in very different ways: a cost might disappear from the budget, a team might free up capacity and use it to take on more work, or AI might surface a commercial opportunity that eventually turns into revenue. These are all meaningful outcomes, but each one requires different evidence.

We started grouping AI impact into three categories: savings, productivity and revenue. The categories gave us a practical way to ask what changed, what evidence supports the change, and how confidently we can attribute it to AI. 

The distinction matters because the same AI use can lead to very different outcomes. A faster process might reduce external spending, free up capacity, or simply shift work elsewhere. An AI-supported commercial lead might turn into revenue – or it might lead nowhere. And a manager may reasonably feel that a team is more productive, even when the delivery data tells a more complicated story.

AI changes where the work happens 

Our first real lesson came from engineering: getting faster at one part of the job doesn’t necessarily mean getting more done overall. 

In the teams and period we looked at, code was coming together faster in a number of cases. But that was only part of the story. More effort was also going into reviewing AI-generated code, understanding it, testing it and fixing it. The quality measures we tracked remained stable or improved slightly. 

The work had changed shape. Some tasks disappeared, some became faster, and others moved further down the process. Delivery metrics could show us that something had changed, but they couldn’t always tell us what that change meant for productivity. 

That distinction matters for the framework. If AI saves money, we can usually point to a financial decision. If it frees up capacity, we need to understand what happened to that capacity. If it supports revenue, we need to follow the outcome far enough to establish what actually happened. 

Writing code has never been the only thing between an idea and a product in customers’ hands. Engineers still need to understand the problem, decide what to build, choose the right architecture and make sure the finished product works as intended. AI can accelerate one of those steps without accelerating all of them. In some cases, it simply moves the bottleneck. 

We also saw the role of the developer expanding. As AI took on more of the implementation work, people were able to contribute to problems that previously required more specialized help. Teams could take on more within the same footprint. 

Managers across Infobip reported increases in capacity. Almost all said they would feel the absence immediately if their AI tools disappeared tomorrow. But there was another side to that gain. 

Some of the remaining work required more context switching and cognitive effort. People were reviewing generated output, moving between a wider range of tasks and keeping more context in mind at once. AI took some work off people’s plates, but it also changed what they had to pay attention to while doing the rest. 

When manager estimates and delivery data disagree 

Where we could compare managers’ estimates with delivery telemetry, the picture became more complicated. Some measures supported the confidence behind those estimates, others didn’t. 

That doesn’t necessarily mean the managers were wrong. They see things that a dashboard cannot: work that quietly stopped happening, capacity redirected to a more valuable task, or problems that were solved before they ever became tickets or metrics. 

We found a similar tension in external research. METR’s 2025 randomized controlled trial found that experienced open-source developers working in repositories they knew well took about 19% longer to complete tasks with AI assistance, even though they estimated afterward that they had been roughly 20% faster. 

A February 2026 follow-up complicated that result further as more developers began opting out of working without AI, introducing a self-selection effect into the measurement. And as AI moves from a tool we prompt to agents that run on their own, that gap only widens – value gets harder to attribute, not easier. 

Activity, perceived productivity and business impact are different things. The framework needed to keep those distinctions visible rather than compressing them into one AI productivity number. 

What counts as AI impact? 

AI use at Infobip goes well beyond engineering. In go-to-market, for example, AI supports account research, proposal generation, and the identification and prioritization of commercial opportunities across the portfolio. 

That means the same three categories have to work across very different kinds of work. Engineering and product teams give us delivery telemetry, while business functions may need evidence from process times, customer response, risk, pipeline, conversion or revenue. 

Across Infobip, we ask the same questions of every AI use case. What changed? What did it cost? Why do we believe AI contributed? Who owns the outcome? And what evidence would convince someone outside the team? 

The answers help us test each claim against the three categories: savings, productivity and revenue. Each requires different evidence and a different standard for what counts as a credible result. 

Savings: did a spending decision actually change? 

Savings are the most straightforward category, because they tie back to a real financial decision: a license cancelled, a vendor replaced, external spending reduced, a planned cost avoided in a way you could point to. 

One example held up well: a team built a tool during an internal hackathon that replaced an external regulatory-monitoring subscription the company had been paying for. When the tool went live, the subscription was cancelled and the cost left the budget. 

Not every freed-up hour belongs here, even when it’s genuinely valuable. Time saved that never actually leaves a budget line belongs in productivity. 

Productivity: what happened to the capacity that got freed up? 

Productivity claims almost always start with “we saved time.” The harder question is what happened to that time: did the team get more done, deliver faster, improve quality, reduce risk, respond to customers sooner, cut errors, or contribute to revenue downstream? A team can create real value without its budget shrinking by a dollar, but that value has to show up somewhere observable; it can’t be asserted from the time-saved estimate alone. 

One pattern we’ve seen across our internal hackathons: a team builds a first working tool, puts it into production, then builds a second and third for adjacent problems – one prototype becoming a small suite addressing different parts of the same workflow. A team automates a recurring manual process and moves from prototype to recurring operational use within weeks. 

Being in production and being used regularly still isn’t a verified productivity return. For the cases here, recurring use is clear; the next measurement step is connecting that use to something measurable – faster resolution, more completed work, better quality, fewer errors. That step is harder than building the tool, and it’s where most of the real measurement work happens. 

Revenue: can we complete the chain? 

Revenue is the hardest category to attribute cleanly. A credible claim needs a defensible line from AI-supported activity to a commercial outcome  –  qualified pipeline, conversion, retention, expansion, or recognized revenue – and has to reckon honestly with what would have happened anyway. 

One team built a tool during a hackathon that surfaced a commercial opportunity nobody had previously had visibility into. The tool gave the team new information, but it didn’t produce revenue by itself. 

We call this an AI-supported opportunity, and we’ll only call it a realized revenue result once the financial outcome and the tool’s contribution to it can both be verified. This is where go-to-market matters most, a shorter path to a deal isn’t the same as a deal AI closed. The cases that haven’t completed that chain may still deserve continued investment, so we keep them in the pipeline of things worth watching. 

Across all three categories, we start from the changed business outcome because usage tells us only that people used the tool. 

From success stories to defensible claims 

Once we had a way to categorize AI impact, the next question was harder: how do we know when a claim is actually backed by evidence? 

We started by looking across the organization, more as a proof of concept than a formal audit. The signals were already there. Managers and teams could point to AI-related outcomes, but most of that information lived in conversations, individual teams and scattered examples. 

What was missing was a consistent way to follow those signals and test them. 

We built a validation loop around that process. A regular survey of managers, which scales better than the ad hoc probing conversations we ran as a pilot. Managers flag potential impact: a metric moved, a tool got used, something changed on the team. An owner is attached to that signal, the outcome we’d expect to see if the claim holds is defined, and we look for evidence beyond the manager’s own account. The claim is then confirmed, revised, or dropped. 

Finance can validate the financial side of a claim. It can’t independently judge every quality, risk, or experience outcome. Those need evidence and accountable judgment from the people who understand the work. 

Finance and transformation teams have long distinguished forecast benefits from realized ones. We’re adapting that discipline to AI use spread across far more tools, workflows, and departments than a typical transformation program deals with. 

An estimate stays useful as long as it’s anchored to something observable, its limits are stated plainly, and there’s a path toward stronger evidence later. We reserve “verified” for the smaller number of savings that have completed independent financial review, and “verifiable” for estimates anchored to something observable that haven’t yet cleared that bar. 

The point isn’t only to justify spending after the fact. Better evidence helps us decide what to scale, where we need sharper instrumentation, which teams need support, and where enthusiasm might be running ahead of the results. 

We now have a practical framework for thinking about AI value across savings, productivity and revenue, along with a validation process that is still evolving. What we still cannot measure consistently is the value of capacity that has been freed up but redirected into work that has no obvious baseline, as well as the contribution AI makes to outcomes shaped by many other factors. That is where attribution gets hardest and where the next stage of our measurement work begins. The strategic case for AI at Infobip was never really in doubt. The startup instinct that got us here – people building, fast – is exactly what we want to keep; our job is to make sure our read on the value keeps pace with it. As our CTO has put it, this is about expanding what people can do, not replacing them. The harder task is the one we’re still doing: getting the spend and the value back in the same room and letting the evidence guide where our next investment goes.