Effort and the three tiers

Finance → Profitability measures effort in three tiers, and you get whichever ones your data supports. Nothing here is switched on by a dropdown: Tier 1 needs nothing, Tier 2 appears once you enter a cost assumption, and Tier 3 is simply what logged time gives you. This is the page to read if your team does not log time on everything — and most do not.

Tier 1 — share of work. Zero assumptions.#

The Share of work column on the Clients grid is each client's slice of everything your team finished in the period, and Work vs revenue is that slice minus its slice of the revenue, in percentage points.

work items         = tickets closed + project tasks completed + client meetings held
                     (+ planner tasks completed, which only ever land in "not linked to any client")
share of work %    = client's work items ÷ all work items finished
revenue share %    = client's revenue ÷ all client revenue in the period
gap (points)       = share of work − revenue share

The three sources on screen, and the fourth behind them#

Every screen names three sources: "tickets closed, project tasks completed and client meetings held". Planner tasks are the fourth. They are counted, but a planner has no client, so they can never reach a client's row: they sit inside the work total and inside the not linked to any client line, and nowhere else.

Meetings are the ones that actually happened: cancelled meetings never happened and scheduled ones have not happened yet, so neither counts — booking next week's meeting does not spend this week's effort. Synced mailbox mail and imported history stay out too, the same rule the client touch metrics use.

Module switches under System → Features do not change the count. A ticket closed in July is a fact about July whether or not Service Desk is on today, so hiding a module never rewrites a stored month or an estimate — the switch hides navigation, pickers and drills, nothing more. A organization that never used Service Desk simply has no tickets to count.

Counted on completion, and organization-wide#

Two decisions shape everything above.

• On completion, not creation. Share of work is only meaningful beside share of revenue, and revenue is recognised in the month the work was worth something. A January kickoff's forty tasks belong against the months they are finished in, not against January's invoice. The cost of this: a six-month ticket lands all at once in its closing month, and a team that leaves tickets open under-reports its own effort. The What to fix tab counts open tickets for exactly that reason. Demand — tickets opened — is a separate, useful number and is available on the grid as its own Tickets opened column.
• Organization-wide, with no viewer scoping. A finance share that differs depending on who is looking is not a finance number. The total is the same for everyone who can open the page. Drilling into records still applies row-level access, and the drill says so when it had to leave records out.

Companies that paid nothing, and work not linked to any client#

Two lines sit above the grid whenever they are non-zero, and both are inside the work total every Share of work percentage is measured against:

• Companies that paid nothing — companies that finished work in the period but have no revenue, no expectation and no recorded cost, so they are not clients and get no grid row. A prospect who burned forty tickets before saying no is here. Show them → opens the list: company names and item counts only, never ticket subjects.
• Not linked to any client — work that belongs to no company at all: every planner task, plus tickets, tasks and meetings with no client on them. Nothing is ever inferred onto a client from a board, a contact or an assignee, because a guess with a real error rate inside a finance number is exactly the quiet wrongness this module exists to remove. The What to fix tab counts it and links to the tickets you can fix.

The two shares are measured against different totals on purpose#

The work total counts everything the team finished, including work for companies that paid nothing and work linked to no client. The revenue total can only count clients — the other work has no revenue to be a share of. So client shares of work sum to less than 100% while client revenue shares sum to exactly 100%.

Read the gap as direction and size, not as a balance. On a organization where a third of all finished work is not linked to any client, every client's share of work is held down against a revenue share that still sums to 100, and the gaps skew negative. Fixing the unlinked pile is what makes the comparison sharp. A "takes more than it pays" card gives the headline and one line of detail; the two underlying shares are in the get_profitability payload Prox reads. When a quarter or more of the counted work is not linked to any client, the Signals tab says so above the cards, so you can see how much of the picture is missing.

What Tier 1 does not claim#

It is not a cost, not a return figure and not hours. It counts work items, not effort — a one-line ticket and a two-day ticket weigh the same. It says nothing about work in progress: an item still open has contributed nothing yet. And it is not comparable between organizations — a team that closes tickets aggressively will always show more items than one that does not.

Unknown is not zero#

Work items are counted per month, and only for months rebuilt since counting shipped. A month with no count is left out of both the client's items and the work total, and the page says how many months it had to leave out. A Share of work cell reads —, never 0%, when the period has no counted work.

Tier 2 — estimated team cost. One assumption, visible and tunable.#

