Work Understanding: Workflow discovery
Objective. Read a discovered workflow as the flow observed from real signal, so a reader can present it as the honest alternative to a hand-drawn map while being clear it is inferred and needs customer confirmation.
Workflow discovery answers 'how does this process actually flow, as opposed to how we think it does?' It is the heart of the Sales story - observed flow, including the variants the whiteboard never captured.
See it in the demo
What this screen answers
The customer question is: what is the real shape of this process, discovered from how work actually moves? A Sales person opens it to contrast observed flow with a consultant's stale snapshot. A CSM opens it to check that the discovered flow matches the process in scope before building improvement work on it.
The task
Scope to the process and period, then read the discovered flow - the steps, the order, where the path branches. The key move is to present it as observed: 'this is how work moved, not how someone said it moves.' Then pair it with the customer's own understanding and note where the two differ, which is itself a finding.
How to read it
A discovered workflow is inferred from captured signal, not a definitive process map. The classic misread is presenting it as the authoritative truth of the process. It is a strong, evidence-based draft that must be confirmed with the customer - the method's value is that it surfaces reality and variants, but the customer still owns what 'correct' means. Read it as 'here is what we observed; does this match your process?'
Honest limits
Discovery does not prove the flow is complete or that every path was captured, and it does not define the intended process - the customer does. Confirm detection method and coverage with product, and confirm the process definition and intended path with the customer before conformance or improvement claims rest on it.
Interpretation check
A discovered workflow is inferred from signal, not a definitive map - present it as an evidence-based draft to confirm with the customer, never as the authoritative process truth.
In the field
KnackGlobal RCM: discovery exposes the real claim path including the detours a hand-drawn map misses, so the conversation moves from 'how we think claims flow' to 'how they actually flowed last month'.
Practical task
On the discovery view for one process, present the observed flow in two or three sentences, name one variant it surfaces, and write the question you would ask the customer to confirm or correct the discovered path.
Self-check
How is a discovered workflow different from a consultant's process map?
It is observed from how work actually moved, including real variants, and it keeps measuring - versus a manual, self-reported snapshot that is stale on delivery. But it is still inferred and needs customer confirmation.
A customer says the discovered flow is 'just wrong' in one place. How do you treat that?
As a finding, not a failure. The gap between observed flow and the customer's understanding is exactly what is worth discussing - and the customer owns what the intended path should be.
Can conformance be measured straight off the discovered flow?
Only once the reference path is confirmed with the customer. Discovery surfaces reality; the customer defines what counts as the intended process.
Verified vs demo. Screen is live in the demo at /#/discovery; exact controls, the discovered flow and figures are SME-validation-pending.