Value Leakage data and setup - what the app needs to produce an honest number
Objective. Describe, at app-logic level, the data and signals Value Leakage depends on, the setup and integrations required, its dependencies on the other apps, and what a CSM validates before trusting any leak figure. Make clear that every number is only as honest as its three inputs - quantity, unit-cost and confidence - and its recoverable-share and overlap assumptions.
Value Leakage is a money layer that sits on top of the other apps. It does not generate raw observation; it takes observed work and outcomes, sizes the loss as quantity x unit-cost x confidence, routes it to one of six categories, and tracks recovery. This reference explains what feeds that model, what must be configured and agreed before the numbers are trustworthy, and exactly what a CSM checks before a figure leaves the room. Specific integration mechanics are described at logic level - confirm the exact connectors and methods with product.
See it in the demo
The data and signals it depends on
Every leakage finding is built from three inputs, and the data behind each must be sound:
- Quantity - the measured volume of the leak: idle or available hours, process touches, system wait time, rework units, missed-automation volume, or outcome units such as denials or unbilled work. This is the signal the app most depends on, and it should be measured rather than estimated wherever possible.
- Unit-cost - the agreed money per unit: a loaded hourly rate, a cost per claim, a cost per unit of rework. This is not observed by the app; it is a rate the customer's finance must agree.
- Confidence - a deliberate discount for how certain the finding is. A well-evidenced, detected finding counts near full; a directional one is marked down. This is the term that stops the number inflating.
Findings are surfaced by workflow detection from observed work patterns, then sized and routed to one of six categories - capacity, process, system, quality, AI and outcome. Detection improves provenance but does not by itself establish the rate, the recoverable share, or that two findings are not describing the same hours.
Setup, configuration and integrations required
At app-logic level the app needs four things configured before its numbers are trustworthy; confirm the exact mechanism, connectors and controls with product for a given customer.
- Rate configuration - the unit-costs (loaded hourly rate, cost per claim or per unit) agreed with the customer's finance and entered as the money-per-unit basis. Wrong or un-agreed rates make every figure wrong in the same direction.
- Recoverable-share assumptions - how much of a theoretical leak is realistically recoverable, so the ledger sizes recoverable value rather than a theoretical maximum.
- Category routing and confidence - how detected findings map to the six categories and how confidence is assigned, so soft findings are discounted rather than hidden.
- Detection and source feeds - the connections that let workflow detection surface findings from observed work and outcomes. The exact signals, coverage and false-positive behaviour are customer-specific - confirm with product.
Treat every integration specific (which systems, which fields, which connector) as 'confirm with product'. Describe the requirement at logic level - 'the app needs agreed rates, a recoverable-share basis, category routing and detection feeds' - and escalate the mechanics to the implementation specialist.
Dependencies on the other apps
Value Leakage is the money layer: the other apps find the problem, this one puts a confidence-discounted money value on it and tracks recovery. Its findings depend on signals those apps produce:
- Capacity leakage draws on available-time and utilisation signals of the kind Time and Activity surfaces - absent vs available vs overtime hours.
- Process and system leakage draw on friction, waiting and rework signals of the kind Work Understanding surfaces.
- Quality leakage draws on rework and quality signals of the kind the Work Output and Quality apps surface.
- Outcome leakage draws on business-outcome signals of the kind RCM Operations surfaces - denials, backlog, unbilled or uncollected value.
Because of this, a leakage number inherits the definitions and coverage of its upstream signal. If the upstream completion definition, source coverage or classification is weak, the leakage figure built on it is weak too. Validate the upstream signal, not just the leakage screen.
What a CSM validates, and what to escalate
Before trusting any leak number, a CSM validates five inputs - the number is only as honest as these:
- Time basis - is the quantity measured or estimated? Prefer measured; mark estimated findings down via confidence.
- Rates - are the unit-costs agreed with the customer's finance, not assumed?
- Recoverable share - how much of the theoretical leak is realistically recoverable, not the theoretical maximum?
- Overlap - are two findings double-counting the same underlying hours? Overlapping findings cannot simply be summed.
- Owner - is a real, accountable person attached, so the finding is a plan and not a statistic?
And always keep recovered capacity and cash recovered on separate lines - never summed.
Escalate to the implementation specialist / product, not to guesswork: the exact rate sources and how they are entered, the detection method and its coverage and accuracy, how recoverable-share is modelled, and anything touching the customer's own finance definitions or org model. Security, compliance and contractual specifics always escalate. Where you cannot confirm, state the figure as a seeded demo example and say 'confirm with product and the customer's finance'.
Interpretation check
A leakage figure is only as honest as its inputs - measured quantity, finance-agreed rate, realistic recoverable share, checked overlap and a named owner. Detection surfaces candidates; it does not by itself establish the rate or recoverable share. Capacity and cash stay on separate lines.
In the field
KnackGlobal (RCM, ~6,000 seats): at this scale a wrong or un-agreed per-claim rate swings the whole ledger, so the setup discipline - finance-agreed rates, a realistic recoverable share, validated upstream outcome signals - is what makes the number defensible enough to displace an incumbent on hard ROI.
Practical task
For one finding on the demo, write a setup-readiness note: name its quantity source (measured or estimated), the unit-cost rate and who must agree it, the recoverable-share assumption, the upstream app whose signal it depends on, and the one integration or detection detail you would escalate to the implementation specialist as 'confirm with product'. Finish by stating its value as quantity x unit-cost x confidence and label it capacity or cash.
Self-check
What three inputs build every finding, and which one does the app not observe?
Quantity (measured volume), unit-cost (money per unit) and confidence (certainty discount). The app does not observe unit-cost - that is a rate the customer's finance must agree. Quantity should be measured, and confidence discounts uncertain findings so the number does not inflate.
Why does a leakage number inherit the trustworthiness of an upstream app's signal?
Value Leakage sizes losses from signals the other apps produce - available time, friction, rework, outcomes. If the upstream completion definition, coverage or classification is weak, the leakage figure built on it is weak. Validate the upstream signal, not just the leakage screen.
A CSM is handed a big capacity leakage figure for a new customer. What five inputs do they validate first?
Time basis (measured vs estimated quantity), rates (agreed with finance), recoverable share (realistic, not theoretical maximum), overlap (no double-counting of the same hours), and owner (a real accountable person). The figure is only as honest as these.
Which setup items must be agreed with the customer's finance rather than assumed by the app?
The unit-cost rates (loaded hourly rate, cost per claim or unit) and the recoverable-share assumptions. Un-agreed rates make every figure wrong in the same direction, which is why they are a finance agreement, not a default.
What does a CSM escalate rather than guess?
Exact rate sources and entry, the detection method and its coverage and accuracy, how recoverable-share is modelled, and anything touching the customer's finance definitions, org model, security, compliance or contract. Where it cannot be confirmed, state it as a seeded demo example and 'confirm with product'.
Verified vs demo. The six-category model, workflow detection, the quantity x unit-cost x confidence sizing and the recovery states are demo-shown on seeded data with illustrative magnitudes (for example Capacity ~78 lakh, Process ~1.12 crore). The exact connectors, detection signals and coverage, how rates and recoverable-share are entered, and the customer's finance and org definitions are customer-specific and not demo-provable - confirm with product and the customer's finance.