Capture that people use
Timers, weekly grids, mobile entry, and agent-drafted timesheets built from calendar and activity for confirmation rather than recall.
Platform · operations
Almost all bad time data has the same origin: somebody rebuilding their week on Friday afternoon from memory and a calendar. Everything downstream — utilisation, project margin, work in progress, revenue recognition on fixed fee — inherits that inaccuracy, and no amount of reporting sophistication repairs it.
What it does
Timers, weekly grids, mobile entry, and agent-drafted timesheets built from calendar and activity for confirmation rather than recall.
Phases, tasks, milestones, and dependencies on a schedule that understands working calendars rather than raw elapsed days.
Salary or contractor cost, employer taxes, benefits, and an overhead allocation using a method you configure — applied per person rather than as a blended rate.
Unbilled time and cost as a real balance that ties to the ledger, rather than a schedule maintained alongside it that agrees by convention.
Allocation across the next eight to twelve weeks against a target per role, with over-commitment flagged before it becomes a delivery problem.
Time and materials, fixed fee by milestone, retainers with rollover, and capped engagements — invoiced from the records that track delivery.
When we measure time accuracy before an engagement, the pattern is consistent: entries are round numbers, they cluster on Friday, and they total suspiciously close to the expected week. That is not dishonesty — it is what recall produces when somebody reconstructs five days from memory.
The fix is not enforcement. Daily reminders and manager chasing produce entries that are timelier and no more accurate. What works is reducing the task from recall to confirmation: the agent proposes a week from calendar entries, document activity, and ticket updates, and the person corrects it.
A margin number built on billed rates tells you about pricing. A margin number built on loaded cost tells you about profitability, and the two frequently disagree about which engagements are worth having.
Loaded cost means salary, employer taxes, benefits, and an overhead allocation, applied per person rather than blended across the team — because a tier-one task done by a junior and a migration run by a senior engineer cost materially different amounts. Blending them makes both project margin and utilisation unreliable in opposite directions.
The allocation method is configurable and appears on every margin report, so the number is auditable rather than a black box somebody has to trust.
Unbilled work in progress is a real asset and in most service firms it lives in a spreadsheet that reconciles to the ledger monthly, approximately. Holding it as a subledger that ties to a control account continuously means the balance is defensible and the movement is explainable — which matters at year end and matters more if you are ever audited.
Limits
Sprint boards, story points, and developer workflow belong in Jira, Asana, or Linear. We read from them and add the cost and margin layer rather than asking teams to move.
Two years of reconstructed timesheets cannot be made accurate retrospectively. Margin on completed engagements will inherit whatever the data was, and we will say so rather than presenting it confidently.
We show allocation, capacity, and over-commitment. Automatically solving a staffing puzzle across constraints is a different product and we do not pretend to it.
Questions
A month of timesheets and a payroll summary is enough to show you margin on loaded cost rather than billed rates.