If you want a rough cost figure beside the share of work, set the assumptions under Assumed cost rate (shortcut) in the gear popover: Assumed cost per hour, for everyone ($) (empty by default; the placeholder reads Not set: no estimate shown — this one number stands in for per-role cost rates, and while it is the only cost you have, Return shows as an estimate), Hours per ticket (default 2), Hours per task (default 4), Hours per meeting (default 0.5), and How sure are these hours? Give or take (%) (0 to 75 in steps of 5, default 25). Its hint reads: "Every estimate is also shown as a low and a high, widened by this much. 0 turns the range off." The popover also says: "Changing these updates every month at once, past months included. Logged hours are different: they keep the cost rate they were logged at."

With no team cost rate set, nothing renders at all — no columns, no zeros, no dashes implying a computed nothing. Entering a rate is the whole feature switch. Clearing it turns everything off again.

estimated hours  = Σ over items with NO logged time of (the item's own estimate, else the assumption)
estimated cost   = estimated hours × what an hour of your team costs
estimated return = return − estimated cost

Two amber columns become available on the Clients grid: Est. team cost ~ (in the Columns menu) and Est. return ~ (shown by default). Both carry the same ~ the page uses for expected revenue, meaning "this contains a figure nobody recorded". The Est. team cost ~ tooltip carries the whole arithmetic and, when a range is set, ends "Give or take N%: between $low and $high." The Est. return ~ tooltip is shorter: "$X recorded return − $Y estimated team cost. An estimate: the Return column is unchanged by it." On the grid, only Est. team cost carries the range; the range on the return appears on the client page and in the PDF.

• Each item's own estimate wins. A ticket or task with estimated hours on it uses them. A meeting uses its real duration when it has a start and an end and is not an all-day entry. Only items that stated nothing fall back to the assumption, and the tooltip says how many did.
• The double-count guard. An item that carries any logged time is skipped entirely — its real cost is already in team cost, and estimating it again would charge the same work twice. The guard looks at all of an item's time, not just this month's, so a ticket worked in February and closed in March is not recorded in February and estimated again in March. A completed project task is also covered by time logged at project level in the same month: teams that log against the project rather than the task have that work in team cost already, and there is no fair way to say which tasks it paid for. This errs towards under-estimating, which is the safe direction for a figure printed beside a recorded return.
• It never touches Return. Not Return, not Return %, not $/hour earned, not hours with no cost rate, not the signals, not the Insights widgets, and not the Return line of the client PDF. It is its own column and its own PDF paragraph, always labelled.
• It is retroactive. It is priced when a report is read, not when a month is built, so changing the rate restates every month on screen at once — closed months included. That is a genuinely different contract from a logged hour, which keeps the cost rate it was logged at forever. The settings copy says so, and so does Prox before it changes it for you.
• Agreements get their share. A closed ticket or a project task whose ticket or project points at one of the client's agreements is estimated for that agreement too, so the Agreements tab and the client page's agreements table show an Est. return ~ column per agreement. Whatever points at no agreement (and every client meeting) stays on the client as "not assigned to an agreement", never split by guesswork.
• It is a range, not a point. The assumed hours carry the give-or-take percentage (25% unless you change it), so the estimated team cost, and on the client page and PDF the estimated return, are also shown as a low and a high: "(between $low and $high)". The range widens only the assumed hours; an item's own stated estimate is the team's number and is not widened. When even the high end of the estimated return is below zero, the client page adds, in red: "This client loses money even at the low end of the estimate." That client is losing money under every reasonable assumption.
• It says how far the return stretches. When the recorded return is positive, the client page adds: "The recorded return of $X covers up to Nh of team time at $R/h. The estimate says the work took about Mh." (The PDF says "…covers up to Nh of team time at this rate.") N is the return divided by the rate.
• It says what belongs to no agreement. When the client has agreements and some estimated work points at none of them, the client page adds: "Nh of that (~$X, N items) is not assigned to any agreement: tickets and projects with no agreement selected, and every client meeting. The rest is shown per agreement below."
• What it is not. It is not overhead absorption. It prices delivery work and nothing else: rent, software and payroll taxes are not in it, and that is Statements' job.

Prox and the estimate#

Prox reads the estimate through get_profitability: when a team cost rate is set, each client and agreement row carries effort_cost_estimate, estimated_hours, estimated_margin and estimated_margin_low / estimated_margin_high (the same figure at the low and high end of the give-or-take range), with the assumptions in effort_cost_assumptions. With no rate set those fields are absent, not zero. Prox can change the assumptions through manage_profitability_settings (assumed_hours_per_ticket, assumed_hours_per_task, assumed_hours_per_activity, assumed_team_cost_rate, and assumed_hours_range_pct from 0 to 75), and asks you to confirm first, because the change restates closed months. It is told to always call these figures estimates, and never to call any return on time figure profit.

These assumptions are deliberately separate from Resource Capacity's planning defaults. Those say how many hours an open item still needs; these say how many a finished one consumed. Changing one never changes the other, and the popover links across so you can keep them aligned if you want to.

Tier 3 — logged time#

Where hours exist with cost rates, team cost is recorded and Return is a real figure. Nothing about Tier 3 is affected by the other two: Tier 3 always wins over Tier 2 for the same item, and Tier 1 keeps counting items whether or not their hours were logged, because share of work and share of cost are different questions. Every rule is in Costs.

One definition, two surfaces#

The Share of work column and the Insights metric Share of Work by Client read the same two stored numbers and produce identical results by construction. The metric shows companies that paid nothing, work not linked to any client and — past the 25 busiest clients — Other clients as their own rows, so its shares add to 100%, and it requires ticket access whenever the Service Desk module is on. Because work is stored per month, the metric offers only whole-month periods and names the months it covered. See Profitability and Insights.

Worked example — a 728-item month, three clients#

June 2026. Your team finished 728 work items: 596 for clients, 45 for companies that paid nothing, 87 not linked to any client. Client revenue on the default setting totalled $320,000.00.

The arithmetic, for Rivera:

work items      12 tickets closed + 31 project tasks + 18 meetings = 61
share of work   61 ÷ 728                                           = 8.4%
revenue share   $9,900.00 ÷ $320,000.00                            = 3.1%
gap             8.4 − 3.1                                          = +5.3 points

And the two lines above the grid:

Companies that paid nothing   45 ÷ 728 = 6.2%   (9 companies with no revenue, expectation or cost)
Not linked to any client      87 ÷ 728 = 12.0%  (planner tasks, and items with no client)

Beckett & Rowe takes four times as much of the team as it produces of the revenue. Northwind takes a third as much. Neither statement needed a single timesheet.

Worked example — pricing the same month#

Assumptions: 2 h per ticket, 4 h per task, 0.5 h per meeting, at $65.00 per hour of your team's time, give or take 25%. Rivera's recorded return is the reference month's $2,868.70, with Include client expenses in return on time switched on (off, it would be $3,463.00).

Of Rivera's 61 finished items, 29 carry logged time and are excluded by the double-count guard. Of the 32 that remain, 15 stated their own hours.

4 tickets closed    × 2h                    =  8.0 h
9 tasks completed   × 4h                    = 36.0 h
4 meetings held     × 0.5h                  =  2.0 h
18.5 h from 15 items with their own estimate= 18.5 h
                                    total   = 64.5 h

estimated team cost   64.5 h × $65.00       = $4,192.50
estimated return      $2,868.70 − $4,192.50 = −$1,323.80

The range widens the 46.0 assumed hours by 25% (11.5 h) and leaves the 18.5 stated hours alone:

hours          53.0 h low … 76.0 h high
est. team cost $3,445.00 … $4,940.00     (grid tooltip: "Give or take 25%: between $3,445.00 and $4,940.00.")
est. return    −$2,071.30 … −$576.30     (client page: "between −$2,071.30 and −$576.30")
break-even     $2,868.70 ÷ $65.00 = 44.1 h

Rivera's recorded return is $2,868.70 (29.0%), because most of the work behind it was never priced. Put an assumption on the unpriced work and the account is $1,323.80 underwater. Both numbers are on the same row, and only the first one is used anywhere else in the product. The client page goes further: the high end of the estimated return is still negative, so it prints in red that Rivera loses money even at the low end of the estimate, and adds that the recorded return covers up to 44.1h of team time at $65.00/h while the estimate says the work took about 64.5h.

Worked example — what the conversation sounds like#

Rivera: 8.4% of the work, 3.1% of the revenue, +5.3 points. With a $6,000 retainer and 61 finished items in a month, that is roughly $98 of retainer per item your team completed.

That is a scope conversation, not an accusation. The useful questions are: is the retainer sized for this volume; is the work in scope; is the ticket load a symptom of something fixable; and would this account be healthy at 30 items a month. The signals engine will raise it for you automatically once the gap passes your limit — the default is 10 points, so Rivera at +5.3 does not raise a card while Beckett & Rowe at +12.3 does. See Signals.

If your team logs no time at all, this page is the one to read first — and the What to fix tab is the second, because the size of your "not linked to any client" line decides how sharp every number here can be.