Task management
One task master instead of four competing spreadsheets
Operational tasks are defined once, with the department that owns them, the competency they require and the conditions that make them ready to run. Everything downstream — allocation, queues, time measurement — reads from that single definition.
Work triggers
Where work comes from
System task
Recurring or scheduled operational work generated from a task definition, created idempotently so a repeat run never duplicates open work.
Management instruction
Work raised directly by a manager. The instruction and any later intervention are retained as immutable history.
Training requirement
Training that becomes due appears as work in the same queue as operational work, with the same start, pause and completion behaviour.
Customer communication
A defined trigger contract exists for inbound customer communication work. Communication providers are not connected — this remains configuration-dependent.
Readiness
A task is either ready, held, or needs review — and says which
Task readiness is not a guess. Where a definition cannot activate, the blocking reason is shown alongside it, so the gap gets fixed instead of being worked around.
Imported source data is reconciled rather than trusted silently: unmatched rows, unresolved identifiers and unlinked tasks stay visible until someone resolves them. Managers can see the effect of those gaps in operational visibility.
See the platform running against real operational tasks
We can walk you through the full loop: a training document, the competency it proves, the qualification gate it opens, and the work that gets allocated because of it.