Value Leakage: Workflow Detection
Objective. Open Workflow Detection and explain how findings are surfaced from observed work, and why a detected finding is a candidate leak to validate, not a proven result.
This screen answers 'where do the leakage findings come from?' It shows detection surfacing candidate leaks from observed workflows, which is the input to the whole ledger.
See it in the demo
What this screen answers
Before a customer trusts any leak number, they ask 'how did you find this - did a person guess it, or did something observe it?' Workflow Detection answers that: it shows leaks being surfaced from observed work patterns rather than from a workshop estimate. A Sales or CSM person opens it to establish provenance - that findings are detected and evidenced, which is what separates this ledger from a consultant's slide.
The task
Open Workflow Detection at the cited route. Read how findings are surfaced and grouped, and pick one detected finding to trace from detection through to its category and value. Be ready to explain that detection produces a candidate leak which then gets sized by quantity x unit-cost x confidence and routed to a category. Do not overstate the detection method - describe it at the level of 'surfaced from observed work' and confirm the exact mechanism with product.
How to read it
A detected finding is a candidate, not a conclusion. Detection tells you something was observed worth sizing; the confidence term then discounts how certain that finding is, and a CSM still validates the inputs before it is trusted. The misread to avoid: treating 'detected automatically' as 'proven and recoverable'. Detection improves provenance and reduces guesswork, but it does not by itself establish the rate, the recoverable share, or that two findings are not describing the same hours.
Honest limits
This screen shows that detection exists and surfaces findings on seeded demo data. It does not prove the detection method, coverage or accuracy for a real customer. The exact signals detection uses, how much of the operation it covers, and its false-positive behaviour are customer-specific - confirm with product. Detection is the start of the ledger, not the end: sizing, ownership and verified recovery still have to happen.
Interpretation check
A detected finding is a candidate leak to validate and size, not a proven or recovered result; automatic detection improves provenance but does not establish the rate, the recoverable share, overlap, or that any cash was recovered.
Practical task
Open Workflow Detection, pick one detected finding, and write a two-line note: what was detected and in which category it lands, then what you would still validate (rate, recoverable share, overlap, owner) before trusting its value.
Self-check
Why does Workflow Detection matter to a sceptical buyer?
It establishes provenance - findings are surfaced from observed work rather than guessed in a workshop. That is what separates this ledger from an inflated consultant estimate, so it is a credibility screen, not just a feature.
Is a detected finding ready to quote to finance?
No. Detection produces a candidate that still needs sizing by quantity x unit-cost x confidence and validation of rate, recoverable share, overlap and owner before any figure is quoted.
What is the risk of saying 'the system automatically detects all our leakage'?
It overstates coverage and accuracy. Detection method, coverage and false-positive behaviour are customer-specific and SME-validation-pending; claim 'surfaced from observed work' and confirm the mechanism with product.
Where does a detected finding go next?
It is sized by the value formula, routed to one of the six categories, ranked in Top value leaks, given an owner in Attribution and tracked on Recovery - detection is the first step of that chain.
Verified vs demo. Screen is live in the demo at /#/workflow; exact controls and figures are SME-validation-pending.