The process you have written down is not the process you have
Ask a team lead how a piece of work moves through their team and you will get four or five clean stages. Ask five people on that team to describe their last week and you will get those stages plus a set of steps nobody has ever written down: hunting for a document, waiting on an approval that sits for two days, redoing a draft that came back with a comment it should never have needed, reformatting something for a system that should have accepted it as it was.
None of that appears in the process map because none of it was designed. It accumulated. And it is almost always where the recoverable hours are, because designed steps tend to be efficient and accumulated ones never are.
You don't want to integrate AI into the process you wish you had; you want to integrate it into how work actually happens.
That line is from Vectr Solutions, and the same piece is blunt about the consequence of skipping this step: leaders end up implementing AI tools that do not align with business realities, and the result is frustrated teams, unreliable insights and costly rework. Their shorter version is the one worth remembering. If you automate chaos, you just get faster chaos.
AI raises the cost of getting this wrong
This was already true of software. It is more expensive with AI for a specific reason: traditional automation fails loudly. A script pointed at the wrong step breaks, someone gets paged, and you find out. AI pointed at the wrong step produces a confident, well formatted, entirely plausible output for a task that should not have been done at all, and nobody finds out for a quarter.
So the failure mode of automating an unmapped process is not a broken pipeline. It is a faster version of work that was not worth doing, delivered with more confidence than the manual version had. We wrote about that failure pattern in AI fails confidently, not loudly.
What system logs can see, and what they cannot
Process mining is the standard answer here and it is genuinely good at what it does. It reconstructs a process from the events your systems record: a ticket created, a record updated, an approval granted, a document saved. For work that lives inside one or two systems of record, it will show you the real path including the exception branches, and it will do it faster and more completely than any interview.
Its limit is not accuracy. It is coverage. A log records that a ticket moved from one state to another at a particular time. It does not record what happened in the gap, and in knowledge work most of the week lives in that gap.
- A log can see: when a record changed, who changed it, how long it sat between states, which path a case took, and where the queue backs up.
- A log cannot see: the twenty minutes spent finding the context needed to make that change, the decision to escalate that happened in a corridor, the draft rewritten twice before anything was saved, the step someone does in a spreadsheet because the real system is too slow, or the reason a person chose not to use the tool you bought.
That second list is where AI either helps or does nothing, and it is invisible to the instrument most companies reach for. The only reliable way to see it is to ask the person doing it, in a conversation where there is no reason to perform.
Map it from two directions at once
One direction alone gives you a wrong answer in a predictable way. Top down gives you the process as designed, which is tidy and aspirational. Bottom up alone gives you a pile of individual accounts with no shared structure. You need both, and the value is in the difference between them.
- Top down: the stages, the handoffs, the systems of record, and who owns each transition, as the people accountable for the process describe it. This is the skeleton and it is usually accurate about structure.
- Bottom up: a private conversation with each individual about how their week actually goes, including the parts they would not raise in a group session because they sound like complaints or like admissions.
- The delta: every step that exists in practice and not on the diagram. This is the output that matters. It is the list of things that were never designed, which is why they were never optimised.
The private part is not a nicety. In a room with a manager, nobody describes the workaround they built because the official tool is slow. In a private conversation they describe it immediately, because it is just how they get their job done.
What a map worth having actually contains
A stage list is not a map. A map that changes a decision has five things on every stage:
- How long it takes, and how much of that is work versus waiting. These have completely different fixes and get confused constantly.
- Which of your AI licences is already used here, which could be, and which nobody has opened.
- What is repeated. Frequency is what turns an annoyance into a business case.
- What must stay human. Marking this explicitly is what stops someone automating a judgment call because it looked like a routing rule.
- Who it hands to next, and what has to be true for the handoff not to bounce back. Rework is a handoff failure and it almost never appears in the documented process.
Note that three of those five cannot be read from a system. They come from the person, which is why the conversation is the instrument rather than a supplement to it.
Do this before the automation conversation, not after
The sequence matters more than the method. A mapped process turns the automation question from a brainstorm into an inspection: you look at the stages, you look at what is repeated and rule bound and frequent, and the candidates are simply there.
Skip the map and the automation list comes from whoever is loudest in the workshop, which produces a list of things that are annoying rather than a list of things that are expensive. Those two overlap less than people expect.
There is also an order-of-operations point about capability. A process redesigned around AI still has to be run by people who are good with AI, and Prosci's research across 1,107 participants found user proficiency is the single largest challenge in AI adoption, named by 38 percent. Mapping the process and ignoring the capability gets you a better designed workflow that nobody can operate.
Where the map comes from
AI Litmus builds it from both directions. It learns your business process from you, the stages and handoffs as you describe them, then holds a private conversation with every individual about how their week actually runs, and the map is what sits between those two. It also marks what should stay human, so nothing gets automated that should not be. The companion reads are how to measure AI adoption and whether your team is using AI well.
Frequently asked
Why map a business process before automating it with AI? Because automation applied to an unmapped process makes the wrong version of the work faster. The documented process usually leaves out the steps that accumulated rather than being designed: hunting for context, waiting on approvals, redoing work that bounced back. Those undesigned steps are where the recoverable hours usually are. Map first and the automation candidates are visible by inspection; skip it and your list comes from whoever was loudest in the workshop.
What can process mining not see? Process mining reconstructs a process from the events your systems record, so it is accurate about state changes, durations between them, path variants and queue build-up. It cannot see what happens between those events: the time spent finding context before a record could be updated, a decision made in conversation, a draft rewritten before anything was saved, a workaround done in a spreadsheet, or the reason someone chose not to use a tool. In knowledge work, most of the week lives in that gap.
How do you map how work actually gets done? From two directions. Top down, capture the stages, handoffs, systems of record and owners as the people accountable for the process describe them. Bottom up, hold a private conversation with each individual about how their week actually goes. The map worth having is the difference between the two, because every step that exists in practice but not on the diagram was never designed and therefore never optimised.
Why do the conversations need to be private? Because in a room with a manager nobody describes the workaround they built because the official tool is too slow, and nobody admits which step they skip when the week is busy. In a private conversation they describe both immediately, since to them it is simply how the job gets done. The undocumented steps are the point of the exercise, and they only surface when there is no reason to perform.
What should a process map include to be useful for AI? For every stage: how long it takes and how much of that is waiting rather than working, which AI licences are already used there and which are not, what is repeated and how often, what must stay human, and what has to be true for the handoff to the next stage not to bounce back. Three of those five cannot be read from a system log and have to come from the person doing the work.