Configuration
Objective. Explain that Time Champ is configured rather than hard-coded - rules, standards, classifications, mappings and scope are settings - so you can set correct expectations about tailoring, and know that a wrong configuration is the most common reason numbers look wrong.
Configuration is why the same product tells different customers a correct, tailored story - and why most 'the numbers are wrong' problems are configuration problems, not product faults. This teaches what is configurable, who owns it, and the discipline of validating configuration before trusting any metric.
See it in the demo
What configuration is in Time Champ terms
Configuration is the set of decisions that make a generic application produce a specific customer's correct numbers. The demos expose configuration everywhere: Time and Activity has productivity rules and data sources; Employee Monitoring has capture policy, agent modes, classifications and administration; Work Output has standards, complexity and targets plus Output Studio; the Workforce Management apps have capacity rules, service goals, shift rules and configuration areas; Scheduling has an explicit configuration area; RCM Insights has Admin and metric definitions.
The key truth: classifications (for example, what counts as productive), standards (what a completed unit should take), denominators, and scope are configurable - they are decisions, not universal facts. That is why two customers can both be correct with different settings, and why reading a metric without knowing its configuration is unsafe (F06).
What a Sales or CSM person can say confidently
Safe to say: 'The product is configured to your operation - your productivity classifications, your completion standards, your service goals - so the numbers reflect how you actually work rather than a generic assumption.' This is a genuine strength and a true statement.
Safe for CSM: configuration validation is step zero of trust. Before interpreting a metric, confirm the classifications, standards, denominators and scope are set correctly for this customer (C02, C05). Most metric disputes resolve to a configuration that does not match the customer's reality, not a broken product.
Safe to position: because classifications and standards are configurable, a label like 'non-productive' reflects a setting the customer controls, not a verdict the product imposes (F04).
Do not promise that a specific configuration option exists, or that a particular tailoring is possible, for a given customer without confirming - the catalogue of configurable settings is a product fact.
What always escalates to security or product
Route to a specialist:
- Whether a specific configuration or customisation a customer wants is actually supported.
- The exact mechanism and limits of configuration (what is self-service for an administrator versus implementation-only).
- Any configuration that touches capture policy, retention or access - those carry security implications (PLAT-06).
- Integration-driven configuration such as mappings that depend on an external system (PLAT-08).
- Anything where a customer treats a desired setting as a contractual commitment.
The posture: you can confidently say the product is configured to the customer and that classifications/standards/scope are settings; you escalate whether a SPECIFIC desired configuration is supported and how it is delivered.
The honest limit
Demo-supported: productivity rules, capture policy and agent modes, classifications, standards, complexity, targets, service goals, capacity and shift rules, and admin/metric-definition areas all exist as configurable settings.
Confirm with product: whether a specific customisation is supported, the exact self-service-versus-implementation boundary, and any configuration with security or integration implications for a given customer.
Separate cleanly: 'the product is configured to your operation and classifications/standards are settings you control' (safe) from 'yes, we can configure exactly that for you' (confirm with product). Configuration is a strength to sell, not a blank cheque to sign.
Interpretation check
Classifications, standards, denominators and scope are configurable decisions, not universal facts; a metric cannot be read correctly without knowing its configuration, and most 'wrong numbers' are a configuration that does not match the customer's reality.
In the field
In a ProHance displacement at KnackGlobal, configuration is the fairness lever: output-per-FTE and cost-per-claim only compare honestly once standards, complexity and classifications are set to match the customer's actual work - so the CSM validates configuration before any incumbent comparison is shown.
Practical task
Pick one metric in the Work Output or Time and Activity demo and list the configuration decisions behind it (classification, standard, denominator, scope). Then write how you would explain to a customer that the number reflects their settings, and which configuration requests you would route to a specialist.
Self-check
Why can two customers show different numbers for the same metric and both be correct?
Because classifications, standards, denominators and scope are configurable to each operation, so the metric reflects each customer's own settings rather than a single universal rule.
A manager says utilisation 'must be wrong'. What configuration facts does a CSM check first?
Whether productivity classifications, completion standards, the denominator and the scope are set correctly for this customer - most disputes resolve to a configuration mismatch, not a product fault.
A customer wants a specific customisation. Can you confirm it on the call?
No - confirm that the product is configured to the operation, then route whether that specific customisation is supported, and how it is delivered, to a specialist.
Which configuration facts are demo-supported and which escalate?
Demo-supported: that rules, capture policy, classifications, standards, targets and service goals exist as settings. Escalate: whether a specific customisation is supported, the self-service-versus-implementation boundary, and settings with security or integration implications.
Verified vs demo. Configurable productivity rules, capture policy, classifications, standards, targets, service goals and admin/metric-definition areas are shown in the demos; whether a specific customisation is supported and how it is delivered are product facts to confirm.