How we estimate the hours a process is costing you

Every estimate on this site starts with the same simple calculation. Deliberately simple.

We would rather you could check the maths yourself than be impressed by it.

hours per week      = (minutes per occurrence × times per week) ÷ 60
working days/year   = (hours per week × 46) ÷ 8
share of a week (%) = (hours per week ÷ 40) × 100

The arithmetic is the easy part. The harder part is deciding what should actually go into it.

The assumptions, stated

46 working weeks a year. Not 52. We use 46 as a deliberately conservative planning assumption, allowing for annual leave, public holidays and quieter periods during the year. It is not meant to reproduce every country’s working calendar exactly.

An 8-hour day and a 40-hour week. Round numbers, close enough for an estimate whose purpose is to tell us whether a process is worth looking at, not calculate payroll.

We round displayed estimates down. The calculation itself keeps its precision. When we show the result, we round conservatively rather than making the case look better than it is.

An estimate that flatters the case catches up with you during delivery — and delivery is where the relationship actually starts.

The part people tend to miss

Ask how long a task takes and most people remember the obvious part.

A quote is “fifteen minutes” until you count pricing it, writing the email, attaching the documents, checking the customer details, following up twice and finding the thread again a week later.

Then it may be closer to forty.

That gap is not carelessness. Much of the work around a task is easy to forget precisely because it does not feel like the task itself.

The same happens with reports, bookings, invoices, customer onboarding and dozens of other small processes.

We therefore count active human effort, not elapsed time.

Waiting three days for a customer to reply is not three days of work. The ten minutes spent reopening the conversation, checking the status and following up are.

That distinction matters.

It is also why, during the 20-minute check, we ask what happens around the work, not just during the obvious step in the middle.

Ten hours of work does not mean ten hours of automation

Finding a process that consumes ten hours a week does not automatically mean those ten hours are worth automating.

The process may be about to change.

Reliable access to the data may be disproportionately expensive.

Half of the apparent process may actually depend on human judgement.

Or the work may happen so rarely that removing it would never repay the cost of building anything.

And a task that involves judgement is not necessarily off limits. It may simply mean that only part of it should be automated.

If software can process 80 routine cases and send the 20 unusual ones to a person, that may be far more valuable than trying to automate all 100.

The useful question is rarely:

Can we automate this entire process?

It is:

Which parts can we automate safely, and what should remain with a person?

Why this matters more than the number

The calculation tells us the size of the opportunity.

It does not tell us whether we should pursue it.

That requires understanding the process, the systems around it, the cost of integrating them, how likely the process is to change and where human judgement still matters.

The arithmetic is deliberately boring.

The diagnosis is the valuable part.

That is why the written follow-up after our 20-minute check includes not only what we think is worth automating, but also what we would leave alone — and why.