Work Understanding - Troubleshooting and diagnosis
Objective. Give a CSM a symptom-driven diagnosis routine for the problems Work Understanding actually produces in the field - wrong or missing numbers, coverage gaps, and disputed figures - with the first checks to run and the clear line for when to escalate.
Most Work Understanding problems trace back to the same few causes: thin capture coverage, low detection confidence, a taxonomy mismatch, an unagreed reference path, or a human reading an inferred hypothesis as a fact. This module organises the common symptoms, gives the likely cause and the first checks a CSM runs for each, and draws the escalation line. It describes everything at app-logic level - no invented error messages or UI paths.
See it in the demo
Symptom: numbers look wrong or missing
What the customer says: 'This friction figure seems too high / too low', 'a step we know is slow shows almost no time', 'a whole part of the process isn't here'.
Likely causes, in order:
- Capture gap - a step no agent sees looks short or absent, which distorts step time and can hide friction and waiting entirely.
- Low detection confidence - the work was detected weakly, so downstream figures are leads, not decisions.
- Taxonomy mismatch - detected work mapped to the wrong process or step, so the number is real but attached to the wrong thing.
- Scope/period mismatch - the figure covers a different team, client set or window than the customer assumes.
First checks a CSM runs:
- Check validated work coverage and detection confidence for the process (/#/sessions). Is coverage adequate, or is this a partial view?
- Confirm the taxonomy mapping is right (/#/taxonomy).
- Confirm the scope and period on screen match what the customer means.
- For a 'too fast' step, treat it as a suspected capture gap until confirmed genuinely fast, not as good news.
When to escalate: if coverage or detection confidence is inadequate and fixing it needs capture reconfiguration, escalate to the implementation specialist - that is not a CSM-side adjustment.
Symptom: coverage gaps
What the customer says: 'Does this cover everyone?', 'I don't think it's seeing the offshore team', 'the numbers feel incomplete'.
Likely causes:
- Agent / capture coverage not set up for part of the population or some systems - so part of the process is unobserved.
- A system in the process that is not feeding detection - swivel-chair work into an unseen system looks like a gap or a wait.
- Privacy/aggregation boundary - some activity is intentionally not captured or shown at an aggregation that looks like a gap.
First checks a CSM runs:
- Establish what validated work coverage is for the process and population in scope, and state it plainly rather than presenting partial findings as complete.
- Check which systems feed detection against the systems the process actually uses (/#/apps).
- Confirm whether a 'gap' is an intentional privacy/aggregation boundary (/#/privacy) rather than a missing feed.
The honest move: never present a partially-covered process as a full one. State coverage, scope the finding to what is observed, and flag the gap.
When to escalate: coverage shortfalls that need capture or integration reconfiguration, and any gap that turns out to be a privacy/retention boundary with legal weight, go to the implementation specialist and the customer's security owner.
Symptom: customer disputes a figure
What the customer says: 'That conformance number is wrong - our process is fine', 'you can't claim that friction is costing us that', 'the discovered flow is just not how we work'.
Likely causes:
- Reference path not agreed - a conformance figure measured against a reference the customer never signed up to. The reference drives the number.
- Finding read as proven waste - a friction or rework hypothesis presented (by the product's output or by a person) as settled fact.
- Discovered flow genuinely differs from belief - which is a finding, not an error, but feels like the tool is wrong.
- Overlap / summed findings - a stacked savings total the customer rightly distrusts.
First checks a CSM runs:
- For conformance, name the reference path and re-agree it with the customer (/#/conformance). The dispute often dissolves once the reference is explicit.
- Reframe any disputed friction as an observed contribution with a confidence - a candidate to validate, not proven waste (/#/friction).
- Treat a 'the flow is wrong' dispute as a discovery finding: the gap between observed and believed flow is the conversation (/#/discovery).
- For a disputed total, check whether findings were summed across overlap, and replace the total with one measured before/after.
When to escalate: a dispute that turns on the actual detection method, confidence threshold or capture scope, or on a privacy/compliance claim, goes to product - never defend a specific method or guarantee from the demo.
Symptom: findings generated but nothing improves
What the customer says: 'We have loads of findings but days-in-AR hasn't moved', 'we automated a step and it made no difference'.
Likely causes:
- No validation loop - findings acted on directly without a before/after, so there is no evidence any change released time.
- Wrong target - effort put on the longest active step while the days sit in waiting, so the cycle barely moves.
- Finding backlog - too many findings generated, too few reviewed and promoted to experiments.
- Confounded result - a change was made but a volume or case-mix shift masked or faked the effect.
First checks a CSM runs:
- Confirm whether each acted-on finding has a baseline and a re-measure in the improvement workspace (/#/improve). If not, that is the problem.
- Check that the targeted step is where the elapsed time concentrates - usually waiting, not the longest active step (/#/steps).
- Count live experiments vs generated findings; if the backlog is huge, cap live experiments and finish a few.
- For a change that 'made no difference', check for confounders before calling it a failure - and record a null result honestly.
When to escalate: this is usually a CSM coaching and routine problem, not a product one - handle it with the adoption playbook. Escalate only if the inability to measure a before/after is a product limitation for that customer's metrics.
The escalation line
A CSM validates, interprets and reframes; the implementation specialist and product own the configuration and the method. Draw the line like this:
A CSM handles: reading coverage and confidence, confirming taxonomy mapping, agreeing the reference path, separating active from waiting, de-duplicating findings, reframing a hypothesis as a candidate, setting up a before/after, and coaching the review routine.
Escalate to the implementation specialist: capture or integration reconfiguration, coverage shortfalls that need setup changes, and taxonomy design or restructuring.
Escalate to product: the actual detection method, confidence thresholds and what coverage means for the customer's environment; whether a specific metric or tracking is available; and anything presented as a capability the demo does not prove.
Escalate to product and the customer's security/legal owner: any capture scope, retention, aggregation or access question with privacy or compliance weight - jurisdiction-dependent and never answered from the demo.
The rule that prevents the worst mistakes: never defend a method, a figure or a privacy guarantee you would have to invent. Reframe to what the evidence actually supports, and escalate the rest.
Interpretation check
Most Work Understanding problems are coverage, confidence, taxonomy, reference-path or interpretation issues, not product faults - because findings are inferred hypotheses bounded by what capture sees. Diagnose coverage and confidence first, reframe hypotheses as candidates, agree the reference before defending a conformance figure, and escalate the actual method and privacy configuration rather than inventing a defence.
In the field
KnackGlobal RCM: when a claim-process conformance figure is disputed, the resolution is to name the payer-driven reference path and re-agree it rather than defend the percentage - and when 'nothing improved', the diagnosis is usually effort on an active step instead of the waiting that moves days-in-AR, fixed with one measured before/after.
Practical task
Take one seeded demo process and write a short diagnosis note for each of three symptoms you can surface (a suspicious figure, a coverage question, a disputable conformance number): the likely cause, the first checks you ran, what you would reframe to the customer, and the exact item - if any - you would escalate and to whom.
Self-check
A customer says a step they know is slow shows almost no time. What is the first thing you check and why?
Capture coverage for that step. A step no agent sees looks short or absent, so the likeliest cause is a capture gap, not genuine speed. Treat it as a suspected gap until confirmed genuinely fast, and escalate to the implementation specialist if it needs capture reconfiguration.
A customer disputes a 68% conformance figure as 'wrong'. What is the first move, and what is the likely cause?
Name the reference path the figure was measured against and re-agree it with the customer. The likely cause is a reference path they never agreed to - the reference drives the number, so the dispute often dissolves once it is explicit, and then you investigate the deviations rather than defending the percentage.
A customer has hundreds of findings but no improvement in their outcome. What is the most likely cause and the fix?
No validation loop and a finding backlog - findings acted on without a before/after, or too many generated and too few promoted to experiments. The fix is to cap live experiments, confirm each acted-on finding has a baseline and re-measure in the improvement workspace, and check the target is the waiting that holds the days, not the longest active step.
Where is the escalation line for a question about exactly how work is detected?
Product. The actual detection method and confidence thresholds for a customer are not something a CSM defends from the demo. Reframe to what the evidence supports and escalate the method question rather than inventing an answer.
A coverage gap turns out to be an intentional privacy boundary. Who owns resolving it?
Product and the customer's security and legal owner. Capture scope, retention and aggregation are jurisdiction-dependent, customer-owned governance - never asserted or changed from the demo by a CSM.
Verified vs demo. All screens referenced are demo-shown on seeded data; figures are SME-validation-pending. There are no invented error messages or UI paths here - diagnosis is described at app-logic level. The actual detection method, confidence thresholds, coverage, integrations and privacy configuration for a customer are confirm with product and the implementation specialist.