Where does the time AI saves actually go?
The direct AI bill may be small. Finding where the time goes after a task gets faster is what tells a company whether the work improved.
The number that stood out to me in Chamath Palihapitiya's recent essay on AI return was $12.50. Citing Ramp's AI Index, he says the median company in its business-spending data pays about that much per employee each month for AI. He compares it with an assumed $8,500 monthly cost for an employee and arrives at a striking threshold: roughly 0.15% more productive, or only a few minutes of a working week, to cover the direct AI bill. On a 40-hour week, the arithmetic is about three and a half minutes. If the bar looks that low, why is it still hard for companies to see the gain?
The calculation is useful because it makes the question concrete, but it is not a promise of return. Ramp measures spending among businesses on its platform, not every company's full AI costs, and $8,500 is an assumption about employee cost rather than a universal salary. Training, review, changing a process, and maintaining a workflow take time too. Even when an employee saves three minutes, those minutes do not automatically turn into lower payroll expense. They may create capacity for another customer, a better decision, or a less rushed day, but the business has to decide how that time will be used.
A field experiment across 66 firms and 7,137 knowledge workers helps explain the gap. Workers were randomly offered access to a generative AI tool inside software they already used for email, meetings, and writing. Among those offered the tool who used it, time spent on email fell by about two hours a week in the second half of the six-month experiment, but the researchers did not detect a broader shift in the quantity or composition of their tasks from giving individuals access. That is meaningful time back for a person. It does not tell us where the time went afterward, or whether a customer received an answer sooner. The study took place in larger organizations with a particular tool, so its results are a prompt to examine a smaller firm's own work rather than a forecast for that firm.
Imagine an employee prepares a customer proposal in twenty minutes instead of an hour, then waits two days for the same approval as before. The first part of the job improved, but the customer still receives the proposal on the same day they always did. For a company with 10 to 100 employees, this can be easy to miss because a small number of people are used to filling the gaps. Someone drafts a response faster, but still has to find the latest numbers, ask a colleague to check them, wait for a decision, and make another pass. If the only measure is how quickly the first draft appeared, the team may celebrate a saving it cannot yet see in its customer experience or its capacity to take on more work.
This is why Ruby looks at the path around a task, not just the task itself. We get to know the people doing the work, follow what happens from the first request to the final decision, and document where information is missing or a question keeps returning to the same person. Once the team can see that path, it can decide whether the answer is a better AI workflow, a clearer approval rule, a shared source of information, or simply removing a step that no longer serves a purpose. The technology matters, but so does knowing what should happen to the time it gives back.
A team could test this with one recurring process. Take a set of recent requests and note when each one arrived, how long employees spent on it, how long it waited between people, how many times it came back for correction, and when the customer or colleague got a useful answer. Then improve one part of the process and watch those same measures. If drafting time falls but elapsed time stays flat, the next problem is visible. If the whole path gets shorter without hurting quality, the company has a stronger reason to say AI made the work better.
There is also a choice to make about the time employees get back. It could let a team respond to more customers, spend more care on difficult cases, or reduce the repeated work that keeps someone late. Those are different outcomes, and a leader should be clear about which one matters before claiming a return. At Ruby, we work alongside employees so they can use the tools with confidence, then look at whether the process around those tools gives time back to the work that matters most. A faster draft is a good start. What happens next tells you whether the business changed.
Sources & further reading
Start with the work. Build the right system around it.
We help teams understand where AI is useful, choose the right tools for the job, and build the confidence to keep improving.
Book a Call