Naming Projects and Tasks So the Reports Make Sense

Oct 12, 2026

Nobody sets out to build a confusing time log. It happens one reasonable decision at a time: a project called “Website”, then “Website v2”, then “Acme website”, then “Acme — site (new)”. Six months later the report has four rows that might be the same thing and you are the only person who can say.

Naming is boring and it is where most of the future readability of your data is decided.

Name projects after the thing you report on

The test: could someone who was not in the room work out what this covers? “Redesign” fails. “Acme — website redesign 2027” passes.

A pattern that survives is client or area, then the deliverable, then a period if the work repeats:

• Acme — website redesign
• Acme — retainer 2027
• Internal — design system
• Internal — recruitment

The prefix does most of the work. It sorts alphabetically into sensible groups, it makes the dropdown scannable, and it means a report sorted by name is already grouped by client.

Avoid dates in names unless the work is periodic

Acme — website redesign (March) implies there is an April version. If the project is a one-off, the dates are in the entries already. If the work genuinely repeats on a cycle — a monthly retainer, a quarterly audit — put the period in the name, because you will want to compare one cycle with the next.

Name tasks after the activity, not the ticket

This is the most common mistake, and the most expensive. A task called Fix login bug #4821 produces a report with three hundred rows, each with one entry in it. You cannot learn anything from that, and the ticket system already has it.

Tasks should be the handful of verbs your work is made of: development, review, meeting, support, deployment, writing. Use the same set across projects wherever you can, because that is what lets you ask “how much of my year went into review?” across every client at once.

Put the ticket reference in the entry description, where it belongs and where it does not fragment your categories.

Keep the same words everywhere

Pick one of each pair and never use the other:

• meeting / call
• review / QA
• admin / overhead
• support / maintenance

It does not matter which you pick. It matters enormously that a report for one client uses the same word as the report for another, because otherwise every cross-project comparison needs a translation step you will do in your head, inconsistently.

Write the list down somewhere the team can see it. Five words in a shared note prevents a year of drift.

Lowercase, and one separator

Mixed capitalisation makes near-duplicates hard to spot: Acme - Website and Acme — website look the same in a dropdown and sort apart in a report. Pick lowercase after the prefix, pick one dash character, and stick to it.

Rename early, rename freely

A time tracker stores the link to the project, not a copy of the name, so renaming a project updates every historical entry and every report. There is no cost to fixing a bad name in month two. There is a real cost to living with it for two years because you assumed it was baked in.

Do a five-minute pass whenever you notice the list has grown: rename the outliers, archive the finished work, merge the accidental duplicates.

The archive is part of the convention

A finished project should leave the active list. It keeps its history and its reports, and it stops appearing in the picker where it can be selected by accident. A picker with eight live projects produces better data than one with forty, most of them dead, because the right choice is visible without scrolling.

You can see how projects, tasks and entries relate in the features overview, or try a naming scheme on the demo instance before applying it to real work.