There is a tempting idea in project software: if a task is marked "in progress", the tool already knows when it started and when it finished, so it can work out how long it took. No timers to start, no forms to fill, no nagging. The hours simply appear.
We built exactly that. Then we took it out, because the numbers were wrong in a way that quietly poisoned everything downstream.
What automatic accrual actually measures
An automatic timer measures the interval between two status changes. That is not the same as time worked, and the gap between them is not small.
A developer moves a ticket to In Progress at 09:40, hits a blocker at 10:15, and goes to work on something else. The ticket sits In Progress until Thursday. The timer records twenty-nine hours.
A field rep marks a visit report In Progress before driving to the customer. The drive, the meeting, lunch and the drive back all land inside the interval.
Someone forgets to move a finished task to Done before the weekend. Monday morning the tool reports sixty hours on a task that took forty minutes.
None of these are edge cases. They are the normal texture of a working week, and each one inflates the number in the same direction. Wall-clock accrual has no mechanism for distinguishing work from elapsed time, so it systematically over-reports, and it over-reports most on exactly the tasks that were hardest — the ones that got blocked, parked and picked up again.
Why over-reporting is worse than no reporting
An absent number is obviously absent. Someone asks for it and you go and find out.
A wrong number is worse, because it gets used. Inflated hours flow into three places, and each one causes a distinct problem.
Invoices. If you bill hourly, you are now charging a client for a weekend during which nobody touched their project. Either you catch it and manually correct every line — at which point the automation has saved you nothing — or you do not catch it, and eventually a client audits an invoice and finds sixty hours on a forty-minute task. That conversation costs more than the invoice.
Estimates. Teams use historic actuals to estimate future work. Feed a padded history into that process and every future estimate inherits the padding, which makes the team look slow and the work look expensive.
People. Anyone comparing hours across a team is now comparing how promptly people update a board, not how much they did. The person who diligently moves cards looks efficient. The person who leaves a ticket open while thinking looks idle. This is a genuinely corrosive thing to measure people on.
What explicit logs give up, and what they buy
The alternative is to make logging a deliberate act: an entry with hours, a date and optionally a note. Two and a half hours on Tuesday, "revised the pricing section after client call".
The cost is real and worth stating plainly. Someone has to do it, it takes a few seconds per entry, and if nobody does it you have no data at all rather than bad data. That is a genuine trade-off, not a free win.
What you buy is that every hour in the system was put there by a person who was asserting that the work happened. That single property is what makes the number usable:
- An invoice line can be traced to a specific entry on a specific day with a note attached.
- A client dispute is answered by showing the log, not by reconstructing a status history.
- A total that looks odd can be investigated, because each entry has an author.
- Nobody's productivity is being inferred from how fast they click a status dropdown.
This is why time logging in Buzzflo is manual entries rather than an inferred timer, and why a task's total is the sum of its logs and a project's hours are the sum across its tasks. Reports, invoices and profitability all read the same summed figure, so there is exactly one number and it has a provenance.
Making manual logging actually happen
The obvious objection is that people will not do it. Usually true, and usually fixable, because non-compliance almost always traces to one of three things.
It is too far away. If logging time means opening a different screen, the entry does not get made. Logging should sit on the task itself, where the person already is when they finish working.
The form asks too much. Hours, date, optional note. That is the whole thing. Every additional required field — activity type, billable flag, cost centre — measurably reduces the number of entries you get, and the data you lose is worth more than the categorisation you gain.
Nobody ever looks at it. If logged hours never appear in a conversation, people correctly conclude the entries do not matter. The fix is to actually use them: reference them in a project review, show a client the breakdown, use them when estimating the next job. Once the data visibly affects decisions, it gets entered.
A fourth factor helps more than people expect: log at the end of a work block rather than the end of the day. Reconstructing Tuesday on Friday afternoon produces guesses, and guesses are what you were trying to avoid.
When automatic tracking is fine
To be fair to the approach — there are cases where inferred time works.
If work is genuinely atomic and completed in one sitting, like a support ticket handled start to finish in a queue, the interval and the work are close enough. If you only need rough relative figures, not billable ones, precision matters less. And if the tool measures actual activity rather than board status, that is a different mechanism with different trade-offs, though it brings its own significant questions about monitoring.
What does not work is inferring billable hours from card status in a team whose work spans days and gets interrupted. That is most teams.
What to do differently on Monday
Take last month's hours for one project and pick the three largest entries. For each, ask the person who did the work whether that number is roughly right.
If they wince, you have your answer, and the fix is not to tune the timer — it is to stop inferring and start recording. Start with one project, log explicitly for a month, and compare the two totals. The gap is what you have been invoicing, estimating and evaluating people on.
If you want to see the rest of what sits on top of those hours, the product tour covers how logged time feeds reporting and invoicing.
time trackingproject management software
Buzzflo puts this into practice — see project & task management, take the product tour, or compare plans.