Every question you'll ever want answered about profitability depends on a hierarchy decision you make in week one.
Get the client-project hierarchy right and every report downstream is free; get it wrong and no amount of reporting effort recovers it. The rule is short: clients are the entity that pays, projects belong to exactly one client, and both are selected from a list rather than typed. Almost every messy analytics situation in a small services business traces back to breaking one of those three.
The structure that works for almost every small services business:
| Client | The organisation that receives an invoice. One record, one code, however many projects it has. |
|---|---|
| Project | A named body of work belonging to exactly one client. Time is logged against this. |
| Task entry | An individual piece of work, logged daily, carrying its project (and therefore its client). |
Teams frequently want a third level — phases, workstreams, sub-projects. Before you add it, ask what decision it changes. Usually the answer is none: you already know the project's total cost and who worked on it. What the third level reliably adds is one more field on every task entry, which reduces the rate at which the log gets filled in at all. If you genuinely need phases, express them as separate projects ("Website — Phase 2") rather than a new hierarchy level.
If your task log lets people type a project name, you do not have project data. You have text. Within a few months you will have "Rajvi SEO", "Rajvi Seo", "rajvi-seo", "Rajvi SEO & Marketing" and "Rajvi (SEO)" — five distinct values to a database, one project to a human, and no report that adds them up.
The fix is a picklist: projects are created deliberately, then selected. This costs one small moment of friction when a genuinely new project starts, and saves the entire reporting layer. Combine it with:
Free-typed project names are the single most common cause of "we can't report on that" in small services businesses. The damage is invisible for months and then permanent.
Keep it short and mechanical:
Three patterns cover nearly everything:
That last point matters more than it sounds. If 20% of your team's time is internal and untracked, every client project looks 20% more profitable than it is. The full calculation is here.
If you already have months of free-typed entries, the data is recoverable — it is a one-time mapping exercise, not a rebuild:
Step 5 is the one people skip. Cleaning historical data without preventing new mess is a treadmill.
With clients and projects clean, these all become queries rather than projects in themselves:
| Client | The organisation that receives an invoice — one record, one code |
|---|---|
| Project | A named body of work belonging to exactly one client |
| Levels needed | Two. A third level rarely changes a decision and reduces log compliance |
| Hard rule | Projects are selected from a list, never free-typed |
| Uniqueness | Project names unique per client, reusable across different clients |
| Retainer pattern | One project per client per period — never one per deliverable |
| Internal time | Create an internal client, or client profitability is overstated |
Use two levels. A client is the organisation that receives the invoice, and a project is a named body of work belonging to exactly one client. Daily task entries carry the project, and therefore inherit the client. A third level such as sub-projects usually adds admin without changing any decision you make.
Because free text produces multiple spellings of the same project — different capitalisation, punctuation and abbreviations — which a database treats as distinct values. Reports then split one project across several rows and no total is correct. Selecting from a picklist scoped to the chosen client prevents this at the point of entry.
Create one project per client per period, such as a quarter, half-year or year, rather than one project per deliverable. Per-deliverable projects multiply into hundreds of records within a couple of years and make comparison impossible. A period boundary lets you compare utilisation across periods.
Create an internal client representing your own company and log admin, business development, training and similar work against projects under it. If internal time is not captured, it either disappears from the record or gets attributed to a client project, and every profitability figure you produce is overstated as a result.
List every distinct project string with its entry count, create proper client and project records, map each old string to a real project, apply the mapping in bulk while retaining the original text for audit, and then switch to a picklist immediately. Skipping that final step means repeating the exercise next year.
No. Mark them closed instead. Closed projects still hold the history you need for estimating similar future work, for profitability comparisons, and for answering questions about past invoices. Deleting them removes exactly the reference data that makes future estimates better.
Merik models clients and projects the way this article describes: client records with auto-derived codes, projects belonging to one client and unique per client, and task entries that select a project rather than typing one. Bulk edit and delete are available for the housekeeping that inevitably comes up.
For teams arriving with a messy history, there is a dedicated repair screen — Fix Project Names — that attaches historical, free-typed project names on task entries to real project records: it guesses the mapping, lets you review it, and applies it per-row or in bulk, retaining the original value. Once clean, Project Intelligence rolls everything up: stage stepper, contributor avatars, sparklines and per-project drill-down. See the client and project modules, the feature list, or how it works.
Turn the hours your team already logs into a per-project margin.
From line-item quote to sent invoice without retyping anything.
Per-client structure, what to check, who gets the alert, and pricing the retainer around it.