Workflow and action engine
Objective. Explain how Time Champ turns a signal into a tracked action and outcome - propose, approve, execute, log, verify - so you can position the platform as driving action, not just reporting, while keeping simulated, approved and executed states strictly distinct.
The workflow and action engine is what makes Time Champ operational rather than merely analytical. This teaches the propose-to-verify loop the demos show, what is safe to say, and the critical interpretation discipline: a simulated or proposed action is not an executed one or an achieved result.
See it in the demo
What the workflow and action engine is in Time Champ terms
The platform does not stop at a number; it moves a signal toward a tracked action and a verified outcome. The demos show this loop clearly: Intraday Management simulates a corrective action, records it in an action log, and reviews the actual outcome; Value Leakage tracks a finding from baseline through action to verification, with recovery explicitly separated into recovered capacity versus cash recovered; Scheduling treats planning, optimisation and publication as distinct steps; Work Understanding has an improvement workspace with an owner and before/after measurement; Quality closes an evaluation-to-review-to-coaching loop.
The mental model is a chain of states: signal, proposed action, approval, execution, log, and verified outcome. Each state is different, and the platform is designed to keep them distinct - which is exactly what makes an action defensible rather than an unverified claim.
What a Sales or CSM person can say confidently
Safe to say: 'Time Champ drives action, not just reporting - a signal becomes a proposed action, someone approves it, it is executed and logged, and the actual outcome is reviewed. Nothing has to live only in a dashboard.'
Safe for CSM operating routines (C06, C08): an action log with ownership turns a business review into traceable follow-through - what was proposed, approved, done, and what actually resulted.
Safe, and essential, as an interpretation rule: keep simulated, proposed, approved, executed and verified strictly apart. A simulated improvement is not an executed action or an achieved service result (idm rule); a projected recovery is not cash recovered (value-leakage rule). Presenting a projection as a result is a critical error (assessment gate).
Do not assert how execution integrates with a customer's systems, whether an action runs automatically, or the exact approval and governance model for a given customer - those are product and configuration facts.
What always escalates to security or product
Route to a specialist:
- Whether and how an action executes automatically or integrates with a customer's operational systems (overlaps PLAT-08).
- The exact approval, governance and segregation-of-duties model for a specific customer (overlaps PLAT-03, PLAT-04).
- Any action with security, access or compliance implications.
- Whether a specific workflow a customer wants can be built and automated.
The posture: the propose-approve-execute-log-verify loop and the state distinctions are demo-supported and safe to teach; the automation, integration and governance specifics for a given customer escalate.
The honest limit
Demo-supported: a propose-to-verify loop with an action log, before/after measurement, distinct planning/optimisation/publication steps, and explicit separation of simulated, executed and verified states (and of capacity versus cash).
Confirm with product: execution automation and integration, the approval and governance model, and whether a specific automated workflow is supported for a given customer.
Separate cleanly: 'the platform moves a signal to a tracked action and a verified outcome, and it keeps simulated, executed and verified apart' (safe) from 'it will automatically execute this action in your system under this approval model' (confirm with product). The state discipline is the whole value - never let a projection be heard as a result.
Interpretation check
A simulated or proposed action is not an executed action, and an executed action is not a verified result; the engine is designed to keep these states distinct, and presenting a projection as a result is a critical error.
In the field
In an RCM account, the action engine is what turns a denial or backlog signal into a proposed action, an approval, an executed step and a verified outcome - but the credible story keeps recoverable value, executed action and collected cash strictly separate, exactly as the Value Leakage recovery screen does.
Practical task
Using the Intraday Management and Value Leakage demos, map one signal through the full loop - signal, proposed action, approval, execution, log, verified outcome - and label which states are simulated versus executed versus verified. Write the one sentence you would use to keep a customer from hearing a projection as a result.
Self-check
What is the core difference between Time Champ and a reporting tool, stated honestly?
It drives a tracked action loop - signal to proposed action to approval to execution to log to verified outcome - so decisions do not live only in a dashboard, while keeping each state distinct.
Why must simulated, executed and verified states be kept apart?
Because a simulated improvement is not an executed action and an executed action is not an achieved result; conflating them (for example presenting a projection as cash recovered) is a critical error that destroys credibility.
A customer asks whether an action executes automatically in their systems. What do you do?
Describe the propose-approve-execute-log-verify loop, then route execution automation, integration and the approval/governance model to a specialist - do not assert automatic execution.
Which workflow facts are safe and which escalate?
Safe: the propose-to-verify loop, the action log, before/after measurement, and the simulated/executed/verified and capacity/cash distinctions. Escalate: execution automation, system integration, approval/governance model, and specific-workflow feasibility.
Verified vs demo. The propose-to-verify action loop, action log, before/after measurement and the simulated/executed/verified and capacity/cash distinctions are shown in the demos; execution automation, system integration, approval/governance and specific-workflow feasibility are product facts to confirm.