Process Mining Use Cases: Examples by Function

Process mining use cases are the business questions that event data can answer: where a process waits, where it breaks the rules, and which of its many variants cost the most. The most common ones sit in finance and procurement, because every step there already leaves a timestamp in the ERP. The less obvious ones start somewhere else entirely, in an inbox. This guide covers both, function by function, with real examples.

The spread is widening. Deloitte's Global Process Mining Survey 2025, based on more than 120 respondents, found that procurement and accounting remain the core applications, while supply chain, IT operations, claims management and customer service are gaining ground. Among respondents, 48 percent now run process mining company-wide, up from 45 percent in 2021.

What makes a good process mining use case

A good process mining use case has three things: a specific question, event data that can be tied to a single case, and someone with the authority to act on the answer.

The question comes first. "Show us our procurement process" produces a map. "Why are a third of invoices paid late in our German entity" produces a decision. Process mining is at its best when it is testing a suspicion rather than exploring.

The data has to fit. Every event needs a case identifier, an activity and a timestamp, and the case identifier has to hold across every system the process touches. If the purchase order, the goods receipt and the invoice cannot be linked to the same piece of work, the analysis will measure something other than the process.

And the finding has to have an owner. A precise description of a bottleneck that nobody is allowed to fix is the most common way a process mining project ends quietly.

Finance: procure-to-pay and order-to-cash

Finance is where most organisations start, and for good reason. Purchase orders, goods receipts, invoices and payments are all recorded in the ERP with a timestamp and a document number, so the event data is usually there already.

Three-way matching and compliance. In procure-to-pay, the core control is that the order, the goods receipt and the invoice agree before anything is paid. Process mining shows how often that control is bypassed, by which entities and on which kinds of spend. One of the best-documented real examples is the BPI Challenge 2019, a public event log from a large multinational in coatings and paints operating from the Netherlands. It covers purchase order handling across some of its 60 subsidiaries: 251,734 order line items, nearly 1.6 million events, 42 distinct activities and 627 users, 20 of them automated batch processes. The process owner's questions were about compliance. The log also shows why that is harder than it sounds: a single line item for rent can carry twelve goods receipts and twelve invoices, and a logistics contract can carry hundreds.

Duplicate and late payments. The same supplier invoice entered twice, or paid after the discount window closed, leaves a visible trail. Process mining finds the variants where it happens and the step where the check failed.

Days sales outstanding and disputes. In order-to-cash, the questions turn around: why customers pay late, which invoices end up in dispute, and how long a deduction takes to resolve. The variants that delay cash are rarely the ones anyone suspects.

Procurement and supply chain

Beyond the invoice, procurement and supply chain processes produce some of the richest event data in the business, and some of the messiest.

Purchase order changes. Orders that are created, changed, approved again and changed once more are a reliable sign of a process that does not match how buying actually happens. Process mining counts the loops and shows who triggers them.

Supplier delivery performance. Comparing promised and actual delivery dates across suppliers, plants and material groups turns a vague complaint about a supplier into a measured one.

One order, many deliveries. Supply chain processes rarely fit the one-case-one-process shape that classic process mining assumes. One order becomes several deliveries, and one invoice covers several orders. Object-centric process mining was developed precisely for that, and it is worth asking about if your processes fan out this way.

Order management and quote-to-cash

Order management sits between sales and finance, and it is where the gap between the documented process and the real one tends to be widest.

Order cycle time. How long an order takes from entry to release, and which variants take longest, is the first question most teams ask. The answer is usually a handful of exception paths that account for most of the delay.

Changes after entry. Delivery dates moved, quantities adjusted, products substituted. In the ERP these appear as change events. Process mining shows how often they happen and how much time they add. What it cannot show is why, because the reason almost always arrived as a message. Order change management is the process that has to handle that, and it is the clearest example of a use case that starts outside the system of record.

Customer service

Customer service processes generate large volumes of event data through ticketing and case management systems, which makes them a natural fit.

Resolution paths and service levels. Which cases are resolved first time, which bounce between teams, which breach their service level, and what those cases have in common.

Escalation patterns. Whether cases reach the right level of expertise quickly, or climb one level at a time.

Here, too, the case usually begins as an email. BD, the global medical technology company, receives 1.4 million inquiries a year across more than 15 languages. Once incoming messages were classified and routed automatically, the service level on critical product incident reports rose from 13 percent to 97 percent, and first response time fell from three days to 22 hours.

IT service management

IT service management produces some of the cleanest event logs available: every ticket, status change and reassignment is timestamped.

The best public example is Belgian. For the BPI Challenge 2013, Volvo IT Belgium released the event log of its incident and problem management system, 7,554 incident cases and 65,533 events. The process owner wanted answers to four questions that read like a checklist for any IT department:

• Push to front. Are tickets escalated to second and third line too often, or too early?
• Ping-pong. How often do tickets bounce between support teams, and which teams are involved?
• Wait-user abuse. Is the "waiting for user" status used to stop the clock and hide real resolution times?
• Conformity. How do the IT organisations handling the same process differ, and why?

The analyses submitted found exactly the patterns the questions suspected. One confirmed that the number of handovers correlates with total resolution time. Another found incidents escalated straight from first line to third line, skipping the second entirely. The jury added a caveat worth keeping: the real root cause often lies outside the data, because a slow team may simply be the one that gets the hardest cases.

Audit and compliance

Conformance checking compares how a process actually ran against how it was approved to run. Instead of an auditor testing a sample of fifty transactions, process mining tests every one of them, and shows where the exceptions cluster.

The applications follow from that: segregation of duties, approval limits, payment controls and regulatory requirements that demand proof that a process ran as designed. The BPI Challenge 2019 log above is, at heart, a compliance use case. The condition is a current, governed process model to check against. Without one, conformance checking measures execution against a fiction. How to choose process mining software covers that requirement in more detail.

Use cases that start in the inbox

Every use case above assumes the process begins with a record in a system. In practice, many of the most expensive ones begin with a message.

A customer emails to move a delivery date. A supplier sends a revised schedule as a PDF. A complaint arrives in a shared mailbox in one of eight languages. Someone reads it, decides what it means, and keys the result into SAP or Salesforce. The system records the outcome. It records nothing about the reading, deciding and chasing that came before.

To a process mining tool, that work is a gap between two timestamps. The analysis can tell you the gap is long. It cannot tell you what happened inside it. That is where conversation mining comes in: reading incoming communication as process data, so the front half of the process becomes visible.

The use cases look like this:

Order intake from email. At Mitsubishi Chemical Group, 60 percent of orders required manual entry and consumed 20 percent of inside sales time. The template-based OCR in place handled only 4 percent of orders.

Order and complaint routing. Dossche Mills receives order and complaint emails across its customer service mailboxes in EMEA. Classifying, prioritising and routing them automatically reached more than 95 percent accuracy and delivered €100,000 in net annual savings.

Requests across a fragmented group. Asteria handles millions of emails a year across more than 33 subsidiaries in 10 countries, each acquired company with its own systems and habits. A single classification layer now covers all of them.

In each case the event log in the system of record was accurate and incomplete at the same time. The part of the process that cost the most time was the part no system had recorded.

Which process mining use case to start with

Start where two things overlap: a question someone is already asking, and data that is already good.

For most organisations that means procure-to-pay or accounts payable, because the ERP data is mature and the money is easy to measure. For organisations whose operations run through shared mailboxes, order management, claims or customer service, start with the communication layer, because that is where the time goes and where the event log is silent.

Either way, check the data before choosing the tool. A use case is only as good as the event log underneath it, and the questions that decide that come before any vendor conversation.