Process mining before you automate messy handoffs

What goes wrong when handoffs pile up

A process rarely breaks in one big, obvious spot. It usually breaks in the gaps between teams, tools, and approvals. One person finishes their part, another never gets the update, and the work sits still for two days because nobody noticed.

That delay often looks like a people problem. Managers assume someone forgot a task, moved too slowly, or ignored a message. Sometimes that is true. More often, the process depends on memory, side messages, or a spreadsheet that only one person checks.

You can usually spot the pattern quickly. Work waits between steps longer than the steps themselves. People enter the same details in different tools. Status updates live in email or chat instead of the main system. Approvals bounce back because the next person gets incomplete information.

When this keeps happening, teams build workarounds. They send a Slack message "just to be safe." They keep a private tracker. They ask for updates in meetings because they do not trust the system view. Each workaround feels small. Together, they turn a simple workflow into a chain of hidden steps.

That hidden work is why business process mapping is harder than it looks. The official process might say "submit, review, approve." The real process is often closer to "submit, fix missing fields, resend by email, wait for finance, remind finance in chat, update a spreadsheet, then approve." If you only look at the formal diagram, you miss the part that burns time.

That is also why teams blame each other so fast. Sales says finance is slow. Finance says requests arrive half done. Operations says nobody follows the rules. All three can be right, because the process creates rework and missed updates at every handoff.

Automation can make this worse. If you automate the visible steps and ignore the hidden ones, you lock the bad process in place. The same confusion moves faster, and fixing it later costs more because the broken path now lives inside the tool.

Process mining gives you a better starting point because it begins with what people and systems actually do, not what the handbook says they do. When you look at real event logs across systems, you can see where work stalls, loops, splits, and quietly leaves the main workflow.

What process mining shows

Process mining shows how work really moves through a company by reading the trail left in your systems. Every ticket update, approval click, status change, and timestamp adds one small fact. Put those facts together and you get a map of the actual process, not the version people remember from a slide deck.

That difference matters more than most teams expect. The written process usually looks clean: a request comes in, a manager approves it, finance checks it, work starts. Real work almost never runs that neatly. People send items back for missing details, skip steps for urgent cases, enter the same data in two tools, or leave a request sitting in someone else's queue for three days.

Event logs make those gaps visible because they show what happened, in what order, and how long each step took. They also expose repeat work that hides inside busy teams. A request might get approved twice, reopened once, and touched by four people before anyone sees the pattern.

A good event log can show the real sequence of steps, where handoffs slow down, how often work loops back, which cases follow the usual path, and where people repeat the same task.

Picture a simple approval flow. On paper, it has four steps. In the logs, 40 percent of requests might bounce back to the requester, return to the same manager, and then wait again for finance. The official map says four steps. The real one has seven touches and two long pauses.

That is where process mining earns its keep. It gives teams evidence before they start automation planning. You can see whether a delay comes from a bad rule, a messy handoff, or a step that repeats because systems do not share data. That matters because automating a broken path usually makes the mess run faster, not better.

Still, process mining does not answer everything. It will not tell you why a manager stalls approvals, whether a legal check exists for a good reason, or what happened in phone calls and chats that never reached a system log. It also will not fix bad data on its own. Teams still need interviews, context, and judgment.

Used well, event logs give you a starting point people can trust: not the process they think they run, but the one they run every day.

Which data to gather first

Start with the systems that already record work as it happens. For most teams, that means the tools people use to create requests, move them forward, approve them, and close them. Process mining works best when you pull real event logs before anyone starts filling gaps from memory.

In most companies, a short list is enough to begin. CRM and sales tools show requests, deals, and status changes. Help desk systems show intake, assignment, and resolution. ERP, billing, and finance tools show orders, invoices, and approvals. Project tracking tools show task moves, comments, and handoffs. If access requests or employee actions are part of the flow, HR or identity systems matter too.

Pick one process and stay narrow. If your company has messy handoffs everywhere, that does not mean you should map everything at once. Choose one flow that causes pain every week, crosses two or three teams, and leaves a trail in software. A purchase approval, customer onboarding, refund request, or access request is a much better starting point than "how work moves through the business."

For each event, gather four fields first: a case ID, an activity, a timestamp, and an owner.

