PRAPI Research · 2026-10-24

How Operators Prove an AI Rollout Is Working: The Metrics That Convinced Leadership

Most AI rollouts report usage and time saved, and most leadership teams have stopped trusting either. We asked the people who own AI rollouts which single number actually changed a leadership decision, and which metric looked healthy while adoption was quietly failing. Their answers converge: the numbers that moved budgets came from a system of record, were compared against a baseline or a control group, and counted the work a person accepted, not how often anyone opened the tool.

7 contributors cited


Usage was the number almost everyone started with, and the number almost everyone stopped trusting. Logins and prompt counts climbed in the first weeks of nearly every rollout we heard about, and self-reported time saved came in high. The numbers that actually moved a decision were different in kind: a figure pulled from a system the team already used for real work, compared against a baseline or against people not using the tool.

Pattern 1: Pull the number from the system of record, and compare

Harrison Tang, co-founder and CEO of Spokeo, rolled out an AI writing and summarization assistant to a support and operations team of about 25 people. The usual numbers looked great within a month: over 90 percent of the team logging in weekly, and people estimating they saved roughly five hours each. "Leadership, understandably, didn't believe either number." What changed the decision:

Median time to resolve a support ticket, compared between agents who used the tool on a given ticket and those who didn't, measured on the same ticket categories. Resolution time dropped about 18 percent for tickets where the tool was used, with no increase in reopened tickets. That was the number that got the rollout expanded to a second team, because it came from our ticket system rather than from anyone's estimate.

Dieter Blom, Director at Versys Media, measured a client services team that got GPT-assisted first drafts, internal knowledge lookup and structured handoff notes inside its existing workflow. Average turnaround per client query, from open to manager-ready draft, dropped from just under 26 minutes to 11 minutes over six weeks, while revision rates held steady. The figure that unlocked budget to extend the rollout into another department was simpler:

the team was handling 41% more request volume without adding staff.

Sasha Berson, Co-Founder and Chief Growth Executive at Grow Law, tracked output per head, because in a services business "capacity becomes the entire limit to growth." When that figure showed around a 30% increase, leadership implemented the tool company-wide instead of limiting it to a pilot.

Pattern 2: Count the work a person accepts

On a small team, the real signal can sit one step after the AI: whether a person kept, approved or rewrote what it produced.

Zain Kazmi, founder of DevMarDe, had no leadership decision to report, but did have a signal worth trusting:

The signal that mattered was whether I approved a draft or rewrote it. After the voice guide, I started approving drafts instead of rewriting them. Approve versus rewrite is a number a small team can count without self-reporting.

Pattern 3: Agree on the test before you see the result

Aleksei Mikhailov, a fractional CTO with more than 20 years in software, watched a pilot with a large customer drift for months, with every review meeting ending in "looks promising, let's extend it," because nobody had defined what working meant. The fix was a shared test:

We sat down with the customer's team and wrote around 60 real questions from their own work, with the answers they'd accept. Scored the AI against that set every week, both sides looking at the same number (fresh batch each month so nobody could tune to the test).

The pilot closed as a paid contract once the customer's leadership "could point to a score and say yes."

Where it looked healthy and wasn't

The operators were specific about the metrics that misled them.

Usage. Harrison Tang's prompt counts "kept climbing while the work barely changed":

a large share of the activity came from a handful of enthusiasts, and most of the team was using the tool for a single low value task, like rewording emails. We caught it by sampling actual tickets instead of reading the dashboard, and by asking people to show us one real task they'd done with the tool that week. Many couldn't.

Dieter Blom saw strong weekly active users while people opened the tool, tested it, then did the real work manually. Comparing system activity against completed task flow and final deliverable timestamps showed that task completion speed in two pods had barely moved: "adoption was performative, not embedded." Sasha Berson found heavy usage hiding poor usage, with people "accepting ineffective first drafts without taking the time to edit." The fix was retraining people to steer the tool and evaluate its results.

Accuracy nobody checked. Hayat Amin, a three-time exited C-suite executive, rolled out an AI commentary tool across a 30-person finance and ops team. Usage hit 80% in week two, and time saved came in at 40%.

