Work Output - Troubleshooting and Escalation
Objective. Diagnose the three symptoms a CSM meets most on Work Output - numbers look wrong or missing, coverage gaps, and a customer disputing a figure - with the likely causes, the first checks to run and the escalation line, all at app-logic level and without inventing error messages or UI paths.
When a Work Output number is challenged, the fault is almost always upstream of the screen - in coverage, completion definitions, standards, the quality filter, the denominator or a blended value type - not in the display. This guide gives a CSM a repeatable diagnosis per symptom that works from the bottom of the time-to-outcome chain up, and a clear point at which the problem belongs to the implementation specialist or product rather than to interpretation.
See it in the demo
Symptom: numbers look wrong or missing
Likely causes: incomplete counted-work coverage (completed work happening off-system or not mapped); a loose or changed completion definition; a mismatched period or scope; a missing or stale source feed; the quality filter on or off unexpectedly; or a denominator problem (paid hours from Time and Activity wrong or absent) for per-hour figures.
First checks a CSM runs, bottom-up:
- Scope and period - confirm the filter is the one you think it is (team/process/client and the right period). Many 'wrong' numbers are a scope slip.
- Coverage - does counted work match what the customer says they complete? Look specifically for manual or off-system work that is not appearing.
- Completion definition - has it changed, or is it looser than assumed? A redefinition shifts totals.
- Quality filter - is the figure clean output or raw? A sudden jump often means the quality filter state differs from last time.
- Denominator - for output per paid hour or cost per unit, confirm the paid-hours figure is present and sane.
Escalate when a source cannot be mapped, a feed is structurally missing or stale, or completion logic needs a model change - that is implementation, not interpretation.
Symptom: coverage gaps
Coverage is the foundation symptom - if it is wrong, every other number is wrong, so treat a suspected gap as high priority.
Likely causes: a system of record not connected; a work type that is completed but not emitted as a countable event; manual or spreadsheet work the customer never mentioned; or a mapping that drops a category.
First checks:
- Ask the customer to state, per process, everything they consider completed work - then compare against what the transactions view actually shows.
- Identify categories present in the operation but absent or thin in the counts.
- Check whether a recent drop coincides with a source or integration change.
- Quantify the gap's likely size so you can judge whether derived figures are still usable with a caveat or must be withheld.
What to do: document the gap explicitly, caveat any figure that depends on the missing work, and do not present cost per clean unit or output per hour as the customer's real number until coverage is confirmed.
Escalate to the implementation specialist whenever closing the gap needs a new source connected, a mapping change, or a completion-definition change - never work around a structural gap with a plausible value.
Symptom: a customer disputes a figure
A dispute is usually a signal that an assumption behind the figure was never agreed - so treat it as a validation conversation, not a defence of the screen.
Likely causes and first checks:
- Disputed attainment - the standard was not agreed, or does not match complexity. Check whether the customer owns the standard and whether it is complexity-matched; if not, that is the real issue, not the attainment number.
- Disputed comparison / ranking - raw counts compared across different work type, complexity, period or tenure. Re-run the comparison normalised and with the quality filter; the dispute usually dissolves.
- Disputed cost - cost built on demo or default rates rather than the customer's model. Rebuild on their rates before discussing.
- Disputed 'savings' - a recoverable, capacity or projected figure read as realised cash. Reframe to the correct value type: opportunity is not collected cash, and a projection is not a measured result.
Resolution habit: name the denominator, the standard and the value type, rebuild on the customer's own basis, and show the corrected reading. If the figure is genuinely unsafe (coverage gap, unagreed standard), withdraw it rather than defend it.
Escalate to product or the implementation specialist if the dispute exposes a definitional or sourcing problem, or to the account's commercial owner if it touches a contractual value claim.
The general diagnosis order and the escalation line
For any Work Output problem, diagnose from the bottom of the time-to-outcome chain upward: coverage and completion definition first, then complexity and standards, then the quality filter, then the denominator, then the value type. The fault is almost always at the lowest unchecked link, and checking top-down wastes time.
The escalation line is simple: anything that is an interpretation or validation task stays with the CSM - scope, normalisation, standard agreement, value-type framing, rebuilding on the customer's rates. Anything that is a setup or model problem goes to the implementation specialist or product - unmappable sources, missing or stale feeds, completion or complexity logic changes, no trustworthy quality signal. Anything that touches a contractual or realised-value claim goes to the account's commercial owner. Never guess across that line, and never present a figure you have had to withdraw as though a workaround fixed it.
Interpretation check
A challenged Work Output figure is almost always an upstream problem, not a display one - diagnose coverage and completion definition first, then standards, quality filter, denominator and value type - and hold the line between a CSM validation task and an implementation, product or commercial escalation.
In the field
In a KnackGlobal-style account, the highest-stakes troubleshooting case is a disputed cost per clean claim: the fix is almost never the screen - it is confirming claim coverage, agreeing the clean-claim definition and rebuilding cost on the customer's rates, with any recoverable opportunity kept out of the realised figure.
Practical task
Take one seeded or real figure that a customer has questioned, run the bottom-up diagnosis in writing (scope, coverage, completion definition, standard, quality filter, denominator, value type), state the most likely cause, and decide explicitly whether it resolves as a CSM validation, an implementation escalation, or a commercial escalation - naming the owner you would hand it to.
Self-check
A customer says this month's output 'fell off a cliff' and the number looks implausibly low. What is your first check and why?
Scope and period, then coverage. A cliff is most often a scope slip or a source feed that stopped emitting completed work, not a real collapse. Confirm the filter and that counted work still matches what the customer completes before treating the drop as real.
A manager disputes a team's attainment as unfair. Where is the fault most likely to be?
In the standard - either it was never agreed by the customer or it does not match the work's complexity. The dispute is a validation conversation about the standard, not a defence of the attainment figure.
You find that a whole category of completed work is done in spreadsheets and never counted. Is this yours to fix?
No - closing it needs a source connected or a mapping change, which is an implementation-specialist escalation. Your job is to document the gap, caveat or withhold the affected figures, and not present cost per clean unit or output per hour as the real number until coverage is confirmed.
A customer disputes a 'savings' figure, saying the cash never appeared. How do you diagnose and resolve it?
Check which value type it is. If it is recoverable, capacity or a projection, the fault is that opportunity was presented as realised cash. Reframe to the correct type - opportunity is not collected cash and a projection is not a measured result - and only billed/collected are money in.
What is the diagnosis order for any Work Output problem, and why that order?
Bottom of the time-to-outcome chain up: coverage and completion definition, then complexity and standards, then quality filter, then denominator, then value type. The fault is almost always at the lowest unchecked link, so checking upward from the base finds it fastest.
Verified vs demo. The screens used for diagnosis are demo-shown on a seeded dataset; the customer's actual sources, completion definitions, standards, quality signal, paid-hours denominator and cost basis are confirm-with-product, and any structural fix (sources, mappings, model logic) is an implementation task, not something to infer from the demo.