What Is Process Discovery? Methods, Tools and Automated Discovery

Process discovery is the work of finding out how a business process actually runs: which steps it has, in what order, how often each path occurs and where work waits, loops or goes wrong. The result is a process model based on what really happens, rather than on what the procedure manual says should happen.

Most companies have a picture of their processes in their heads. It usually comes from the people who designed them, and it is usually tidier than reality. Orders that arrive by email instead of EDI, questions that bounce between three teams, exceptions that someone handles from memory: none of that shows up in a flowchart drawn in a workshop. Process discovery closes that gap. This guide explains the two meanings of the term, compares the four main discovery methods, shows how automated process discovery works and sets out the steps of a discovery project.

What is process discovery?

The term is used in two ways, and most confusion around it comes from mixing them up.

In the broad sense, often called business process discovery, it covers any method for documenting how a process works today: interviews, workshops, observation, document review and data analysis. The goal is a reliable as-is picture that improvement or automation can start from.

In the narrow sense, process discovery is one of the three types of process mining, alongside conformance checking and enhancement. Here it means an algorithm that reads an event log and builds a process model from it automatically, without a predefined model to compare against.

Both meanings answer the same question: what does this process really look like? They differ in the evidence they use. The broad sense allows opinion and observation; the narrow sense relies only on recorded data. In practice, good discovery projects combine the two, using data for the facts and people for the context behind them.

Process discovery methods compared

Four methods dominate. Each one looks at a different source, so each one sees part of the process and misses another part.

1. Interviews and workshops

The traditional route. Analysts sit down with the people who run the process, map the steps on a whiteboard and validate the result with the team. It captures intent, rules and the reasons behind decisions, which no log will tell you. It also captures memory, and memory favours the standard path. Rare variants, workarounds and volumes are where interviews are weakest, and a large mapping exercise can take months before anyone acts on it.

2. Process mining

Process mining reconstructs the process from event logs in systems such as SAP, Oracle or Dynamics. Every recorded step has a case ID, an activity and a timestamp, so the algorithm can show every path, how often it occurs and how long it takes. That makes it objective and complete for everything the system records. Its blind spot is everything the system does not record: the conversation that came before the sales order, the clarification by email, the phone call that changed a delivery date. Traditional process mining also needs data engineering to extract and prepare those logs, which is why process mining without data engineers has become a topic of its own.

3. Task mining

Task mining records what individual users do on their desktops: clicks, keystrokes and application switches. It is useful for finding repetitive screen work that can be scripted. It sees how one person performs one task, but not why the task exists, where the request came from or what happens after it leaves that desk. It also raises questions about monitoring employees that many organisations would rather avoid.

4. Communication and system data

The newest method starts where most B2B processes actually begin: in email, shared inboxes, tickets and chat. AI reads those conversations, recognises what each one is about (a new order, a delivery question, a price request, a complaint) and links them to the records in the ERP and CRM. That gives a view of the process from the first customer request to the final system entry, including the unstructured part that event logs never capture. This is the idea behind conversation mining, and it is the basis of automated process discovery.

Automated process discovery

Automated process discovery uses AI to build the process model for you, instead of asking analysts to draw it or data engineers to prepare logs for it. The AI reads communication and system data, groups similar requests into processes and subprocesses, and estimates how much volume each one carries.

The shift is in the starting point. Classic process mining starts with a model of the system and asks which events fit into it. Automated discovery starts with the work itself and lets the model emerge from what the data shows. For processes that run through inboxes, such as order intake, customer service and supplier communication, that is the only way to see the full picture.

In Tekst, this is what the Process Discovery feature does. You point it at your connected integrations, and within minutes it returns a process model with main processes, subprocesses and estimated volumes, so you can see where the work is and decide what to tackle first. The first version is rarely perfect, so you can rework the taxonomy: remove, add, rename or lock processes and let the AI regenerate the rest. Every change is saved as a draft with version history, so nothing goes live until you approve it. Because Tekst can also connect to ERP data through a data warehouse, discovery can follow a case from the first email to the final ERP entry.

Scale is where the difference shows. Becton Dickinson handles 1.4 million customer inquiries a year across more than 100 distinct topics. No workshop can map that by hand, and no event log contains it. With automated discovery, full process visibility is typically in place in under 10 days.

Tekst does not record desktops or screens. Discovery works on the communication and system data the business already has, which keeps the focus on the process rather than on individual employees.

Process discovery vs process mining

The two terms overlap, but they are not the same thing.

• Scope: process discovery is the goal (an accurate as-is model). Process mining is one family of techniques for reaching it, and discovery is also one of its three types.
• Sources: process mining works on structured event logs. Process discovery in the broad sense can use any source, including interviews, documents and unstructured communication.
• Output: discovery produces the map. Process mining goes on to check that map against the intended process (conformance) and to add performance data such as throughput times (enhancement).

A useful way to see it: discovery tells you what the process is; the rest of process mining tells you how well it runs. Both are part of process intelligence, which combines the map with the context needed to act on it.

Process discovery steps

Whatever method you use, a discovery project follows roughly the same six steps.

1. Pick the process and the question. Start with one process and one business question, such as "why does order entry take so long?" or "which requests could be automated?". A clear question decides which data matters.
2. Identify the sources. List where the process leaves traces: shared mailboxes, ticketing tools, the ERP, the CRM. For most customer-facing processes the inbox is the first source, not the last.
3. Connect and collect. Connect the sources, with the right access controls and data processing agreements in place. With automated discovery this replaces most of the manual data preparation.
4. Build the first model. Let the algorithm or the AI generate the model: processes, subprocesses, paths and volumes. Treat it as a draft.
5. Validate with the people who run it. Walk the model through with the team. They will spot categories that should be merged or split, and explain why certain variants exist. This is where the broad and narrow meanings of discovery meet.
6. Prioritise and act. Rank processes by volume, effort and error rate, and pick the first improvement or automation. Keep discovery running, because processes change and the model should change with them.

An anonymised audit of SAP order intake shows why the data has to come before the whiteboard. Analysis of 4,514 orders found 1,314 different paths through the process. A team that had mapped the process in a workshop would have drawn one.

What to look for in process discovery tools

Process discovery tools vary widely in what they can see. Five questions separate them.

• Which sources does it read? Event logs only, or also email, tickets and chat? If your process starts in an inbox, a tool that only reads the ERP starts halfway through.
• How much preparation does it need? Some tools need months of data engineering before the first model appears. Others build a first model from connected integrations within days.
• Can you correct the model? AI will group some things wrongly. Look for the ability to rename, merge, split and lock processes, with version history.
• Does it show volumes, not just paths? A map without volumes cannot tell you where to start.
• Does it lead to action? Discovery is only worth doing if it feeds improvement. Check whether the model can be used directly for routing, automation or agentic process automation, or whether it stays a report.

For a broader comparison of platforms, see how to choose process mining software.

Where to start with process discovery

Start with the process that generates the most communication. For most manufacturers and distributors that is order intake or customer service, where requests arrive by email in every shape and language, and where the ERP only records the outcome. Connect that inbox and the ERP, let the first model build, and spend an hour with the team that runs the process to check it.

The first model will show which request types carry the most volume, which ones loop back and forth, and which ones are simple and repetitive enough to automate. That is the point where discovery stops being a mapping exercise and becomes a plan. For examples of what teams do next, see these process mining use cases.