What the Log Cannot See

A discovered process describes what the systems recorded. Knowing what they did not record is part of having the analysis.

Work outside the systems

Email, where a great deal of coordination and chasing happens.

Spreadsheets, where reconciliation and calculation happen.

Conversations, in person and on calls.

Local documents.

None of it produces an event, so the map shows a gap where the work was.

Time before the first event

A request sitting in an inbox before anyone created the record.

Frequently days, and entirely invisible.

Estimate it by comparing a sample of source requests against record creation times, which is a manual exercise and worth doing once.

Reasons

The log shows a rejection. It does not show why.

It shows a case skipped a step. It does not show whether that was correct.

Reason codes help and are usually unusable until rewritten with the people who select them.

Everything else comes from asking, which is why every finding should be validated with the operation before it is reported.

Effort

Duration is not effort. A step taking four hours may have taken ten minutes of work and waited the rest.

Without start and end timestamps the two are indistinguishable.

Which means cost estimates from a single-timestamp log are guesses, and should be labelled as such.

Quality

The log shows a case completed. It does not show whether the outcome was right.

Errors that pass every check are invisible.

Downstream complaints and returns are the only signal, and they need joining to the case.

What justifies task mining

Only the first two: work outside the systems, and the gaps between events.

Not reasons, which come from asking people and not from watching their screens.

Not effort, which better timestamps would give at a fraction of the cost and intrusion.

Not quality.

And only for a specific named gap, time-boxed and consulted, which is the subject of the next section.

How to declare the blind spots

With every process map: what proportion of cases the model covers, and which steps are known to be unrecorded.

With every cycle time figure: the boundary, and whether pre-record delay is included.

With every cost figure: whether it rests on durations or on measured effort.

A map presented as complete will be undermined by the first person who names a missing step, and there is always one.

The coverage declaration

A short statement attached to every map and every figure.

What proportion of cases the model describes.

Which steps are known to happen and not be recorded.

Whether pre-record delay is included in the cycle time.

Whether durations represent effort or elapsed time.

Whether the resource field is present and at what granularity.

Five lines. A map presented as complete will be undermined by the first person who names a missing step, and there is always one.

Closing gaps without desktop capture

Three cheaper routes, in order of preference.

Enable logging that is off by default, which frequently records exactly the missing step.

Add start and end timestamps, which separates working from waiting and removes the need to estimate effort.

Add a reason code on rejections and cancellations, which converts the largest mystery into a distribution.

Each is a configuration change rather than a monitoring deployment, and together they close most of the gap that task mining is bought for.

Measuring the blind spot

Rather than listing what is invisible, quantify it.

Sum the intervals between consecutive events where nothing is recorded anywhere.

Express it as a proportion of case duration.

That proportion is the blind spot, and it is the honest caveat on every duration finding.

Report it alongside the headline numbers, so that a reader knows how much of the process the analysis actually observed.

A large blind spot is the argument for extending instrumentation — or, where the work genuinely happens on desktops, the argument for the task mining section's cautious approach.