The question most teams cannot answer
Payroll is usually the largest operating cost a services or product team carries. For a 20-person team on an average fully-loaded cost of INR 12 lakh a year, that is INR 2.4 crore of annual payroll. The uncomfortable question is what share of it converts into work anyone can point to.
Most teams cannot answer that, and the honest reason is not laziness. It is that nobody has the data, and the data is genuinely awkward to collect without making people feel watched.
This is a model for estimating the gap, not a claim about your team. Run it with your own numbers, treat the output as an order of magnitude rather than a figure, and read the section at the end on when this model does not apply.
The calculation, with the assumptions visible
Every number below is an input you should replace. The point is the structure, not the result.
Inputs
- Team size: 10 people
- Fully loaded cost per person: INR 12,00,000 per year (salary plus benefits and overhead)
- Working days: 250 per year, 8 hours per day
- Effective hourly cost: INR 12,00,000 divided by 2,000 hours = INR 600 per hour
- Assumed recoverable loss: 1 hour per person per day
Result
1 hour x INR 600 = INR 600 per person per day
INR 600 x 250 days = INR 1,50,000 per person per year
Across 10 people = INR 15,00,000 per year
At a fully loaded cost of USD 70,000 and an effective rate of USD 35 per hour, the same model gives roughly USD 8,750 per person and USD 87,500 across ten.
The assumption doing all the work is that one hour. Published research on knowledge work commonly finds only a few hours of genuinely focused work in an eight-hour day, but very little of that gap is recoverable: meetings, coordination, thinking, reading and rest are not waste. One hour is deliberately conservative. If you use three, you are no longer modelling, you are marketing.
Where the time actually goes
Five patterns show up repeatedly once teams have data. We are not going to assign each one a percentage, because any split we published would be invented, and a made-up number in a business case is worse than no number.
Context switching
Knowledge workers toggle between applications and tabs around 1,200 times a workday, and recovering full concentration after a significant interruption takes materially longer than the interruption itself. Activity data shows which applications dominate, whether switching clusters at particular times, and which roles are worst affected — which is usually a workflow or permissions problem rather than a discipline one.
Meeting load
Reclaim.ai's research puts the average professional at roughly 15 hours a week in meetings. The problem is rarely meetings themselves; it is invite sprawl that nobody prunes because nobody has evidence about which recurring meetings earn their cost. Our meeting cost calculator will price a specific recurring meeting for you in a minute.
Unbilled client work
For agencies, consultancies and IT services firms this is the one that touches revenue directly. Time reconstructed from memory on a Friday systematically undercounts short work: a 15-minute client call, an evening revision round, research that felt like overhead. Recovery here means the invoice matches the work, which sometimes means billing less.
Tool friction
Slow systems and broken integrations are a tax nobody itemises. Idle time concentrated around a specific application is a signal that people are waiting on the tool rather than working in it, and it gives an infrastructure argument something better than anecdote behind it.
Unclear priorities
When people do not know what matters next, they default to low-effort visible work: inbox triage, chat, reformatting. That produces activity without output, which is exactly why activity percentage is a poor headline metric. The fix is management clarity, and the data only tells you the pattern is there.
Why the gap widens if you ignore it
- The loss is invisible, so nothing addresses it.
- Inefficient workflows become normal because nobody corrects them.
- New joiners inherit those workflows as the way things are done.
- Delivery slips, and the instinctive response is to hire.
- Headcount multiplies the original inefficiency instead of fixing it.
Run the model above at 10 people and again at 50 and the arithmetic is obvious. The point is not the number. It is that hiring around an undiagnosed process problem scales the problem.
What teams actually change once they can see it
The useful interventions are almost never about individuals.
- Communication norms. If engineers are spending a third of the day in chat, the answer is protected focus blocks and async protocols, not a conversation with the engineers.
- Tool rationalisation. Most teams accumulate overlapping tools nobody audits. Usage data shows which are genuinely used, which are tolerated, and which were abandoned after onboarding.
- A meeting audit. Recurring meetings are organisational debt. Pricing them and reviewing the expensive ones against what they produce is a one-afternoon exercise with a lasting result.
- Billing accuracy. For client work, matching the invoice to the record is the most direct return, and it survives client scrutiny in a way that estimates do not.
Building the business case honestly
If you are taking this to a decision-maker, the structure that survives challenge is:
- Annual payroll for the team in scope
- Your own recoverable-loss assumption, stated openly, ideally an hour a day or less
- The share of that you expect to actually recover, which is a fraction and not all of it
- Tool and rollout cost, including the management time to act on what you find
Then state the assumption you are least sure about and what would falsify it. A business case that survives someone disagreeing with one input is a business case; one that collapses is a pitch.
When this model does not apply
Three cases where the arithmetic above will mislead you, and it is worth knowing them before you spend anything.
- Your problem is direction, not efficiency. If the team is building the wrong things, perfect execution makes it worse. Visibility into hours will not surface that.
- Nobody has capacity to act on the findings. The data does not improve anything by existing. If no manager has the time to redesign a workflow, you have bought a dashboard.
- Deep-work-heavy teams. Research, design and architecture work look inactive precisely when they are most valuable. Applying this model to them produces a number that punishes the work you most want.
And the cost that never appears in these calculations: an invasive rollout that prompts two experienced people to resign will usually exceed everything the model claims to recover. How a programme is introduced is a financial decision, not only a cultural one.
Where to start
Run 30 days with no intervention and no alerts. You get a baseline that makes every later change measurable, and you find out whether the pattern you assumed exists actually does. Most teams discover their bottleneck is not where they thought, which is the entire value of looking.
Do it with the policy written first and employees able to see their own data from day one. Everything in this article depends on people not treating the tool as something being done to them.