Accounting firms, IT service providers and MSPs, staffing, consulting, agencies. Assumes a time and billing system, a CRM, and a great deal of institutional memory in spreadsheets. Small firms belong here too, where the time tracker is used by some people some of the time, the accounting file is the system of record for everything, and the institutional memory is one person.
Firms with a time and billing system and a CRM.
Utilization and staffing forecast
In one line: Shows who is free in three weeks and which practice is about to be underwater, while there is still time to sell or hire.
Who uses it and when: the practice lead, weeks out instead of at month end, on a list of who is free and which practice is heading toward overload. It changes one decision: whether to push for more work or bring someone on now.
What it does not do: it will not sell the work or make the hire. It gives the lead enough runway to do either.
Usually needs building.
It depends on two things: actual hours, which are already captured through the time system, and a forecast, which is not data at all. The forecast lives in a spreadsheet per practice lead, rebuilt from scratch every month, so there is no record of what was forecast against what actually happened. Turning the forecast into a row per person per project per day, kept over time, is the project. The feature is what happens after it.
The pain: “Half my people are slammed and half are idle and I find out at the end of the month.”
What it runs on
- One row per: two separate records, and mixing them is the classic mistake. Planned: one row per person per day per project. Actual: one row per time entry. Keep them apart and compare them.
- Described by: employee, role and level, skill, client, project, task, date, office, billable flag, rate.
- Must agree across systems: employee, project, client, and the role and skill list. If the resourcing spreadsheet uses different project names than the time system, no comparison exists.
- History: you need history on role, level, and rate. Someone promoted mid-year has two different rates and both belong to real weeks of work.
Why it usually fails: the forecast is not data. It lives in a spreadsheet per practice lead and is rebuilt from scratch every month, so there is no record of what was forecast versus what happened. Time entered a week late finishes the job, because “current utilization” is always a week stale.
Scope creep detection on fixed-fee work
In one line: Flags the fixed-fee engagement that is drifting past its scope early enough to have the conversation with the client.
Who uses it and when: the engagement lead, while the work is still in flight, on a flag that hours are running past the original scope instead of a break-even surprise at the end. It changes one decision: whether to raise scope with the client now or absorb it quietly.
What it does not do: it will not have the conversation with the client. It flags the drift early enough for someone to.
Usually needs work.
It depends on time entries against the task, which are already captured. The budget field is the problem: it gets overwritten every time a change order lands, so by the end of the project the plan matches the actuals perfectly and the creep that actually happened is gone. Nothing new has to be built. The original scope and fee get frozen, and every amendment gets recorded as its own dated change instead of overwriting the total.
The pain: “Every fixed-fee job ends at exactly break-even, which tells me the scope grew and nobody said anything.”
What it runs on
- One row per: one time entry, against one project task or deliverable, on one day. The task has to be the same task the fee was built from.
- Described by: employee, project, task or deliverable, client, contract type, date, amendment reference.
- Must agree across systems: the task and deliverable list. The tasks in the proposal, the tasks in the project plan, and the tasks in the time system have to be one list, which is where nearly all of the work in this feature actually is.
- History: you need history and it is the entire point. The original scope and fee, frozen, plus every amendment with its date and what it changed.
Why it usually fails: the budget field is overwritten each time a change order lands. At the end of the project the plan matches the actuals perfectly, and the creep, which is the thing you wanted to see, has been erased by the accounting for it.
Service desk answer assistant
In one line: Drafts the response to an incoming ticket from what actually resolved the same problem before, at this client, on this equipment.
Who uses it and when: the tech answering the ticket, the moment it comes in, on a draft response built from what actually fixed this before at this client instead of a blank reply. It changes one decision: whether the tech starts from scratch or from a checked draft.
What it does not do: it will not solve a problem it has not seen resolved before. It drafts from history; a new problem still needs a person.
Usually needs building.
It depends on knowing what actually resolved a ticket, and that is not captured: resolution notes say “fixed” or “resolved per user,” which is not a record of what was done, only that something was. The category list was set once at go-live and never revised either, so it carries no real information. Capturing what was actually done, not just that it was closed, is the project. The feature is what happens after it.
The pain: “Our best tech answers the same question forty times a month and it is never written down.”
What it runs on
- One row per: one ticket event. One ticket, one status change or one reply, one timestamp. Not one row per ticket, because the time between events is where the SLA lives.
- Described by: client, site, end user, asset or device, technician, category, priority, contract and SLA, date opened, date resolved, resolution.
- Must agree across systems: client, site, asset, and category. The asset in the ticketing tool and the asset in the RMM or inventory tool have to be the same device.
- History: you need history on contract and SLA terms, and on asset assignment. Devices move between users and sites, and a ticket has to be read against the terms in force at the time.
Why it usually fails: resolution notes say “fixed” or “resolved per user,” so the record of what was actually done does not exist. And the category list was configured once at go-live and never revised, so everyone picks the first plausible item and the categories carry no information.
Small firms: a time tracker, an accounting file, and email.
True cost to serve by client
In one line: Shows what each client actually costs you to serve, including the hours nobody billed, so the renewal and rate conversations start from a number instead of a feeling.
Who uses it and when: whoever handles the renewal conversation, before it happens, on a real cost-to-serve number for that client instead of a feeling. It changes one decision: what rate goes into the renewal conversation.
What it does not do: it will not set the new rate. It gives the number the conversation starts from.
Usually needs work.
It depends on billable time, which is already tracked against the client and the day. Non-billable time is the gap: it never gets entered, because nothing happens if it is skipped, so the clients generating the most unbilled work look like the cheapest to serve. Entries made from memory at month end, rounded up to the hour, add more noise. Nothing new has to be built. Non-billable time starts getting logged the same way billable time already is.
The pain: “Two clients pay us the same and one of them takes three times the work, and I only know that because I can feel it.”
What it runs on
- One row per: one block of time, against one client and one piece of work, on one day. Billable and non-billable both. The non-billable ones are the whole point of the feature.
- Described by: person, client, engagement or project, type of work, billable flag, date, rate, and how the client is priced (hourly, retainer, fixed fee).
- Must agree across systems: the client and the engagement. The name on the invoice, the name in the time tracker, and the name on the folder the work lives in have to resolve to the same client, and one client with three brands is still one client.
- History: you need the retainer or fee as it was agreed, with the date each change took effect. A retainer that was quietly raised last spring makes every month before it look worse than it actually was.
Why it usually fails: non-billable time never gets entered, because nothing happens if you skip it. The clients that generate the most unbilled work then look like the cheapest ones to serve, which is exactly backwards, and the firm renews the wrong ones. The second cause: time is entered at the end of the month from memory, rounded up to the hour, and assigned to whichever client is easiest to remember. That does not just add noise. It moves hours off the quiet clients and onto the loud ones, so the error runs in one direction and never cancels out.