Leadership was pleased until a board pack went out with a figure nobody had verified, because the model had interpolated it from adjacent data.

The number that changed the budget decision was the accuracy rate on outputs touching figures sent outside the building, tracked manually for 90 days.

A blank chat box. Aleksei Mikhailov saw a few percent of users opening an AI chat weekly and read it as early traction. But users were there to finish a task, and a blank chat box asked them to stop and think of a question. Moved into the daily workflow as a "draft it" button inside a form they already used, the same model went from a few percent to about half of active users. "I'd probably have kept watching that engagement number and feeling fine about it for a while."

Results that don't scale. Dennis Beytekin, co-founder and CEO of Scale Oxford, a UK digital marketing agency, piloted AI-generated social media creatives for clients and saw consistent uplift in engagement rate, CTR and impressions per post. The rollout still proved difficult to scale consistently:

AI-generated visuals often contained small inaccuracies, struggled to maintain a consistent brand identity, and increasingly started resembling generic AI-generated content.

The through-line

Across the answers, the same rule held: set a baseline before rollout, take the outcome number from a system rather than a survey, compare it against the work done without the tool, and treat usage as a question, not an answer. Harrison Tang put it plainly:

Pick one outcome metric that already lives in a system your team uses for real work, and compare tool users against non users on the same tasks. Treat usage numbers as a starting point for questions, never as proof.

Dieter Blom's version is shorter: "measure the business process after AI touches it, not the AI touch itself."

