Value Leakage troubleshooting - when the numbers look wrong, incomplete or disputed
Objective. Give the CSM a symptom-driven guide to diagnosing Value Leakage problems - numbers that look wrong or missing, coverage gaps, and a customer disputing a figure - with the likely cause, the first checks to run, and when to escalate. Described at app-logic level, no invented error messages or UI paths.
Because Value Leakage produces money numbers, a wrong or disputed figure is a trust problem, not just a data problem. This guide works by symptom. For each, it names the likely cause in terms of the app's model - quantity, unit-cost, confidence, recoverable share, overlap, owner and recovery state - the first checks a CSM runs, and the point at which it escalates to the implementation specialist, product or the customer's finance. The recurring root cause is almost always an input, not the screen.
See it in the demo
Symptom - a figure looks wrong (too high or too low)
Likely cause: one of the three inputs is off. Too high usually means an un-agreed or inflated unit-cost rate, a theoretical-maximum quantity passed as measured, or confidence set too high for a directional finding. Too low usually means confidence correctly discounting a weakly-evidenced finding, or a recoverable share applied that the customer did not expect.
First checks a CSM runs: (1) Break the figure into quantity x unit-cost x confidence and sanity-check each term. (2) Confirm the unit-cost rate is the one agreed with the customer's finance. (3) Check whether the quantity is measured or estimated. (4) Check the confidence level against the evidence behind the finding. (5) Confirm the recoverable-share assumption is the agreed one, not the theoretical maximum.
When to escalate: if the rate source, the detection method, or how recoverable-share is modelled cannot be confirmed, escalate to the implementation specialist / product. If the dispute is about what the rate should be, that is a conversation with the customer's finance, not a fix in the tool.
Symptom - numbers missing or a category looks empty
Likely cause: a detection or upstream signal gap. Value Leakage sizes losses from signals the other apps produce, so a thin category usually means the upstream signal (available time, friction, rework, outcomes) is weak or not connected, or workflow detection is not surfacing findings in that area for this customer.
First checks a CSM runs: (1) Identify which upstream app's signal feeds the empty category and check that signal's coverage directly. (2) Confirm detection is actually running against the customer's data rather than seeded demo data. (3) Check whether the missing findings are genuinely absent or simply not yet detected/validated. (4) Distinguish 'no leak here' (a good result) from 'no data here' (a coverage gap).
When to escalate: detection coverage, which signals feed a category and how, and false-positive/negative behaviour are customer-specific and SME-validation-pending - escalate the mechanics to product. Never tell a customer 'you have no leakage here' when the real situation is 'we have no data here'; say which it is.
Symptom - coverage gaps and un-owned findings
Likely cause: the ledger is sized but not operationalised. Common gaps: high-value findings with no named owner (owned only by a vague team label), findings stuck at Open with no action, or whole categories not yet in anyone's review routine.
First checks a CSM runs: (1) On Attribution, list high-value findings and flag any that are un-owned or owned by a team label rather than a person. (2) On Recovery, count how many high-value findings are still Open with no movement. (3) Check owner coverage (share of high-value findings with a named owner) and time to verification as the two adoption measures. (4) Confirm a review cadence exists that actually moves findings forward.
When to escalate: if ownership cannot be mapped because the customer's org model or roles are unclear, that is a success-planning conversation with the customer, and how assignment maps to real roles is 'confirm with product'. A coverage gap is usually an adoption problem to fix with the customer, not a defect.
Symptom - a customer disputes a figure
Likely cause: almost always a capacity-vs-cash blend, an overlap, or a sized-vs-recovered confusion - not a calculation error.
First checks a CSM runs: (1) Establish exactly which number is disputed and on which screen. (2) Check whether capacity and cash have been blended into one total - if so, separate them, because they are never summed. (3) Check for overlap: are two findings claiming the same underlying hours? Overlapping findings cannot be added. (4) Check the recovery state: is the disputed value at Open (a sized opportunity) being read as recovered? Only Verified-with-evidence is recovered. (5) Re-walk the finding as quantity x unit-cost x confidence so the customer sees the inputs, not a black-box total.
When to escalate: if the dispute is about the rate or the recoverable-share assumption, resolve it with the customer's finance. If it is about the detection method or evidence standard, escalate to product. The strongest response to a dispute is the model's own honesty - show the inputs, the confidence discount and the capacity-vs-cash separation; the transparency is the defence.
Interpretation check
A wrong, missing or disputed leakage figure is almost always an input or a read, not a screen defect. Diagnose by breaking the figure into quantity x unit-cost x confidence, checking overlap and recovery state, and separating capacity from cash. Rate and recoverable-share disputes go to finance; detection and coverage mechanics go to product.
In the field
KnackGlobal (RCM, ~6,000 seats): a disputed figure on a flagship account is a credibility risk, so the diagnostic discipline - show the inputs, separate capacity from cash, check overlap, confirm only Verified-with-evidence is recovered - is what keeps a single challenged number from undermining the whole ROI case against the incumbent.
Practical task
Take a seeded demo finding and stage a dispute: write down the customer's complaint ('that number is too high'), then run the diagnostic - break it into quantity x unit-cost x confidence, check recovery state, check for a capacity-vs-cash blend and for overlap - and write the one-paragraph response you would give, ending with exactly what (if anything) you would escalate and to whom (finance vs product).
Self-check
A customer says a capacity figure is far too high. What do you check first?
Break it into quantity x unit-cost x confidence and sanity-check each term: confirm the unit-cost is the finance-agreed rate, check whether the quantity is measured or a theoretical maximum, and check confidence against the evidence. Also confirm the recoverable-share is the agreed one, not the maximum.
A whole category looks empty. How do you tell a real 'no leak' from a coverage gap?
Identify the upstream app's signal that feeds the category and check its coverage; confirm detection is running against the customer's own data; then decide whether findings are genuinely absent (a good result) or simply not detected/connected (a coverage gap). Never report 'no leakage' when the truth is 'no data'.
A disputed figure turns out to be capacity and cash added together. What is the fix and the rule?
Separate them into two lines; the rule is that recovered capacity and cash recovered are never summed, because freed capacity only becomes cash if the customer redeploys or removes it. The blend was the inflation, not a calculation error.
Two high-value findings seem to double the recovery. What is the likely cause and check?
Overlap - two findings describing the same underlying hours. Check whether they share the same quantity basis; overlapping findings cannot be summed, so the aggregate must be corrected before it is trusted.
When does a disputed figure leave the CSM's hands?
When the dispute is about the rate or recoverable-share assumption, it goes to the customer's finance; when it is about the detection method, coverage or evidence standard, it escalates to product. The CSM's own strongest move is to show the inputs and the capacity-vs-cash separation - transparency is the defence.
Verified vs demo. The screens, states and category magnitudes referenced here are demo-shown on seeded data (for example Capacity ~78 lakh, Process ~1.12 crore). Real detection coverage and method, rate sources, recoverable-share modelling and acceptable verification evidence are customer-specific and SME-validation-pending - diagnose at app-logic level and escalate mechanics to product; resolve rate and recoverable-share questions with the customer's finance.