Measuring effort without timesheets: let the work keep time

Every conversation about capacity, pricing or AI ends up at the same question: how long does this task actually take? Most finance teams answer it with timesheets, and most finance leads quietly know the answer is wrong. People fill them in on Friday afternoon, from memory, in six minute units, against client codes rather than tasks. There is a better instrument, and it is already sitting in your workflow. You can measure effort without timesheets by recording when each piece of recurring work changes state, and letting the gaps between those moments do the counting.

Why timesheets get recurring work wrong

This is not a complaint about the people filling them in. Timesheets were built for billing, and they do that job. They were never built to tell you what a task costs.

A few things go wrong when you try to use them that way:

• They record the client, not the task. "Client A, 3.5 hours" tells you nothing about whether that was the bank reconciliation, the VAT workings or a long call about a missing invoice.
• They are written after the fact. By Friday, Tuesday's work has blurred. People round to whatever feels plausible.
• They absorb the dull parts. Chasing a document, waiting for a file, re-opening last month's working to remember the method: these rarely get their own line, so they vanish into whatever task was nearest.
• They invite a performance. If people suspect a number will be judged, they shape it. Big tasks get trimmed, small ones padded.

The result is a number nobody would bet on, used to make decisions that matter: how many clients a team can take, what a fixed fee should be, and which tasks are worth handing to an agent.

How to measure effort without timesheets

Recurring work already moves through a small set of states. A typical set looks like this:

1. Not started. The task exists for this period but nobody has picked it up.
2. In progress. Someone is working on it.
3. Waiting. It is blocked on something outside the team: a client, a bank file, an approval.
4. In review. The doer has finished and a reviewer has it.
5. Done.

Every time a task moves from one state to another, a timestamp is free. The doer clicks "start", "waiting on client", "send for review", and the clock keeps itself.

From those timestamps you get four numbers per task instance:

• Active time: the total time spent in progress.
• Waiting time: the total time blocked outside the team.
• Review time: the time from handing over to sign-off.
• Elapsed time: first start to done.

These four numbers answer different questions. Active time feeds capacity and cost per task. Waiting time tells you where the calendar slips, and it is usually fixed upstream, not by working faster. Review time is the cost people forget when they count a task, which we covered in who checks the checker. Elapsed time is what the client and the close calendar feel.

What state times can and cannot tell you

Be honest about the limits, because the team will spot them immediately if you are not.

In progress is not hands on keyboard. Someone starts the reconciliation, takes a phone call, answers two emails and comes back. The state says forty minutes; the work might have been twenty-five. Over one instance that is noise. Over twelve monthly instances, the median settles into something useful, and it is far closer to reality than a Friday guess.

Look at medians and spread, not single runs. Take a hypothetical bookkeeping firm tracking the monthly bank reconciliation for one client over six months. Say, as an illustration, that active time sits between 40 and 60 minutes five months out of six, and then jumps to three hours in one month. The median tells you what the task costs. The outlier tells you something happened, and it is almost always an exception: a new account, a batch of payments with no reference, a change in the bank's export format. That outlier is worth a line in your exceptions log.

Waiting needs its own state. If people cannot mark a task as waiting, the clock runs while they sit on a missing file, and active time swells with days of nothing. The single most common reason state-based measurement looks wrong is a missing "waiting" state.

It measures tasks, not people. Two people doing the same task at different speeds is information about the task: one of them is probably following a better method, or has a manual the other has not seen. It is not a ranking.

Measure the task, not the person

That last point deserves its own section, because it decides whether any of this works.

Tell the team what is recorded, why, and what it will be used for: capacity planning, sensible fees, and deciding which tasks to document or hand over first. Report it per task, as medians across instances and people. Do not put it in appraisals, and do not build a league table from it.

The reason is partly fairness and partly practical. The moment state times are used to judge individuals, people stop clicking "start" until they are nearly done, and the data becomes as shaped as the timesheet it replaced. The honest version is the only version that produces honest numbers.

It also helps to say plainly where this leads. Knowing what a task costs is how a team argues for taking the repetitive half of the work away first, with the hours going back to review, clients and judgement. Measuring effort without timesheets is designed into Beaks for that reason: effort comes from state changes on recurring work, not a number someone has to guess and maintain.

Starting with a spreadsheet

You do not need a new tool to try this. Pick one recurring task that runs at least monthly, for example a bank reconciliation, the payroll check or a supplier statement run. For its next few runs, ask the doer to record five times in a shared sheet:

1. Started.
2. Went to waiting, and back out of waiting (as many times as needed).
3. Sent for review.
4. Review finished.
5. Done.

That is one tap of a clock per change, not a reconstruction of the week. After the first run you will have a first honest number for active, waiting and review time, and after three or four runs a median worth using. Compare it with the timesheet total for the same work. The gap is the cost of measuring by memory. Put the numbers next to the step by step costing method in the real cost of a bank reconciliation and you have the start of a per task cost.

One thing to do this week

Choose one recurring task, add a "waiting" state to however you track it today, and log the five timestamps for its next run. Tell the doer why you are doing it and that the number belongs to the task. Next month, run it again and look at the median.