Contributors

  1. I’ll answer from the support and operations side, where we rolled out an AI writing and summarization assistant to a non-technical team of about 25 people. What we measured: We started with the usual numbers: weekly active users and self-reported time saved. Both looked great within a month, with over 90 percent of the team logging in weekly and people estimating they saved roughly five hours each. Leadership, understandably, didn’t believe either number. The single number that changed a decision: Median time to resolve a support ticket, compared between agents who used the tool on a given ticket and those who didn’t, measured on the same ticket categories. Resolution time dropped about 18 percent for tickets where the tool was used, with no increase in reopened tickets. That was the number that got the rollout expanded to a second team, because it came from our ticket system rather than from anyone’s estimate. The metric that looked good while adoption was failing: Prompt counts. They kept climbing while the work barely changed. When I looked closer, a large share of the activity came from a handful of enthusiasts, and most of the team was using the tool for a single low value task, like rewording emails. We caught it by sampling actual tickets instead of reading the dashboard, and by asking people to show us one real task they’d done with the tool that week. Many couldn’t.
  2. The number that changed leadership's mind for us was cycle time reduction on a real business process, not usage. In one rollout with a non-technical client services team, we introduced GPT-assisted first-draft responses, internal knowledge lookup, and structured handoff notes inside their existing workflow. We tracked average turnaround time per client query from open to manager-ready draft. That dropped from just under 26 minutes to 11 minutes across a six-week period, while revision rates held steady. That was the number leadership cared about because it tied directly to capacity. Same headcount, materially more throughput. The decision-changing figure was simple: the team was handling 41% more request volume without adding staff. That unlocked budget to extend the rollout into another department. Prompt count, login frequency, none of that did the job. Leaders wanted evidence that the operating model had changed. Fair enough. The metric that looked healthy while adoption was actually weak was active users per week. On paper it was strong. In reality, people were opening the tool, testing it, then doing the real work manually because they didn't trust the output enough to use it in production. We caught that by comparing system activity against completed task flow and final deliverable timestamps. Usage was up, but task completion speed in two pods had barely moved. That told us adoption was performative, not embedded.
  3. The number that changed a decision: Our goal was to determine output per head, which indicates how much work each team member could produce without lowering quality. That is what mattered to leadership as capacity becomes the entire limit to growth in a services business. When the figure showed around a 30% increase as a result of the AI rollout, it prompted leadership to implement it company-wide as opposed to limiting it to a pilot project. While the statistics about usage and hours saved were nice, it was the figure associated with increasing the number of clients served while keeping staff the same that proved to be the most effective. The metric that looked good while adoption was quietly failing: At the very start, we kept track of the AI tool usage to see how frequently people would open and use it and it looked promising with excellent engagement. However, the output and quality were not matching the level of usage. When we looked deeper into it, it turned out that while people were utilizing AI a lot, they were doing it poorly, by accepting ineffective first drafts without taking the time to edit and seeing it as a way to lessen their workload instead of as a valuable tool.
  4. We are a small team, so I have no leadership decision or big figures to quote. What I can say is which signal I trust. Usage told me nothing: the tool's drafts were accurate, and they still did not sound like me. The signal that mattered was whether I approved a draft or rewrote it. After the voice guide, I started approving drafts instead of rewriting them. Approve versus rewrite is a number a small team can count without self-reporting. The metric that looked fine was factual accuracy: the drafts were accurate and I still would not publish them as written. I caught it by reading the drafts as the person who has to sign them.
  5. An AI startup I worked with had a pilot going months with a large customer. Every review meeting ended with "looks promising, let's extend it." Frustrating, because nobody had defined what "working" meant. We sat down with the customer's team and wrote around 60 real questions from their own work, with the answers they'd accept. Scored the AI against that set every week, both sides looking at the same number (fresh batch each month so nobody could tune to the test). The pilot closed as a paid contract once their leadership could point to a score and say yes. For the metric that looked good while things were quietly broken: engagement on an AI chat. A different product showed a few percent of users opening it weekly, which felt like early traction. Users were there to finish a task, though, and a blank chat box asked them to stop and think of a question. We moved the same model into the daily workflow as a "draft it" button inside a form they already used. Went from a few percent to about half of active users, same model, same cost. I'd probably have kept watching that engagement number and feeling fine about it for a while. I'm a fractional CTO, 20-plus years and over 300 projects, a lot of them startups building their first AI features.
  6. Most teams measure logins and time saved, and I'd argue both numbers are almost designed to mislead you. As a three-time exited C-suite executive who's been part of some of the fastest growing tech companies in the world, I've seen this pattern repeatedly. We rolled out an AI commentary tool across a 30-person finance and ops team. Usage hit 80% in week two. Time saved came in at 40%. Leadership was pleased until a board pack went out with a figure nobody had verified, because the model had interpolated it from adjacent data. The number that actually changed a budget decision was accuracy rate on outputs touching figures sent outside the building, tracked manually for 90 days. That told us whether adoption had genuinely changed the work.
  7. One of our most interesting AI experiments involved offering pilot AI graphic design services to our clients, particularly in social media creatives. For measurement, we compared AI-generated creatives against conventional designs using engagement rate and CTR as our KPIs. We also tracked the average time required to prepare each post, from initial concept to final approval, to understand the actual efficiency gains. We saw consistent uplift in both engagement rate and CTR, as well as impressions per post. However, the rollout was surprisingly difficult to scale consistently. AI-generated visuals often contained small inaccuracies, struggled to maintain a consistent brand identity, and increasingly started resembling generic AI-generated content.

Methodology

This report draws on direct responses to a research brief PRAPI posted publicly from October 16 to October 23, 2026. The brief asked people who own AI enablement or an AI rollout for non-technical teams what they measured to show the rollout was working, which single number changed a leadership decision such as expanding, funding or shutting down part of a rollout, and which metric looked good while adoption was quietly failing. It asked for the team, the tool and real figures, and stated that vendors describing their own product's analytics were not wanted.

Responses came through three channels: the MentionMatch source-request network, the Connectively source board, and the PRAPI response form on prapi.dev. We received 67 submissions: 35 through MentionMatch, 21 through Connectively and 11 through the response form. Each ran through an AI-detection check at intake, and submissions flagged by that check were not quoted.

Seven contributors are quoted. Selection was editorial: we favored first-hand, specific accounts that answered the brief's questions, and set aside answers that described the respondent's own product, offered general advice without a rollout behind it, repeated another contributor's point, or could not be attributed to the person named. Every contributor quoted consented to named citation.

Quotes are verbatim from the submissions, trimmed for length. Figures such as resolution times, turnaround times, output per head and usage rates are the contributors' own reports and were not independently verified. Titles reflect what contributors provided. Contributors speak for themselves, not for their employers.

Research conducted by PRAPI. GTM for founders running portfolios.

Research conducted by PRAPI. PR system for founders running portfolios. Try PRAPI →