Manual minutes per transaction is better than "AI adoption"

“AI adoption” is becoming one of the least useful metrics in software.

It can mean that employees opened an AI tool, that a feature generated text, that a model touched a transaction or that management announced an initiative.

None of these necessarily changes the economics of the business.

For operational software, I prefer a more basic measure:

How many manual minutes are required per transaction?

This metric is difficult to make look better than reality.

If a booking, claim, invoice, support request or supplier exception still requires twelve minutes of employee attention, adding an AI-generated summary has not transformed the workflow.

It may have improved it. It has not transformed it.

Manual minutes also captures something that binary automation metrics miss.

A transaction may not be fully automated, but reducing human effort from fifteen minutes to four is meaningful. Conversely, a transaction may be classified as “automated” even though employees spend substantial time monitoring, correcting and reconciling the system afterward.

The metric forces teams to look at the entire lifecycle.

That includes collecting information, making decisions, communicating with third parties, checking outcomes, correcting errors and reconciling financial records.

It also exposes hidden labor.

Many software businesses underestimate work performed through email, spreadsheets, Slack messages, supplier calls and informal knowledge. Because the work does not occur inside the core product, it disappears from product analytics.

Manual-minutes analysis brings it back into view.

The metric should be paired with at least three others:

• The percentage of transactions requiring no human involvement.
• The error or rework rate.
• The cost of failure.

These metrics prevent the company from optimizing only for labor reduction. Saving three minutes is not useful if it doubles the number of costly errors.

The deeper benefit is organizational.

Once manual minutes become visible, teams stop arguing abstractly about whether a feature is “AI-powered.” They begin asking practical questions.

• Why did a person need to intervene?
• Could the system have obtained the missing information?
• Could the decision have been converted into a policy?
• Could the exception have been routed to the right person sooner?
• Did the automation remove work, or merely move it somewhere else?

This is the difference between adopting AI and improving operations.

The first is easy to announce.

The second changes margins.