RCM Insights: Metrics
Objective. Read a metric's definition to decide whether two numbers are comparable, so a figure is never compared or repeated without the definition that governs it.
Metrics exposes the definitions behind the numbers - what 'AR days', 'denial rate' or 'recoverable' actually mean here. It answers 'does this number mean what I think it means', and the definition is what governs whether any two figures can be compared.
See it in the demo
What this screen answers
Metrics answers the comparability question: what exactly does this number count, and can I compare it to another one? RCM terms like AR days or denial rate are defined differently across tools and teams, and silent definition mismatches cause the worst reporting errors. A Sales person uses Metrics to show that definitions are explicit and governable; a CSM uses it to agree definitions with the customer once, so later arguments are about the work and not the maths.
The task
Before trusting or comparing a figure, open its metric definition and read what it counts, over what population and period, with what exclusions. When comparing two numbers, confirm they share a definition. When agreeing a customer baseline, pin the definition first. The task is read the definition, then compare or baseline - at that level, without inventing the exact layout of the definition panel.
How to read it
The classic misread is comparing two same-named metrics that are defined differently. 'AR days' under one definition (for example, excluding credit balances) is not comparable to 'AR days' under another, even though the label matches. A metric definition governs whether a number is comparable - so two figures are only comparable once their definitions match, and a figure is only portable with its definition attached. This is the companion discipline to the Data view: Data tells you the evidence is there; Metrics tells you what the number actually means.
Honest limits
This screen proves that definitions are exposed and governable on seeded data. It does not prove the demo definitions are the customer's. Confirm each metric definition with product and agree it with the customer before any figure is compared across tools or built into a commitment. The number is only as meaningful as the definition behind it, and the definition is customer-specific.
Interpretation check
A metric definition governs whether a number is comparable - two same-named metrics with different definitions are not comparable, and a figure is only portable with its definition attached. Read the definition before comparing or repeating any number.
In the field
KnackGlobal (RCM): agreeing the definition of AR days and denial rate up front is what lets operations and finance trust the same numbers in a QBR - a silent definition mismatch is exactly the kind of error that erodes credibility under displacement pressure.
Practical task
In the demo Metrics view, pick one RCM metric, record its definition (what it counts, population, period, exclusions), and write a one-line rule for when a number using it is and is not comparable to a similarly named figure elsewhere.
Self-check
Two reports both show 'AR days' but the numbers differ. Where do you look first?
The metric definitions - what each counts, over what population and period, with what exclusions. Same label does not mean same definition, and only matched definitions are comparable.
Why pin metric definitions with a customer early?
So later conversations argue about the work, not the maths. Agreeing definitions once prevents silent mismatches that cause the worst reporting errors.
How do the Data and Metrics views complement each other?
Data shows whether the evidence is present, covering and fresh; Metrics shows what the number actually means. Both are needed before a figure is trusted or compared.
What must be confirmed before a figure is compared across tools or built into a commitment?
That the metric definition is the customer's, confirmed with product and agreed with the customer - otherwise the comparison or commitment rests on a definition mismatch.
Verified vs demo. Screen is live in the demo at /#/metrics; exposed, governable metric definitions are demo-shown on seeded data, and exact controls, definition fields and figures are SME-validation-pending. Live, customer-specific metric definitions are production-dependent - confirm with product.