Fluency

Task Mining

Last updated

Task mining records how individuals perform work at the desktop, capturing the steps that system logs miss. It runs for a fixed observation window and then stops, so the picture it produces is accurate on delivery and degrades from then on.

What Task Mining actually means

Task mining exists because process mining cannot see the desktop. Where an event log records that a case moved from one status to another, task mining records what the person actually did to move it: the applications opened, the fields copied, the spreadsheet consulted between two systems. At that resolution it captures the manual work that log-based analysis treats as a single transition.

The operating model is what bounds it. A study is scoped, a cohort is instrumented for a defined window, and the output is delivered as findings. That makes it a project with a beginning and an end, and the deliverable describes the window it observed. When the process changes afterwards, and it will, nothing in the deliverable changes with it.

There are two further consequences of the study model. The cohort is a sample, so process variants that the sampled people did not perform are absent, and rare-but-expensive exception paths are exactly the ones a sample is likely to miss. And because the recording is literal, unifying variants into one process is left to the analyst, which is a manual step that does not scale past a handful of processes.

For a defined question at a point in time, such as sizing the manual effort in one back-office process before a business case, task mining answers well. For continuously targeting AI deployment and verifying outcomes afterwards, the constraint is that the baseline goes stale as soon as the study ends, and the next question requires another study.

Examples

Where task mining is strong

Sizing the manual effort in a single back-office process for a business case. The window is defined, the population is known, and the deliverable is a defensible estimate of hours spent on specific steps.

The variant the sample missed

A study instruments twelve people over six weeks. A quarter-end exception path handled by two other people never appears, so the process model omits the work that generates most of the escalations.

A baseline with an expiry date

A study completes in March and is used to justify an automation that ships in September. By then a system has been replaced and the recorded steps no longer match, so the pre-deployment comparison no longer applies.

Frequently asked questions

Task mining records how individuals perform work at the desktop, capturing the steps that system event logs miss. It typically runs as a study: a cohort is instrumented for a fixed window and the output is delivered as findings about that window.

Process mining reads system event logs and sees processes across systems at low resolution. Task mining records desktop activity and sees individual steps at high resolution, but only for the people and period it observed.

The study model. Observation runs for a fixed window and then stops, so the baseline is accurate on delivery and degrades as the work changes. Answering the next question requires commissioning another study rather than querying something that kept running.

Only those performed by the sampled cohort during the window. Rare and expensive exception paths are the ones a sample is most likely to miss, and because the recording is literal, grouping the captured traces into variants is left to the analyst.

When the question is defined and bounded, such as quantifying manual effort in one process to support a business case. When the requirement is continuous targeting and post-deployment verification, a study that ends is a poor fit for a question that recurs.

Ready to deploy AI across your enterprise?

Discover how Fluency can help you continuously deploy AI.