TCTime Champ Academy
PlatformSALES ยท CSM35 min

Rules engine

Objective. Explain that much of what Time Champ decides - productivity classification, capacity assumptions, adherence grace, service goals - is driven by configurable rules the customer owns, so you position tailoring honestly and treat rule settings as the first thing to check when numbers surprise.

Rules are how the platform turns raw signals into classified, measurable outcomes in a way that reflects each customer's operation. This teaches what rules govern, why rules are a configuration-and-trust concept, and the line at exact rule capabilities for a specific customer.

What the rules engine is in Time Champ terms

A rule is a configurable decision the platform applies consistently: what counts as productive, what a completed unit should take, how much grace an adherence calculation allows, what service goal a plan targets. The demos expose rules across the suite - Time and Activity has productivity rules; Capacity Planning has capacity rules and standards; Real-Time Adherence and Intraday Management expose rules; Scheduling has shift rules; Work Output has standards, complexity and targets.

The important truth: rules are DECISIONS the customer owns, not universal facts (PLAT-05). A productivity classification or a handling standard is a setting, which is why a label like 'non-productive' reflects a rule the customer controls, not a verdict the product imposes (F04). Rules are also why reading a metric without knowing the rule behind it is unsafe (F06) - the rule is half the meaning of the number.

What a Sales or CSM person can say confidently

Safe to say: 'How work is classified and measured is driven by rules you configure - your productivity classifications, your completion standards, your service goals - so the output reflects your operation, and you can change the rule if your reality changes.'

Safe for CSM (C05): when a metric surprises a customer, the rule behind it is the first check - a classification, standard or grace setting that does not match the customer's reality explains most 'wrong number' disputes before you ever question the data.

Safe for trust (F04): because classifications are rule-driven and reviewable, the product is not imposing hidden judgements - the customer can see and adjust the rules.

Do not assert the exact rule capabilities - how complex a rule can be, what conditions are supported, whether a specific rule a customer wants can be built - for a given customer. That is a product fact.

What always escalates to security or product

Route to a specialist:

  • Whether a specific rule or classification logic a customer wants is supported.
  • The exact expressiveness and limits of the rules engine (conditions, combinations, precedence).
  • Rules that depend on integrated data from another system (overlaps PLAT-08).
  • Any rule change with access or capture implications (overlaps PLAT-06).
  • How rule changes are governed, versioned and audited for a specific customer (overlaps PLAT-04).

The posture: you can confidently say that classification and measurement are rule-driven and customer-owned, and that rules are the first thing to check; you escalate whether a SPECIFIC rule is supported and how the engine is bounded.

The honest limit

Demo-supported: productivity rules, capacity rules and standards, adherence rules, shift rules, and completion standards and targets exist as configurable, customer-owned settings.

Confirm with product: whether a specific rule is supported, the engine's exact expressiveness and limits, rules driven by integrated data, and rule governance/versioning for a given customer.

Separate cleanly: 'classification and measurement are rule-driven and you own the rules' (safe) from 'yes, we can build exactly that rule for you' (confirm with product). Sell the tailoring-and-ownership; escalate the specific-rule feasibility.

Interpretation check

A rule is half the meaning of a number: a classification, standard or grace setting is a customer-owned decision, not a universal fact, so a metric cannot be read correctly without knowing the rule behind it, and the rule is the first thing to check when a number surprises.

In the field

In a KnackGlobal displacement, the rules engine is the fairness lever: productivity classifications and completion standards must match the customer's actual work before any output or cost comparison is credible - so the CSM reviews the rules behind each figure before it is shown against the incumbent.

Practical task

Pick a classified metric in the Time and Activity or Capacity Planning demo and name the rule behind it (classification, standard, or grace). Write how you would explain to a customer that the number reflects a rule they own, and list the rule questions you would route to a specialist.

Self-check

A manager disputes a productivity figure. Why is the rule the first thing a CSM checks?

Because classification is rule-driven and customer-owned; a classification or standard that does not match the customer's reality explains most disputes before the data is ever in question.

How does rule-driven classification support the trust conversation?

Because classifications are configurable and reviewable, the product is not imposing hidden judgements - a label reflects a rule the customer controls and can adjust, which is honest and defensible.

A customer wants a specific classification logic built. Can you confirm it?

No - confirm that classification and measurement are rule-driven and customer-owned, then route whether that specific rule is supported, and the engine's limits, to a specialist.

Which rules facts are safe and which escalate?

Safe: that productivity/capacity/adherence/shift rules and standards are configurable and customer-owned, and that rules are the first check on a surprising number. Escalate: specific-rule feasibility, engine expressiveness, integrated-data rules, and rule governance/versioning.

Verified vs demo. Configurable, customer-owned productivity/capacity/adherence/shift rules and standards are shown in the demos; whether a specific rule is supported, the engine's expressiveness and limits, integrated-data rules and rule governance are product facts to confirm.