RCM Insights troubleshooting - when an answer looks wrong, thin, or disputed
Objective. Give a CSM a symptom-first guide to the problems RCM Insights throws up in the field: numbers that look wrong or missing, coverage gaps, and customers disputing a figure. For each symptom, the likely cause, the first checks to run, and when to escalate - described at app-logic level, with no invented error messages or UI paths.
Most RCM Insights problems are not bugs - they are evidence problems: a thin source, a definition mismatch, a scope misread or a stale feed. This guide works symptom-first so a CSM can diagnose calmly, because in this app a wrong-looking number is usually a correctly-working tool telling you something about the data behind it.
Symptom: numbers look wrong or missing
Likely causes: the metric definition does not match what the user expects; the source feeding the question is thin or not connected; the data is stale; or the question is being asked against data that cannot support it (which should surface as 'not enough data').
First checks a CSM runs:
- Open the metric definition - confirm what it counts, over what population and period, with what exclusions. A 'wrong' number is often a different-than-assumed definition.
- Open the Data view - check the source is connected, how much of the relevant population it covers, and its freshness.
- Confirm the question actually maps to data that exists; if it does not, 'not enough data' is the correct answer, not a bug.
Escalate when: the definition, source connection or refresh cadence appears not to match what was set up for the account - that goes to product and the implementation specialist, not a guess to the customer.
Symptom: coverage gaps
Likely causes: a source is connected but covers only a slice of the relevant population or a short period; a feed stopped refreshing; or a whole source for a payer, client or process is not connected at all.
First checks a CSM runs:
- In the Data view, read coverage, not just the source name - how much of the relevant population is actually present. Presence of a source is not coverage.
- Read freshness to rule out a stalled feed versus a genuine gap.
- Compare the asked question's scope against what the connected sources cover - a gap often means the question reaches beyond the connected data.
Escalate when: a source that should be connected is not, or coverage is materially below what the customer was told to expect. Confirm the intended coverage with product before telling the customer anything about why the gap exists.
Symptom: a customer disputes a figure
Likely causes: a definition mismatch between Insights and the customer's own report (the same label on two different definitions); a scope difference (two dashboards scoped differently); a freshness difference (one view newer than the other); or a projection being compared to a result.
First checks a CSM runs:
- Pin both definitions side by side - does 'AR days' here count the same population, period and exclusions as their number? A metric definition governs whether the two are comparable.
- Compare scopes - a saved dashboard reflects its own filters and scope, so two correct figures can differ.
- Check freshness and whether one figure is a projection and the other a result - keep projection and result separate.
Escalate when: definitions genuinely diverge from what was agreed, or the customer's data and Insights data cannot be reconciled at definition and scope level - that is a product and implementation conversation, documented, not improvised.
Symptom: a fluent answer the customer wants to quote externally
This is the highest-stakes symptom even though nothing looks broken. Likely cause: a well-worded answer is being treated as proof before its evidence has been inspected.
First checks a CSM runs:
- Has anyone opened the source, coverage, freshness and definition behind this answer? If not, it is unverified.
- Does the data genuinely cover the question, or would 'not enough data' be the honest answer?
- Are the metric definitions and sources confirmed with product for this account?
Escalate / halt when: the answer has not been evidence-inspected or confirmed with product. An unverified answer must not become a customer commitment - the correct move is to pause the external use, inspect the evidence, and confirm with product before anything is quoted. This is coaching as much as troubleshooting.
The general diagnosis pattern and escalation line
Across every symptom the pattern is the same: definition -> source -> coverage -> freshness -> scope. Walk those five, in that order, before concluding anything. Most 'wrong' numbers resolve at definition or coverage.
The escalation line is equally consistent. A CSM diagnoses evidence problems at app-logic level and coaches the evidence habit. A CSM does not guess about connectors, refresh cadence, exact metric formulas, or security and compliance - those always go to product and the implementation specialist. Never invent an error message or a UI path to explain a figure to a customer; describe what the evidence shows and, where it is uncertain, say 'confirm with product'. Document any dispute and its resolution so the same question is not re-litigated.
Interpretation check
Most RCM Insights problems are evidence problems, not bugs. Walk definition -> source -> coverage -> freshness -> scope before concluding. An Ask answer is a starting point to verify ('not enough data' is valid), a saved dashboard reflects its own scope, and a metric definition governs comparability. Never guess connectors, cadence, formulas or security - escalate those.
In the field
KnackGlobal (RCM): a client disputing an AR-days figure is diagnosed by pinning definitions and comparing scopes before anyone concludes the tool is wrong - because under displacement pressure, a mishandled dispute or a guessed explanation does more damage than the original discrepancy.
Practical task
Take a seeded or sample dispute - a figure a customer says is wrong. Write the diagnosis walk across all five steps (definition, source, coverage, freshness, scope), state the most likely cause, the first checks you ran, your resolution or the reason it is 'not enough data' / 'confirm with product', and the exact escalation note if it needs product. Do not invent any error message or UI path.
Self-check
A customer says a number 'looks wrong'. What do you check first, and why?
The metric definition - what it counts, population, period, exclusions. A 'wrong' number is most often a different-than-assumed definition, and the definition governs what the figure even means before you look at sources or scope.
A whole payer appears missing from an answer. Is that a bug?
Not necessarily - it may be a coverage gap (source connected but not covering that payer, or not connected at all) or a question reaching beyond the connected data. Read coverage and freshness in the Data view; escalate if a source that should be connected is not.
Two figures for the same metric disagree between Insights and the customer's report. Walk the diagnosis.
Pin both definitions (same population, period, exclusions?), compare scopes (a dashboard reflects its own filters), check freshness, and check projection-versus-result. A metric definition governs comparability; escalate if definitions genuinely diverge from what was agreed.
Nothing is broken but the customer wants to quote a fluent answer externally. What is the move?
Halt until the evidence is inspected (source, coverage, freshness, definition) and confirmed with product. An unverified answer must not become a commitment - this is the highest-stakes symptom precisely because it looks fine.
What does a CSM never guess about, and where does it go?
Connectors, refresh cadence, exact metric formulas, and security or compliance specifics - those always go to product and the implementation specialist, never a guess to the customer, and never an invented error message or UI path.
Verified vs demo. The symptoms and diagnosis pattern are grounded in the demo's ask-and-inspect behaviour on seeded data and the platform honesty guardrails. Exact controls, figures and definitions are SME-validation-pending; live sources, coverage, cadence, definitions, role scope and all integration and security specifics are customer-specific - confirm with product and the implementation specialist.