Introducing time tracking to a team that has not had it is a change-management problem wearing a software problem's clothes. The tool takes an afternoon. The part that determines whether you get real numbers or polite fiction happens in the first two weeks, mostly in what you say and how you behave when the first awkward number appears.
Before you announce anything
Know what question you are trying to answer. "Better visibility" is not a reason, and teams can tell. Real reasons sound like: we do not know which projects make money; we keep underquoting the same kind of job; two people are clearly overloaded and we cannot prove it to ourselves. Pick the actual one. It determines what you need to track, and it is the thing you will say when someone asks why.
Decide what you will not do with the data. Write this down before you start, because you will be asked and an improvised answer sounds like an evasion. Ours would be: this is never an input to performance reviews, never compared between individuals in public, and never used to question someone's hours without talking to them first.
Settle the billable definitions. Travel, internal meetings, rework, quick questions. If you launch without answers, everyone invents their own and your first quarter of data is unusable.
The announcement
Say the real reason, in one paragraph, out loud, to everyone at once. Not by email, and not cascaded through team leads who will each explain it slightly differently.
Say what it is not for, explicitly. People will assume surveillance unless told otherwise, and even then some will assume it anyway — which is fair, because plenty of employers have done exactly that. The way you earn the benefit of the doubt is by behaving consistently for a few months, not by wording the email well.
Then say what will change for them. Ideally something honest and specific: fewer arguments about whether a project is going over, an actual basis for saying no to a client, resourcing decisions that stop being guesswork. If nothing changes for them, expect compliance rather than accuracy, and adjust your expectations of the data accordingly.
The first two weeks
Start narrower than you think. Client, project, duration, one line of description. No task codes, no sub-phases, no mandatory fields. You can add granularity later on the two projects where it changes a decision; you cannot recover from having asked for too much on day one, because the habit that forms is "invent something plausible".
Have one person answer questions. Not a channel — a person, named, whose job this is for a fortnight. Most questions are the same eight questions.
Log it yourself, visibly. If the founders are not tracking their own time, nobody believes it matters. This is the single most reliable predictor of whether a rollout takes.
Do not report on anything yet. Two weeks of data from people learning a new habit is noise, and the first person to be asked about their number in week two will tell everyone else, and the habit that forms is defensive.
Weeks three to twelve
Now start the weekly rhythm — a fifteen-minute look at burn against budget on live projects. Do it consistently and in the open. The value is less the review itself than that everyone knows it happens, which is what turns tracking from an administrative tax into something with a visible purpose.
Expect the first uncomfortable finding around week five. A favorite client will turn out to be barely profitable, or a project everyone thought was fine will be 40% over. How you handle that one moment sets the tone for years. If the response is to look for who is at fault, you have just taught everyone that honest logging is dangerous, and the numbers will quietly improve from that week onward while the business does not.
The right response is to treat it as the system working. It found something you did not know. That is what you bought.
The three mistakes that poison it
Backdating a rollout. Asking people to reconstruct last month to "get a baseline" starts the whole thing with an exercise in fiction, and signals that approximate numbers are acceptable.
Setting individual targets in month one. Or ever, really — but especially before you know what normal looks like in your agency.
Collecting data and never showing anyone anything. The fastest way to kill compliance is for people to spend six weeks logging carefully and never see a single thing come back. Share something monthly, even if it is only "here is where our time went and here is what surprised us".
What success looks like at ninety days
Not 100% compliance. Ninety days in, you want entries that arrive within a day of the work, categories used consistently enough that comparisons mean something, and at least one decision — a price changed, a scope re-agreed, a hire brought forward — that you can point at and say: we knew that because of this.
One decision is enough. It is what makes the next ninety days easy.