Capacity Planning: Work types
Objective. Validate the work-type taxonomy that the plan is built on - check scope and coverage, and escalate deep setup rather than re-engineering the model.
Work types are the taxonomy of work the plan sizes - each type carries its own standards and drivers. This is a configuration screen: a CSM validates that the right work is represented, not that the model is built correctly from scratch.
See it in the demo
What this screen answers
A CSM opens this to answer 'is the plan sizing the right work?' Every required-FTE number traces back to the work types the plan recognises. If a material work type is missing or miscategorised, the requirement is sizing the wrong work - silently. This screen is where that scope is checked.
The task (validate, do not re-engineer)
Scope to the customer and confirm the work types present reflect the work the customer actually does, at a level that matters for planning. Check for obvious gaps or duplicates. This is a validation and escalation task - you are confirming scope and correctness, not designing the taxonomy. Deep setup (new work-type structures, standards engineering) goes to the specialist. Describe it as 'the work types configured for this scope'.
How to read it
A work type listed here is a planning category, not proof of its standards. The misread is assuming that because a type exists it is sized correctly - the standard and driver attached to it (set on other screens) decide that. Read this screen for coverage and scope: is the customer's real work mix represented? Missing or wrong types are the quiet cause of a plan that looks fine but sizes the wrong effort.
Honest limits
This screen does not prove the standards or drivers behind each type are right - only that the type exists. It is admin configuration; do not re-engineer it in a customer call. Confirm with product and the customer that the taxonomy matches their operation, and escalate structural changes to the implementation specialist.
Interpretation check
A work type existing here means the plan recognises that category - it does not prove the standards behind it are right; validate coverage and scope, and escalate deep setup rather than re-engineering.
In the field
An RCM operation with distinct work (charge entry, claims, denials, appeals): if a high-effort type is missing from the taxonomy, the capacity plan under-sizes silently, which is exactly what this validation catches.
Practical task
Review the work types for one scope and write one line: do they cover the customer's real work mix, and name one gap or duplicate to raise with the specialist - without proposing to re-engineer the taxonomy.
Self-check
What is the CSM's job on this configuration screen?
Validate that the right work is represented at a planning-relevant level and flag gaps/duplicates - not design or re-engineer the taxonomy, which is a specialist setup task.
A work type is listed, so is it sized correctly?
Not necessarily. Existence is scope; correctness depends on the standards and drivers attached to it elsewhere. Validate those separately.
What is the quiet failure a missing work type causes?
The plan sizes the wrong work. The requirement can look healthy while material effort is uncounted or miscategorised, so coverage of the real work mix must be checked.
Verified vs demo. Screen is live in the demo at /#/worktypes; exact controls and figures are SME-validation-pending.