Every consulting firm has tried three time-tracking tools and blamed the consultants each time. The timer was too fiddly, the app was too slow, the reminders were ignored. The tools get replaced; the problem stays, because the problem was never the timer. It is the shape of the entry, and the shape was decided by whoever set up the tool without asking what the entry was for.
The entry is for one question: was the project profitable? That question is answered by joining three records, the proposal that priced the work, the project that did it and the invoice that billed it. The time entry is the only record that touches all three, and most firms capture it in a shape that joins to none of them.
A time entry that can answer the question has five facts on it.
Who did the work, which gives it a cost, because people cost different amounts. When, which places it in a period for the books and against a milestone for the project. How long, which is the one everyone captures. Which project, which most firms capture too, although often as a client rather than a project, which is not the same thing when the client has three.
And which deliverable or task, meaning the line of the proposal the hour was spent on. This is the fact that joins the entry to the estimate, and it is the one almost nobody captures, because it is the one that requires the consultant to know how the proposal was structured and to choose.
Three facts out of five gives you hours per client. Five gives you cost per deliverable, which is the number the proposal estimated and the invoice billed, and the only number from which a margin can be computed without a reconstruction.
Without the deliverable, the firm knows it spent four hundred hours on a client and billed a fixed fee, and it knows the margin on the whole engagement after the fact. It does not know that the discovery phase came in at half the estimate and the integration phase at twice it, which is the fact that would have changed the next proposal. So the next proposal is priced from the last one's total margin, which was fine, and the integration phase is underpriced again. We described the firm-level version of this in the utilisation you cannot see: utilisation gets computed three ways and none of them says which work was profitable.
Without the cost per person, the firm knows the hours and not what they cost, so a project staffed by two seniors and a project staffed by two juniors look the same on the hours report and are not the same on the ledger.
And without the join to the invoice line, the unbilled hours are invisible. The consultant who quietly does an extra forty hours to get a deliverable right, which is the consultant you most want to keep, shows up nowhere until the exit interview.
That is the cost: proposals priced from the wrong number, projects staffed blind, and the best people's effort unrecorded. None of it is the timer.
Firms that bill fixed fees sometimes conclude that time tracking matters less, since the invoice does not depend on the hours. It matters more. On a fixed fee the hours are the whole margin, and a deliverable that overruns is paid for entirely by the firm. The join from entry to deliverable is the only way to know which fixed fees were profitable, and it is the only basis for pricing the next one. A fixed-fee firm with three-fact entries is pricing from memory.
Because the tool was set up from the tool's side. A time-tracking app ships with a project list and a timer, so the firm loads its clients as projects and starts the timer. The proposal lives in a document or the CRM, with its own structure of phases and deliverables. The invoice lives in the books, with its own lines. Nobody mapped the three structures to each other, so the entry cannot refer to a deliverable, because the deliverable does not exist in the time tool.
This is the same gap we described in professional services automation as three joins: proposal to project, project to time, time to invoice. The entry's shape is set by the joins the firm needs, and the joins were never designed, so the shape is whatever the app defaulted to.
Start from the proposal, not the tool. A proposal is a list of deliverables, each with an estimate in hours or days and a price. That list is the structure the project must inherit, so that each deliverable is a task or phase in the project tool. It is the structure the time entry must refer to, so that each hour lands on a deliverable. And it is the structure the invoice follows, so that each line bills a deliverable, fixed or by the hour.
Once the three share the structure, the entry has its five facts without the consultant doing anything new: the project and deliverable are picked from a list that already exists, the person and the date are known, and only the duration is typed. The join is designed in, and the profitability of each deliverable is a report rather than a reconstruction.
The tool matters less than the structure. Zoho Projects can hold it, with the bolt-ons we described in why Zoho Projects is not a PSA, and so can most of its competitors. What none of them does for you is the mapping to the proposal and the invoice, because those live in other systems, and carrying the structure across the three is integration work.
Consultants do under-record time, and no entry design fixes that entirely. But the complaint changes shape once the entry is right. When the entry asks for a deliverable, the consultant can see what the hour is being counted against and why it matters, and the firm can see within a week which deliverables are overrunning rather than at the end of the quarter which clients were. People record time against things that are visibly used. They stop recording against a timer that feeds a report nobody reads.
So fix the entry first, and then judge the discipline.
Take the last three projects and try to compute margin per deliverable from the time entries you have. If you cannot, the entries lack one of the five facts, and you now know which. Then restructure the project tool from the proposal, so the deliverables exist to be picked, and wire the invoice lines to them.
The wires between proposal, project and invoice are integration work by engineers, done under a guaranteed estimate. Discovery is no-risk: we take your last three projects and show you which facts the entries are missing, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