The case ID ties every event to one item moving through the process. That item might be a ticket number, order number, invoice ID, or customer request ID. Without it, you cannot tell which events belong together.

The activity is the step that happened. Keep the name plain and specific, such as "request submitted," "manager approved," or "finance reviewed." If activity names are vague or mixed together, the map gets muddy fast.

The timestamp shows when each step happened. Use the raw event time from the system, not a guessed date from a spreadsheet summary. Even small time errors can hide waiting time between teams.

The owner tells you who touched the work at that step. Sometimes that is one person. Sometimes it is a team, queue, or department. Either works if you stay consistent.

Keep clean system data separate from human guesswork at first. If someone says, "We usually send it to legal after that," treat that as a note, not as an event. Build the first map from recorded facts only. Then compare the map with what people think happens. The gap between those two views is often where the delay lives.

How to map the work step by step

Choose one flow that already hurts. Pick something with a clear complaint and enough event history to study, such as expense approvals, support escalations, or purchase requests. If you try to map every handoff across the company at once, the work gets vague fast.

A narrow flow gives you cleaner evidence and keeps the first pass small enough to finish in days instead of months.

Pull a sample of events from every system that touches that flow. You do not need a perfect data warehouse to begin. A few hundred cases from your ticket tool, ERP, CRM, email approval system, or exported spreadsheets can be enough.

For each event, collect the same fields whenever possible: case or request ID, event name, date and time, person or team that did it, and status or outcome.

Clean names before you analyze anything. If one system says "approved," another says "ok," and a third says "manager signoff," merge them into one label when they mean the same thing. This small cleanup step prevents a lot of confusion later.

Next, group events by case and put them in time order. Each case should read like a simple timeline: request created, manager reviewed, finance checked, request returned, manager approved again, payment sent. Once you line up enough cases, the real path usually looks messier than the policy document.

As you map the flow, mark four things: delays, loops, approvals, and handoffs between teams. Delays show waiting time. Loops show rework. Approvals show where decisions pile up. Handoffs show where ownership changes and context gets lost.

A simple spreadsheet often works for the first pass. Add one row per event, sort by case and time, then mark the gaps between steps. If cases sit for 18 hours before finance opens them, that is a process problem. If 30 percent bounce back to the requester for missing fields, that is another one.

Then compare the map with how managers think the work runs. Managers usually describe the happy path. Event logs show the common path.

Walk through two or three real cases with the people who handle them every day. Ask where the map looks wrong, where systems miss events, and where people work around the official process. That gap between the story and the data is often where bad automation plans begin.

A simple example from request to approval

A team may think invoicing is the slow part. The event logs often show something else.

A customer asks for a quote on Monday at 9:12. Sales creates it at 9:25, operations checks stock at 10:03, and finance approves pricing at 10:18. On paper, that looks fast. But the quote then sits untouched for 19 hours before sales sends it to the customer the next morning. The customer accepts within two hours, so the outside delay is not the problem.

The next handoff is where the process breaks. Finance tries to create the invoice and finds that the cost center field is empty. The item goes back to sales, sales asks operations which project code to use, and operations updates the record after lunch. One missing field creates a loop across three teams.

A simple process map might show only four steps:

• Quote created
• Quote approved
• Invoice issued
• Payment received

That map hides the real work. Event logs show every status change, who touched the item, and how long it waited between handoffs. In this case, the longest delay is not invoice generation at all. It is the time spent waiting between sales, finance, and operations, plus the rework caused by incomplete data.

After operations fills in the missing field, finance sends the invoice in 12 minutes. Payment arrives 14 days later, which matches the agreed terms. If you automate the whole chain without fixing the missing field, you only make the handoff loop run faster. The same bad record still bounces back.

A smaller fix usually does more. Make the cost center required before sales can submit the quote for approval, or pull it in automatically from the deal record. Add a simple rule that blocks approval if that field is blank. That can remove a full day of delay without a large automation project.

That is why business process mapping should start with real event data, not just workshop notes. A whiteboard says the process has four steps. The logs show seven touches, two long pauses, and one avoidable return.

Mistakes that send teams in the wrong direction

