82 days were retired from a Kuwait bank's procurement cycle — not through better technology selection, but through an honest baseline of what the process actually did versus what the system recorded. The baseline required clarity on a question most organisations cannot yet answer: which analytical technique was needed, and why?
Process mining, process discovery, and task mining are 3 distinct approaches to understanding how work happens. Vendors frequently present them as interchangeable, or claim a single platform delivers all 3. The conflation is commercially convenient. It is also analytically costly — the wrong starting technique produces precise data about the wrong question, and an improvement programme that optimises the process as-is rather than as it should be.
Process mining: the event-log approach
Process mining analyses structured event log data — timestamps, case IDs, activity codes — extracted from enterprise systems (ERP, CRM, core banking, claims platforms). It reconstructs the actual flow of transactions through a system by reading what the system recorded. The output is a process map derived from data, not from interviews or observation.
What process mining answers:
- Which paths do transactions actually take through the system?
- Where do transactions deviate from the intended path?
- Which stages are associated with the longest delays?
- Where do loops, rework, and exception routes cluster?
What process mining requires:
- A system that logs structured events with timestamps and case identifiers. Not every system does this consistently.
- Event log data that is complete and covers the period being analysed. Gaps in logs produce gaps in the reconstructed map.
- Domain knowledge to interpret the output. A process mining tool produces a graph. Understanding what the graph means requires process expertise, not just analytical skill.
What process mining cannot see:
Work that happens outside the system. If a checker manually corrects a field before submission, the system log shows a clean input. The correction is invisible to process mining.
Decisions. Event logs record that a step occurred. They do not record why a decision was made, what context the decision-maker held, or what alternatives were considered.
Informal coordination. Emails, calls, and messaging that shape how transactions are processed do not appear in system logs.
Process mining is a diagnostic tool. It tells you what your systems recorded. It is not a complete picture of what your people did.
Process discovery: the conversation and observation approach
Process discovery captures how work actually happens through structured interviews, observation, and documentation review. Unlike process mining, it does not depend on system event logs. It can surface informal workarounds, undocumented exception routes, and steps that happen entirely outside any system.
What process discovery answers:
- What do people actually do, step by step, when they perform this process?
- Where do informal workarounds exist that are not captured in any log?
- What decisions are made, and on what basis?
- What knowledge is held personally by specific individuals — and is at risk when they leave?
- What does the process look like from the perspective of the person doing the work, not the system recording it?
What process discovery requires:
- Access to the people who do the work. Discovery depends on structured conversation and, in some cases, direct observation.
- Facilitators who can distinguish what people say they do from what they actually do. The two frequently differ — not through evasion, but because expertise makes implicit steps invisible to the expert.
- Time. Interview-based discovery is slower than event-log analysis at scale.
What process discovery cannot see:
Scale. Discovery is effective for understanding how a process works. It is not well-suited to analysing variance across thousands of transactions simultaneously. That is process mining's territory.
Recency without effort. A process discovered six months ago may not reflect current reality. Discovery outputs decay as process reality drifts, unless they are maintained actively.
Agentic platforms — like ESSAM — use conversational AI to accelerate process discovery. The conversation captures the process model in natural language, structures it against the E-S-S-A-M framework (Eliminate, Simplify & Standardize, Automate, Migrate), and identifies improvement opportunities without requiring specialists or flowchart software. This makes discovery faster and more current than interview-based methods.
Task mining: the desktop recording approach
Task mining captures work at the desktop level — recording what individual operators do on their screens during a task. It uses screen recording, keystroke logging, and application monitoring to reconstruct workflows at the granularity of individual user actions.
What task mining answers:
- Which applications, fields, and buttons does a user interact with during a task?
- How much time is spent on each application or step?
- What is the variation in how different operators complete the same task?
- Which specific actions are candidates for robotic process automation (RPA)?
What task mining requires:
- Desktop monitoring software deployed on operator workstations. Privacy and consent considerations must be addressed before deployment — particularly in Singapore (PDPA) and Malaysia (PDPA 2010) jurisdictions.
- A representative sample period. Task mining reflects how operators work during the recording window. Month-end peaks, training days, or system outage periods produce unrepresentative data.
- Clear scope definition. Task mining is highly granular. Without a defined scope, the volume of data collected can exceed what the team has capacity to analyse.
What task mining cannot see:
The process context above the task. Task mining shows what an operator does at their screen. It does not show whether the task should exist in the current process design.
Decisions made outside the desktop. A call to a counterparty, a message to a colleague, or a judgment call about whether to proceed — none of these appear in desktop recordings.
The larger process flow. Task mining is task-level. It can identify which individual steps to automate. It cannot design the improved process or determine whether the broader workflow makes sense.
Task mining is most valuable as a precursor to RPA implementation — identifying the exact sequence of UI actions that an automation script needs to replicate. It is not a substitute for process-level understanding.
Where vendors blur the three
A process mining platform that adds desktop recording to its feature list is not a task mining specialist — it has added a feature. A task mining tool that aggregates desktop recordings across users is not doing process discovery — it is doing task-level aggregation. A process discovery tool that includes a simple process map is not providing event-log analysis.
The commercial incentive to blur the categories is straightforward. A platform claiming to do all 3 is easier to sell to a buyer who does not want to evaluate 3 separate tools. The analytical cost is equally straightforward. Each technique answers a different question, requires different data, and produces a different type of output. A buyer who expects process mining to surface informal workarounds will be disappointed. A buyer who expects task mining to tell them whether a process should exist will be disappointed.
There is a provable test. If a vendor claims their tool does all 3, ask to see the task-mining UI separately from the process mining dashboard. Ask what data source each analysis draws from. Ask what the output format is for each technique. If the answers are vague, or the demonstrations conflate the tools, the "all-in-one" claim is a positioning strategy rather than a capability description.
Which technique to reach for first
The correct sequence depends on the question you are trying to answer.
Start with process discovery when:
- You do not have clean, complete event logs.
- The process is informal, lightly systemised, or involves significant off-system work.
- You need to understand decisions and workarounds, not only transaction flows.
- You are establishing a baseline before any investment in analysis tooling or automation.
Move to process mining when:
- You have structured event logs from a core system.
- You need to understand variance at scale — not one process, but thousands of transactions.
- You are investigating where delays and exception routes concentrate.
- You are validating (or challenging) the process map produced by discovery.
Use task mining when:
- You have identified specific high-volume, rule-based tasks as RPA candidates.
- You need precise UI-level action sequences for automation scripting.
- You are measuring operator-level variance in a task that is already understood at the process level.
The sequence most operations teams get wrong: they begin with task mining or process mining before completing discovery. The result is detailed data about a process whose basic design has not been questioned. They are measuring the wrong thing precisely.
E-S-S-A-M and the technique sequence
The E-S-S-A-M framework aligns naturally with this technique sequence. The alignment is not accidental — the framework was designed around the principle that redesign precedes automation.
Eliminate and Simplify & Standardize require process discovery. You cannot decide to eliminate a step you have not understood in its operational context. Process mining shows where transactions slow down; discovery explains why. Both are needed to make elimination decisions with confidence.
Automate is where task mining becomes relevant. Once a process has been redesigned — steps eliminated, inputs standardised — the remaining automatable steps can be characterised at the desktop level. Task mining at this stage is efficient and targeted. Task mining before process redesign risks scripting steps that should be removed.
Migrate — routing human judgment to the right people — benefits from process mining insights. Mining data shows where exceptions concentrate and how long they remain unresolved. That data informs the design of escalation rules and routing logic.
Evidence: Kuwait and the discovery-first sequence
The Kuwait bank procurement case illustrates why discovery-first matters. The 139-day cycle was fully captured in system logs — approvals, submission timestamps, stage completions. Process mining could have produced a detailed map of the transaction flow.
What the logs did not show: informal correction rounds between procurement and finance, re-approval cycles triggered by incomplete submissions, and approval stages retained from a prior policy. These appeared in the logs as normal process steps, indistinguishable from intentional design. Only discovery — in ESSAM's case, through structured conversational baseline — surfaced them as rework.
Abdulla Al-Awadi, the bank's Chief Strategy Officer at the time, directed the baseline. The ESSAM team applied E-S-S-A-M to the discovery output. The result: 139 days to 57 days, a 59% reduction, 82 days retired, 106.9% efficiency improvement.
Process mining would have measured the 139-day process accurately. Discovery revealed that 82 days of it should not exist.
An honest note on ESSAM's position in this taxonomy
ESSAM is primarily a process discovery and redesign platform. It uses conversational AI to accelerate discovery — capturing the actual process through structured questions, identifying improvement opportunities through the E-S-S-A-M framework, and producing documented SOPs without specialist facilitation.
ESSAM does not replace dedicated event-log analysis platforms for large-scale transaction-pattern analysis, and it does not replace desktop recording tools for RPA scripting at the UI level. If those are the specific questions you need to answer, the right tool is the one built for them.
What ESSAM provides that most process mining platforms do not: the conversational discovery layer that surfaces what event logs cannot see. And the redesign framework that determines what to do with the findings before any automation investment is made.
Which question are you actually trying to answer?
Before selecting a process analysis tool, identify the question you need to answer. If it is "what do my system logs show?" — start with process mining. If it is "what is actually happening in this process, including what no system records?" — start with discovery. If it is "which specific desktop actions should I automate?" — start with task mining.
The wrong starting question leads to accurate data about the wrong thing — and an improvement programme that optimises the process as it is rather than as it should be.
Describe the process you want to understand to the ESSAM team. Outline what data you currently have — system logs, interview access, desktop monitoring capability. ESSAM identifies which analytical approach fits your question and what a baseline would show. Reach the team at https://apac.essam.ai/contact — one paragraph describing your process and your question is all that is needed to begin.
Frequently asked questions
What is the difference between process mining and process discovery?
Process mining analyses structured event log data from enterprise systems to reconstruct transaction flows. It shows what systems recorded. Process discovery captures how work actually happens through structured interviews and observation — surfacing informal workarounds and decisions that do not appear in any log. Both are useful; they answer different questions from different data sources and should be treated as complementary, not interchangeable.
What is task mining and when is it used?
Task mining captures work at the desktop level — recording individual operator actions across applications and screens to produce granular UI-level action sequences. It is most useful as a direct precursor to RPA implementation: identifying exactly which steps to automate. Task mining shows what to automate. It does not address whether the process containing those steps is correctly designed.
Can one platform genuinely do process mining, process discovery, and task mining?
Some platforms claim coverage of all 3. In practice, each technique requires a distinct data source: event logs for process mining, structured conversation or observation for discovery, and desktop recording for task mining. When evaluating an "all-in-one" claim, ask to see each capability demonstrated separately, and ask which data source each draws from. Vague answers indicate a positioning claim rather than a distinct capability.
Which technique should an operations team prioritise first?
Most operations teams should start with process discovery — establishing a baseline of what actually happens before investing in event-log analysis or desktop recording. Discovery surfaces the informal workarounds and process design problems that mining and task mining cannot see. Mining and task mining add significant value after the process has been understood and redesigned, not before.
How does ESSAM relate to these 3 techniques?
ESSAM is a process discovery and redesign platform. It uses conversational AI to accelerate discovery — capturing the actual process through structured questions, identifying improvement opportunities through the E-S-S-A-M framework, and producing documented SOPs without specialist facilitation. ESSAM does not replace dedicated event-log analysis platforms or desktop recording tools. It addresses the discovery layer that process mining platforms typically do not cover, and where most process improvement programmes need to start.
Related reading: