Data platform
Objective. Explain the data platform as the shared layer that feeds metrics - sources, coverage, freshness, definitions and scope - so you can set honest expectations about where numbers come from, and route storage, residency and retention to security.
Every metric a customer trusts rests on the data platform beneath it. This teaches the parts that matter for correct interpretation - sources, coverage, freshness, definitions - what is safe to say, and the hard line at storage, residency and retention, which are security facts.
See it in the demo
What the data platform is in Time Champ terms
The data platform is the shared layer that collects signals, applies definitions and standards, and serves the numbers every application shows. You can see its customer-facing edges in the demos: RCM Insights exposes Data, Metrics and sources; applications across the suite expose data-source settings, standards and definitions. The important parts for Sales and CSM are the ones that determine whether a number is trustworthy:
- SOURCES - where a signal or work item comes from.
- COVERAGE - how complete that source is (counted-work coverage, agent/data coverage).
- FRESHNESS - how current the data is.
- DEFINITIONS and STANDARDS - what counts, configured per customer (PLAT-05).
- SCOPE - the organisation/client boundary the number sits inside (PLAT-02, F05).
These are exactly the checks F06 and C05 teach before interpreting any metric. The data platform is not an abstract backend; it is the set of things you validate to trust a dashboard.
What a Sales or CSM person can say confidently
Safe to say: 'The numbers are built from your actual signals and work items, with definitions and standards configured to your operation, and you can inspect sources, coverage and freshness - RCM Insights even surfaces the data and evidence behind an answer.' This is both true and the trust message.
Safe for CSM (C05): before trusting any metric, validate sources, coverage, freshness, definitions and scope; a number without adequate coverage or with stale data should not become a customer commitment (F06, rcm-insights interpretation rule).
Safe for sales: point to evidence inspection as the antidote to 'can I believe this number' - the platform is built to show the data behind the answer, not just the answer.
Do not assert where data is stored, how long it is retained, how it is encrypted, or its residency - those are security facts (PLAT-06), not data-platform talking points.
What always escalates to security or product
Route to a specialist:
- Data storage location, residency and retention (security - PLAT-06).
- Encryption and access to the underlying data store.
- Exact data model, warehouse technology and architecture.
- Data export, portability and deletion mechanics and any contractual data commitment.
- Whether a specific source can be ingested and at what freshness for a given customer (overlaps PLAT-08).
The line: coverage, freshness, definitions and scope are things you VALIDATE and can discuss as interpretation discipline; storage, residency, retention and architecture are security and product facts you ESCALATE.
The honest limit
Demo-supported: the platform is built from customer signals and work items with configurable definitions and standards, and exposes data, metrics, sources and evidence (clearest in RCM Insights).
Confirm with product/security: storage location, residency, retention, encryption, the underlying data model and warehouse technology, and export/deletion mechanics.
Separate cleanly: 'the numbers come from your signals, you can inspect the sources and evidence, and we validate coverage and freshness before trusting them' (safe) from 'your data is stored here, retained this long, encrypted this way' (confirm with product/security). Discuss trust-through-evidence; escalate storage-and-residency.
Interpretation check
The data-platform facts that make a number trustworthy - sources, coverage, freshness, definitions, scope - are things you validate and can discuss; storage, residency, retention and encryption are security facts you escalate. Never let a question about trusting a number drift into an improvised storage claim.
In the field
In a KnackGlobal displacement, trust rests on the data platform: output-per-FTE and cost-per-claim are only credible once counted-work coverage, freshness, standards and client scope are validated - so the CSM inspects the data behind the number before it is shown against the incumbent.
Practical task
Take one metric from the RCM Insights or Work Output demo and write its trust checklist: its sources, how you would judge coverage and freshness, its definition and its scope. Then list the data-platform questions (storage, residency, retention, encryption) you would route to security.
Self-check
Before trusting a metric, which data-platform facts does a CSM validate?
Sources (where it comes from), coverage (how complete), freshness (how current), definitions and standards (what counts), and scope (the org/client boundary) - the F06/C05 checks.
A customer asks 'can I believe this number?' What is the honest, platform-grounded answer?
Show the data behind it - the platform exposes sources, coverage, freshness and evidence (RCM Insights surfaces the supporting data), and an answer without adequate coverage should not become a commitment.
A security reviewer asks where the data is stored and how long it is kept. What do you do?
Route storage location, residency, retention and encryption to a specialist - these are security facts, not data-platform talking points, and must never be asserted.
Which data-platform facts are safe and which escalate?
Safe: sources, coverage, freshness, definitions, scope, and evidence inspection. Escalate: storage location, residency, retention, encryption, data model/warehouse technology and export/deletion mechanics.
Verified vs demo. That numbers are built from customer signals with configurable definitions, and that sources, coverage, freshness and evidence can be inspected, is shown in the demos; storage location, residency, retention, encryption and the underlying data architecture are product/security facts to confirm.