A bad process map can look precise and still be wrong. The usual problem is simple: the team starts too early with messy data and fuzzy boundaries. If nobody can agree on where a case starts and where it ends, the results turn into noise.

This happens a lot with shared inboxes, informal requests, and work that jumps between chat, email, and tickets. You may see lots of activity in the event logs, but activity is not the same as a process. Process mining works best when each case has a stable trigger, a trackable path, and a clear finish line.

Dashboards cause another common mistake. Averages make everything look smoother than it is. A report may show that approvals take two days while hiding the fact that 15 percent bounce back three times or sit in limbo until someone chases them by hand. Those outliers are often where the cost sits.

A few warning signs usually mean the picture is too neat:

• Rework loops barely appear
• Manual corrections happen outside the tracked system
• One average time hides huge variation
• Canceled or reopened cases disappear from reports
• Urgent cases skip steps and vanish from the main path

Teams also automate steps before asking why those steps exist. That is how useless work gets faster instead of smaller. A second approval, a copied spreadsheet entry, or a status update might look like a delay worth fixing. Sometimes it exists because finance needs an audit trail, or because upstream data arrives incomplete. If you automate it without asking, you keep the waste and add more code.

It is also easy to blame software for every delay. Some delays come from policy, staffing, timing, or incentives. A manager may approve only twice a week. A customer may send missing documents late. Two teams may use different definitions of "done." No script fixes that.

The biggest miss is ignoring the people who rescue broken cases. Every company has them. They know which requests always fail, which vendor names break matching rules, and which customers need a manual override. Their work rarely appears cleanly in event logs, but it keeps the process moving.

If you want a map you can trust, pair the logs with short interviews and a few real case reviews. That mix is usually better than a polished dashboard alone.

Quick checks before you automate

Teams often rush into automation because the pain feels obvious. Someone says approvals are slow, requests get lost, or people keep asking for status updates. That is not enough. If you automate a messy path, you usually make the mess run faster.

Before you change anything, make sure you can answer a few plain questions from real event logs, not memory.

• Where does the case start, and where does it clearly end?
• Can you follow one case across tools with a shared ID, order number, or ticket number?
• Where does work sit still the longest?
• What are the two most common loops?
• Is the first bad step something you should delete, simplify, or automate?

This sounds basic, but many teams skip it. They build automation around a form, a handoff, or an approval rule before they know whether that step should exist. A useless step with a bot is still a useless step.

A simple test helps. Take 50 recent cases and trace them end to end. If you cannot say where each one started, where it waited, why it looped, and how it finished, you are not ready to automate yet. You are still mapping the process.

In practice, the first fix is often smaller than people expect. Remove one approval. Require one field earlier. Merge two status checks into one. Then measure again. That is usually cheaper and safer than building a full automation flow on top of broken handoffs.

What to do next with what you found

Once you can see the process clearly, do not automate the whole thing at once. Pick the single bottleneck that causes the most delay or sends work back most often. A small change is easier to test, cheaper to undo, and more likely to teach you something useful.

Say purchase requests sit for days because three managers review the same line item. Do not start with a new tool. First, try one rule change: one owner approves standard requests, and only exceptions move higher. That removes a handoff before anyone writes code.

Write the new flow in plain language before anyone builds anything. Keep it short. A new team member should be able to read it once and understand where work starts, who touches it, and when it ends.

Your draft only needs four things:

• What starts the work
• Who handles it next
• Where work can pause or return
• What counts as finished

Then measure the change with numbers, not opinions. Track total time, the number of handoffs, and how often work returns for fixes. If a change saves 15 minutes but creates more rework, you did not solve the problem.

Run process mining again after the test. Compare fresh event logs with the old path and look for shorter waiting time, fewer loops, and fewer side routes through email or chat. Teams often move the mess instead of removing it, so a second review matters.

Keep the first test narrow. Use one team, one request type, or one approval rule. That gives you a clean before and after view and makes the next decision easier. If the result holds, then decide what comes next: automate the step, change ownership, add alerts, or leave it manual because people still need judgment there.

If the findings point to a bigger redesign, outside help can save weeks of trial and error. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this kind of process review fits naturally into broader automation and AI adoption work.

The best next step is usually small and specific. Fix one choke point, measure the result, and confirm it with fresh data before you touch the next one.