Work Understanding: Work detection
Objective. Read the work detection view to see how raw sessions are turned into recognised work with a confidence, so a reader can explain the detection method and judge whether a finding is trustworthy enough to act on.
Detection answers 'how do we know this activity was this piece of work, and how confident are we?' It is the trust foundation - every downstream screen inherits the confidence set here.
See it in the demo
What this screen answers
The customer question is: how is observed activity recognised as specific work, and how sure are we? A Sales person uses this to show the method honestly - detection, not magic. A CSM uses it to review confidence and taxonomy mapping before trusting any friction, waiting or rework finding built on top of it.
The task
Scope to the process and period, then inspect how sessions are detected and classified into work, and where confidence sits. The CSM move is to confirm that detected work is mapped to the right process taxonomy and that confidence and coverage are adequate for the process in scope. Low-confidence detection means every finding downstream is a lead, not a decision.
How to read it
Detection is inference from captured signal - a labelled session is a best estimate with a confidence, not a certified fact. The classic misread is treating a detected work item as ground truth and skipping the confidence. Read confidence first: high-confidence detection on good coverage can anchor a finding; low-confidence or thin coverage means treat everything built on it as provisional.
Honest limits
Detection does not guarantee every piece of work was captured or correctly labelled, and it does not prove the taxonomy matches the customer's definitions. Confirm the actual detection method, confidence thresholds and coverage for the customer's processes with product - the demo shows the method on seeded data.
Interpretation check
Detected work is inferred with a confidence, not certified fact - check confidence and coverage here before trusting any downstream finding.
Practical task
On the detection view for one process, write a short note stating the confidence level you see and whether it is adequate to act on, plus one thing you would confirm with product about the detection method.
Self-check
Why is work detection the trust foundation for the whole app?
Every downstream screen (step time, friction, rework) is built on detected work. If detection confidence or coverage is weak, those findings inherit the weakness and become leads, not decisions.
A finding looks compelling but sits on low-confidence detection. How do you treat it?
As a candidate to validate, not a conclusion. Confirm taxonomy mapping and coverage, then run an experiment rather than acting on it directly.
What does a CSM confirm on this screen before a review?
That detected work is mapped to the correct process taxonomy and that confidence and coverage are adequate for the process in scope.
Verified vs demo. Screen is live in the demo at /#/sessions; exact controls, confidence figures and the detection method shown are SME-validation-pending.