Blog · June 11, 2026 · ~9 min read
Time tracking for consultants: why availability-based billing needs a different tracking system
Consultants on availability-based retainers have a time tracking problem that no standard tracker was designed to solve. The tracker records hours. The client needs to see availability — what’s been used, what remains, when the cycle resets. These are structurally different information shapes, and building only the first one is why your retainer clients still email you asking how many hours they have left.
This post explains why standard time trackers fail consultant retainers at the client-visibility layer, what a two-layer tracking setup looks like, and how to build the second layer without replacing the tools you already use.
The consultant’s tracking problem is not a logging problem
Ask a consultant how they track time and most will name a tool: Toggl, Harvest, Clockify, a spreadsheet, their calendar. These tools solve the logging job competently. They record when work happened, how long it took, which client it was for, and sometimes what project or task it belonged to. That record is what the consultant uses to verify the month’s hours, build their invoice, and answer questions about where time went if asked.
The logging job is well-served. The problem is that there is a second job the tracker does not do — and most consultants don’t notice it’s missing until a client emails them asking about their balance.
The second job is client-side availability visibility: the ongoing, cycle-aware picture of how much of the reserved capacity has been used, how much remains, and when the cycle resets. That picture is not a report of work done. It’s a running balance against a pre-agreed cap, and the format that answers a client’s question in three seconds looks nothing like a time report.
A time report shows: dates, task names, hours per entry, total hours in a date range. A client glancing at this to find their remaining balance has to do arithmetic — total the entries, subtract from the cap, confirm the entries are only from this billing cycle (not last month’s entries that happened to fall in the date range). It takes two minutes and requires knowing the cap and cycle dates. Most clients don’t do it. They email instead.
Why availability-based billing creates a unique visibility obligation
Project-based and hourly billing don’t produce this problem. In a project engagement, the client has bought a defined deliverable. The project is either done or not done; there’s no cap to track mid-cycle. In pure hourly billing, the client pays for hours consumed after the fact; the invoice documents what happened and there’s nothing to self-serve check in between invoices.
Availability-based billing is different because the client has pre-paid for a reserved capacity — a specific number of hours per cycle — and that reservation is what they’re paying for, not just the hours that get consumed. As explained in the anatomy of a consultant retainer fee structure, the availability retainer model is built on the premise that the client has reserved the consultant’s bandwidth. The hours cap is the contractual shape of that reservation.
Because there’s a cap, there’s always a remaining balance. Because there’s a cycle, that balance resets. Because the client knows they’re paying a fixed fee per month, they naturally want to know whether they’re getting value from it — which means knowing how much of the reserved capacity they’re using. These questions are structurally inherent to the arrangement, not symptoms of a difficult client or poor communication. Any client on a monthly hours-cap retainer will eventually ask the balance question. The only variable is whether they ask by email or find the answer themselves.
What standard trackers actually give clients
Most time trackers offer some form of sharing. Toggl has shared reports. Harvest has Scheduled Reports and a shareable Project Budget URL. Clockify has a Standard-tier Client access feature. These are real features — but they’re all shaped for the time tracker’s native model, which is date-range-based reporting, not billing-cycle-based availability tracking.
The mismatch shows up in three specific ways:
Date range vs. billing cycle. A shared time report defaults to a date range the consultant configures. If the billing cycle runs from the 1st to the 31st, the consultant has to set the report to match that window. If the cycle resets mid-month or on a rolling 30-day basis, the report’s date range has to be reconfigured each cycle. Any client bookmarking the URL gets a link that shows the wrong time window a month later.
Hours worked vs. hours remaining. Time tracker reports lead with hours worked — how many hours were logged, on what dates, against which tasks. The client’s question is the inverse: how many hours are left. The client has to do the subtraction. For a 20-hour cap client who can see they’ve logged 14.5 hours, finding “5.5 hours remain” requires knowing the cap number and doing arithmetic. That’s not a three-second glance — it’s a calculation.
Static snapshot vs. live balance. Even well-configured shared reports are point-in-time snapshots that require the client to reload and re-read on each visit. The client can’t tell whether the report reflects the current state or a state from last week without checking the dates. A live balance that updates automatically as the consultant logs time removes this uncertainty entirely.
The result is that even consultants who use good time tracking tools and do share access with their clients still receive the balance question by email. The tool sharing doesn’t retire the email loop because the shared output is the wrong shape for the question. As the two-job framework for time tracking explains, logging time and making time visible to clients are genuinely separate jobs, and doing one well doesn’t automatically solve the other.
The two-layer setup consultant retainers actually need
A tracking setup that handles both jobs has two layers:
Layer 1 — time tracker for the record. This is the consultant’s internal logging system: Toggl, Harvest, Clockify, a detailed spreadsheet, or any tool that captures time entries with dates, task descriptions, and hours. The audience is the consultant. The output is the record that supports billing, answers dispute questions, and informs future cap sizing. This layer does not need to be legible to clients in real time — it needs to be accurate and complete for the consultant.
Layer 2 — cycle-aware visibility URL for the client. This is the client-facing layer that answers the balance question without email. The output is a URL the consultant sends once and the client bookmarks. Opening it shows: hours used this cycle, hours remaining, cycle reset date, and a plain-language work log. The audience is the client. The format is a progress bar and a log, not a date-range report. This layer does not need to capture the granular time entries the consultant uses for billing — it needs to show the client what they need to know at a glance.
The two layers have different audiences, different formats, and different update cadences. Trying to make Layer 1 serve both audiences — keeping the time tracker exactly as it is but sharing it with the client — is what produces the mismatch described above. The tracker is optimized for Layer 1. Building a separate Layer 2 is the fix.
What the client-facing layer needs to show
The four pieces of information a retainer client needs from the visibility layer are well-defined once you think about what question they’re actually trying to answer. The question is almost always some variant of: “Do I still have hours this month? How many? When do they reset?” The answer requires four inputs:
1. Hours used this cycle. Not total hours ever logged. Not hours by project. Just: how many of the reserved hours have been consumed since the last reset. A number, not a list.
2. Hours remaining. The cap minus hours used. This is the number the client is actually asking about. It should be the most prominent element on the page — larger text, a progress bar, something that communicates “you have X hours left” without requiring the client to do subtraction.
3. Cycle reset date. When does the cap refresh? This is the second most common question after the balance itself. A client who knows they have 2 hours remaining but the cycle resets in 4 days makes different decisions than one who has 2 hours remaining with 22 days left in the cycle.
4. Work log for this cycle. A plain-language record of what was done and how many hours each item took. Not ticket IDs, not decimal hours, not project codes — dates, plain-language descriptions, and hours in whole or half numbers. The work log is how clients connect the hours balance to actual work. It answers the implicit follow-up question: “OK, 12 of 20 hours used — what did that 12 hours go into?”
This is the structure described in the anatomy of the client hours dashboard: four pieces of information, optimized for a three-second glance, accessible from a bookmarked URL without login. A client who can answer their own balance question from a bookmark never sends the status email.
Why most consultants only build Layer 1
The reason most consultants never build the client-visibility layer is not that they don’t know their clients want it. It’s that there is no natural moment where the gap becomes visible until a client asks and the consultant answers by sharing their time tracker, discovers it doesn’t quite work for this purpose, and then manually sends a PDF instead.
The manual PDF is the most common substitute for Layer 2. The consultant exports their time tracker data at the end of the cycle, formats it into a summary email, and sends it as a monthly update. This works once. It stops working when the client asks about their balance mid-cycle, when the consultant forgets to send the monthly update, or when the client’s question arrives on a Tuesday afternoon and the last update was two weeks ago.
A monthly PDF is not a live balance. It’s a one-shot document that answers the question at a specific moment and becomes stale immediately. The client who bookmarks it gets the wrong numbers the next time they open it. The email loop continues because the PDF is formatted like a record (consultant-audience, monthly cadence) rather than a balance (client-audience, always current).
The second common substitute is a shared spreadsheet. The consultant maintains a running hours log in a Google Sheet, shares view access with the client, and tells them to check it. This is closer to Layer 2 than a PDF — it’s live and client-accessible — but it requires the consultant to maintain the formula that calculates remaining hours, to remember to update it promptly after logging time, and to ensure the column structure is readable to someone who didn’t build it. Shared spreadsheets work until the consultant stops updating them consistently. Most are accurate for the first one or two cycles and then fall three to five days behind by cycle four or five, which is when clients stop trusting them and revert to email.
Choosing tools for each layer
The Layer 1 choice — which time tracker to use for the consultant’s internal records — is largely a matter of preference and workflow. Toggl Track, Harvest, Clockify, and Everhour are all competent at the logging job. If you already use one, keep it. Layer 1 is not broken; it doesn’t need to change.
The Layer 2 choice depends on how you want to handle the update workflow. There are two approaches:
CSV-based update. Export a time report from your Layer 1 tracker (most trackers can export CSV filtered by client and date range), import it into a Layer 2 tool, and the balance URL updates automatically from the import. This keeps Layer 1 as the single source of truth for time entries and removes the double-entry problem. The tradeoff is that the Layer 2 URL is only as current as the last import.
Direct-entry update. Log time directly in the Layer 2 tool instead of (or in addition to) Layer 1. The balance URL updates immediately as entries are added. The tradeoff is maintaining two logging workflows if Layer 1 is still used for billing.
For most solo consultants, the CSV approach is the better starting point: it works with whatever tracker you already use, the import takes two minutes, and “two minutes once a week” is maintainable in a way that “two logging workflows forever” often isn’t.
What changes when the client has a Layer 2 URL
The first change is the obvious one: the status emails stop. Clients who can check their own balance stop asking about it. This is the direct effect, and for consultants managing three or more active retainers, eliminating those check-in emails recovers a meaningful amount of time each month.
The second change is less obvious but more significant: the client’s relationship with their hours cap shifts. A client who can see their balance at any time starts managing their requests differently. They know when they’re approaching the cap before they hit it. They can decide whether a request fits in the current cycle or should wait until the reset. They see the work log entries accumulating and understand where the hours are going without asking. The retainer becomes a tool they actively use rather than a payment they make and occasionally question.
The third change affects renewal and upsell conversations. A client who has been watching their utilization for six months has formed their own view of whether the cap is right-sized. If they’ve consistently been at 85–90% utilization, they’ve already arrived at “we might need more hours” before the consultant raises it. If they’ve been at 60% utilization, they’ve seen the data too and the right-sizing conversation happens based on evidence rather than assumptions. The balance URL converts usage from something the consultant tracks internally into something both parties track together.
The retainer arrangement works better when the client understands what they’re getting. An hours-remaining URL is the simplest possible implementation of that understanding — one number, always current, no login, no questions needed. Send it once, on day one, before any hours are logged, when the client is learning the format with no stakes attached. The question “how many hours do I have left?” is the easiest question to answer when the answer is already bookmarked.