Process Mining From a CSV Export: See How Your Process Really Runs
Every ticket, order and claim your systems handle leaves a trail: what happened, to which case, and when. Process mining turns that trail into a map of how the process actually runs, not how the flowchart on the wiki says it runs. You don't need an enterprise tool for it; a CSV export is enough.
Process improvement · 2026-10-24 · 8 min read
What an event log is
An event log is a table with one row per event. Three columns are essential: a case ID (the ticket, order or claim number), an activity (what happened: "Triage", "Manager approval") and a timestamp. Three more make the analysis much richer:
| Column | Example | What it adds |
|---|---|---|
| Case ID * | T-1042 | Groups events into one process run |
| Activity * | Escalate to L2 | The steps of the process |
| Timestamp * | 2026-09-08 14:05 | Order of steps and time between them |
| Start time | 2026-09-08 13:40 | Exact work time of each step |
| Team / role | L1 Support | Lanes: who does what |
| Person | Asha | How many people each team really has |
Where to get one
- Jira: export issues with their changelog (status changes) — each status change is an event, the issue key is the case.
- Zendesk / Freshdesk: ticket audit or event exports; ticket ID is the case, status or group changes are the activities.
- ServiceNow: the audit (sys_audit) or metric tables for incidents and requests.
- ERP (SAP, Oracle, Tally, Odoo): document flow or change logs — purchase order number as the case, document steps as activities.
- Spreadsheets: if your team logs work in a sheet with a case number and a date per step, that is already an event log.
Tip: Start small: one process, one or two months of data. A few thousand events are plenty to see the main paths and the bottleneck.
Reading the process map
The miner groups events by case, sorts them by time and counts how often each step follows another. The result is a map where every arrow carries a share of cases: "Triage → Resolve 70%, Triage → Escalate 30%". Rare paths are what make real process maps look like spaghetti, so start by showing only the paths that cover 80–90% of cases.
Paths (variants) tell the story
Each distinct sequence of steps is a path or variant. Usually two or three paths cover most cases; the rest are rework loops (reopened tickets, revised requests) and exceptions. The share of cases going through a loop is often the single most useful number process mining gives you — every reopened ticket is work done twice.
Where the time goes: work, queues and outside waits
Time between two events is a mix of three things: work on the step, queueing for a busy team, and outside waits (for the customer, a supplier, a signature). With start times in the log they can be separated directly. Without them, a good rule of thumb is that the time even the fastest cases take between two steps is an outside wait, while time that only some cases spend is queueing.
From the map to a simulation
A map shows what happened; a simulation shows what would happen if you changed something. In AI Flowchart the mined process opens as a board with step times, branch chances, cases per day and team sizes already filled in from the log, and calibrated so the simulated time per case matches the real one. Then:
- Press ▶ to find the bottleneck — the team or step where cases queue.
- Try what-ifs: one more person in that team, a faster step, skipping an approval.
- Use 🎯 Find the best fix to rank every single change by time saved.
- Turn the process into an SOP with a RACI matrix once you have settled on the fix.
Open the support ticket sample →
Frequently asked questions
Do I need an enterprise process mining tool?
Not to start. Tools like Celonis are built for millions of events across many systems. For one process and a CSV export, a browser-based miner shows the same map, paths and times in minutes.
Is my data safe?
In AI Flowchart the log is parsed and analysed in your browser and never uploaded. Only the resulting diagram is saved if you open it as a board.
What if my log has no start times?
Step times are then estimated from the gaps between events, outside waits are detected from the time even fast cases take, and the whole model is calibrated so the simulated time per case matches the real one.