Work Understanding - Data and setup reference
Objective. Explain, at app-logic level, what Work Understanding needs to produce trustworthy discovery, variants, conformance and friction findings, so a CSM knows what to validate before trusting a number and a Sales person knows what to promise as conditional on setup.
Work Understanding infers how work flows from captured signal. Its outputs are only as good as the signal feeding them: the activity capture that detects work, the taxonomy that maps detected work to processes, the reference path that conformance is measured against, and the coverage that bounds every finding. This reference lists those dependencies at app-logic level (specifics are 'confirm with product'), the apps it leans on, and the concrete checklist a CSM runs before trusting discovery, variants, conformance or friction - plus what to escalate to the implementation specialist.
The data and signals it depends on
Work Understanding does not read a documented process - it infers the process from captured activity signal. So the inputs that matter are:
- Activity capture / detection signal - the raw sessions and application activity from which work is detected. This is the foundation; everything downstream inherits its confidence and coverage.
- A work taxonomy - the mapping that turns detected work into named processes and steps. Without a confirmed taxonomy, discovery describes shapes that do not line up with how the customer names their work.
- A reference / intended path per process - conformance is measured against this, and the choice of reference drives the conformance number. This is customer-owned, not a product default to assume.
- Period and scope definitions - which teams, clients, process variants and date range a finding covers.
The honest framing for a customer: discovered workflows and variants are inferred from captured signal and must be confirmed; conformance depends on the chosen reference path; friction and rework are hypotheses, not proven waste. The data basis is what lets those hypotheses be trustworthy enough to validate. Exact capture mechanism, detection method and confidence thresholds are confirm with product.
The setup and configuration required
Described at app-logic level (do not assert specific toggles or UI paths - those are confirm with product):
- Capture coverage set up for the processes in scope - the activity the agent sees determines what work can be detected. A step no agent sees looks short or absent, which silently distorts step time and friction.
- Taxonomy mapping confirmed - detected work mapped to the customer's real process and step names, so discovery and variants describe the right thing.
- Reference path(s) agreed with the customer - so conformance has a meaningful denominator. Never let a reference default stand in for a customer decision.
- Standards and period definitions set - what 'a complete process instance' means and over what window, so before/after comparisons are apples-to-apples.
- Privacy, aggregation and access configured - what is captured, at what aggregation, visible to whom. This is jurisdiction-dependent, customer-owned governance.
Integrations (the systems whose activity feeds detection, and any import of a defined process) are described at logic level here; the specific connectors, scopes and authentication for a customer are confirm with product and the implementation specialist.
Dependencies on other apps
Work Understanding sits downstream of capture and alongside the output and value layers:
- Employee Monitoring / activity capture - the detection signal originates here. If agent coverage, classifications or capture policy are weak there, detection confidence and coverage in Work Understanding are weak too. Validate capture at source before trusting discovery.
- Work Output - answers 'are teams producing the expected work at quality and cost'; Work Understanding answers 'why does the work take this long'. They share the same people and process reality, so completion definitions and taxonomy should line up across both to avoid contradictory stories.
- Value Leakage - a validated Work Understanding finding can feed a leakage item, but only after a measured before/after. Do not let a Work Understanding opportunity estimate become a leakage cash number; capacity opportunity and cash stay separate.
- RCM Operations - the business outcome (days-in-AR, backlog) that a validated improvement should move.
The dependency to watch: a finding is only as trustworthy as the capture beneath it, and only as comparable to Work Output as the shared taxonomy allows.
What a CSM validates before trusting the numbers
Run this checklist before any discovery, variant, conformance or friction figure becomes a claim:
- Coverage - is validated work coverage adequate for the process in scope? Low coverage means findings are partial. A missing step may be a capture gap, not a fast step.
- Detection confidence - is confidence high enough on this process to act, or are findings leads only? (/#/sessions)
- Taxonomy - is detected work mapped to the right process and step names? (/#/taxonomy)
- Discovered flow sanity - does the observed flow match the customer's understanding of the process? The gap is itself a finding, but it must be explained, not ignored. (/#/discovery)
- Reference path - for any conformance figure, which reference was it measured against, and has the customer agreed it? (/#/conformance)
- Active vs waiting - is step time separating active handling from waiting, and is a long wait real or a capture gap? (/#/steps)
- Overlap - before summing or stacking friction findings, have they been de-duplicated?
- Aggregation/access - is what is shown within the agreed privacy and access scope? (/#/privacy)
If any check fails, the finding is a candidate to validate, not a number to report.
What to escalate to the implementation specialist
Escalate - do not guess - on anything that touches the actual capture, detection, integration or privacy configuration for the customer:
- The real capture mechanism, detection method and confidence thresholds for the customer's environment.
- Specific integration connectors, scopes and authentication for the systems feeding detection or any imported process definition.
- Coverage shortfalls that need capture reconfiguration rather than a CSM-side adjustment.
- Taxonomy design beyond confirming an existing mapping - building or restructuring a taxonomy is specialist work.
- Any privacy, retention, aggregation or access question with legal or works-council weight - these are jurisdiction-dependent and customer-owned; confirm with product and the customer's security and legal owners.
The rule: a CSM validates and interprets what is configured; the implementation specialist and product own what the configuration is. Never assert a capture scope, confidence threshold, integration specific or privacy guarantee from the demo.
Interpretation check
Every Work Understanding output is bounded by the signal feeding it: discovery and variants are inferred from captured activity and confirmed with the customer; conformance is only meaningful against an agreed reference path; friction and rework are hypotheses whose trustworthiness depends on coverage and detection confidence. Validate coverage, confidence, taxonomy and reference before trusting a number; escalate the actual capture, integration and privacy configuration to product.
In the field
KnackGlobal RCM: before any claim-process finding is trusted, the CSM confirms capture coverage of the claim steps, that detected work maps to the customer's claim taxonomy, and which reference path conformance uses - because a finding built on thin coverage or an unagreed reference is a lead, not evidence that can sit in front of a 6,000-seat customer.
Practical task
For one demo process, run the CSM validation checklist end to end: note coverage and detection confidence, confirm taxonomy mapping, sanity-check the discovered flow against a stated process, name the reference path for conformance, separate active from waiting in step time, and list the two items you would escalate to the implementation specialist before trusting any figure.
Self-check
A friction finding looks strong but validated work coverage on that process is low. What does that mean for the finding?
The finding is partial and a candidate to validate, not a number to report. Low coverage means the process is only partly observed, so the finding may miss steps or waiting entirely. Confirm coverage and detection confidence before acting.
Why is the reference path a setup dependency and not a product default?
Conformance is measured against the reference path, and the reference choice drives the number. The intended path is customer-owned; letting a default stand in for a customer decision produces a conformance figure nobody agreed to and cannot defend.
Detection in Work Understanding looks thin. Where is the most likely root cause, and is it a CSM fix?
Most likely upstream capture coverage - the activity signal detection is built on. It is usually not a CSM-side adjustment; escalate the capture configuration to the implementation specialist rather than guessing at a setting.
Can a Work Understanding opportunity estimate be reported as a Value Leakage cash figure?
No. A Work Understanding opportunity is a modelled hypothesis of capacity, not cash, and only a measured before/after earns a savings claim. Capacity opportunity and cash stay separate; do not let the estimate cross into a leakage cash number.
A customer asks exactly what the agent captures and who can see it. What do you do?
Describe at app-logic level what is captured, at what aggregation, under whose access - and escalate the specifics. Real capture, retention, aggregation and access are customer configuration and jurisdiction-dependent; never assert a guarantee from the demo.
Verified vs demo. The detection, taxonomy, conformance and privacy screens are demo-shown on seeded data. The actual capture mechanism, detection method, confidence thresholds, integration specifics, available metrics and privacy configuration for a customer are confirm with product and the implementation specialist.