Work Understanding: Work taxonomy
Objective. Read the taxonomy as the map that gives every other screen its meaning, check that observed work is mapped to the right process, and escalate deep setup rather than improvising it.
The taxonomy defines the processes and work types that all other screens group work into. It answers 'are we measuring the right buckets?' - the configuration that decides whether every downstream number is even comparing like with like.
See it in the demo
What this screen answers
The customer question is: is the observed work being sorted into the process categories that actually match how we operate? This is a governance screen, not an analysis one. Sales people show it to prove the app can be shaped to a customer's real process language; CSMs review it because every friction, variant and comparison downstream depends on work being in the right bucket.
The value is correctness at the root. If the taxonomy is wrong, every other screen is confidently wrong - so this is where a CSM earns trust by checking the map before reading the territory.
The task
- Open the taxonomy screen from the overview.
- With the customer, check that the top-level processes and work types match how they actually describe and run the work - not a generic default.
- Spot-check a sample of observed work and confirm it is mapped to the process a person would agree with.
- Flag mismatches and escalate deep configuration to a specialist - restructuring a taxonomy is setup work, not a live demo adjustment.
Describe this at the level of 'is the mapping correct and complete', not invented menu paths or field names.
How to read it
Read the taxonomy as the denominator for everything else. The classic misread is skipping it and trusting downstream numbers that are grouping unlike work together - comparing a 'process' that is really two different processes, or splitting one into fragments that each look small.
Mis-mapped or unmapped work is the quiet failure mode: it either inflates a category, hides time in an 'other' bucket, or makes two teams look different when they are doing differently-labelled versions of the same thing. A clean-looking analysis on a wrong taxonomy is worse than no analysis, because it is believed.
Honest limits
This screen does not itself produce insight, and its correctness cannot be judged from the demo's seeded categories - a real customer's taxonomy must reflect their operation. Deep setup, re-mapping and governance of changes are specialist and customer-owned work.
Confirm with product how taxonomy is built and maintained for a customer, who owns changes, and what coverage of observed work is actually mapped. Position taxonomy review as the prerequisite for trusting any other screen, and escalate structural setup rather than improvising it in front of a customer.
Interpretation check
The taxonomy is the denominator for every other screen; if work is mapped to the wrong process, every downstream number is confidently wrong. Review and correctness come first, and deep setup is escalated, not improvised.
In the field
For an RCM customer, lumping 'denials' and 'first-pass claims' into one process would make waiting and friction numbers meaningless - so the taxonomy review is the step that protects the days-in-AR story.
Practical task
On the demo taxonomy screen, pick one process category, sanity-check that the work under it belongs together, and write a one-line note on what you would confirm with the customer before trusting any downstream analysis of that process.
Self-check
Why check the taxonomy before reading any analysis screen?
Every friction, variant and comparison groups work by the taxonomy. If the buckets are wrong, the downstream numbers compare unlike work and are confidently misleading - a clean chart on a wrong map is believed and dangerous.
What are the failure modes of mis-mapped work?
It inflates a category, hides time in an 'other' bucket, or splits one process into fragments that each look small - making comparisons and totals untrustworthy.
A customer wants the taxonomy restructured during a demo. What do you do?
Flag the need and escalate it as specialist setup. Restructuring is customer-owned configuration governance, not a live demo adjustment.
Can the demo's taxonomy be shown as what a customer will have?
No. It is seeded. A real taxonomy must reflect the customer's own operation; confirm with product how it is built, maintained and owned.
Verified vs demo. Screen is live in the demo at /#/taxonomy; exact controls and categories are SME-validation-pending and seeded, and how taxonomy is built, owned and maintained for a customer must be confirmed with product.