Analyze processes before you automate them: mapping, assessment, selection

It comes up in almost every intro call, usually in passing and with a particular task in mind that costs someone hours every week: retyping quotes, forwarding inquiries, transferring data from emails into a spreadsheet. The wish is understandable, and often justified. The difficulty lies elsewhere, namely in the question of what exactly “that” actually is.

Suppose a business with about fifteen employees wants to automate the handling of incoming customer inquiries. Ask the owner, and it goes like this: inquiry arrives, is recorded, quote goes out. Ask the clerk, and three more steps appear: a query to the warehouse, a look at the price list from two years ago and a handwritten note for the boss. Both describe the same workflow and mean different things.

What is remarkable is that neither account is wrong. The owner knows the workflow from the point of view of the result, the clerk from the point of view of daily work. Only together do they form a picture, and even then the view of the warehouse or accounting is often missing, who are involved at the margins without anyone thinking of them.

This scenario is a pattern, not a reported individual case. It shows why the work begins before the automation. A workflow that nobody oversees completely cannot be reliably captured in rules. A process mapping makes it visible before time and money flow into a tool built on an incomplete assumption.

The most common failure pattern is automating the detour. If an invoice is printed, signed off and scanned again today because a four-eyes principle was once required, you can rebuild that path with a script. It would be faster, but not smarter. The real question, whether the approval is still needed in this form, remains unanswered.

The second failure pattern is the exceptions. A workflow works in the normal case and fails on the five special cases that occur constantly in daily work: a customer without a customer number, an order with a partial delivery, a document in the wrong format. People solve things like this on the side because they have context. An automation without documented exceptions either aborts or silently produces wrong results, which is worse.

Third, someone responsible is often missing. In practice a process rarely has an owner; it is spread across roles that feed into one another. When an automated step then fails, nobody knows who should notice it, fix it or decide whether it may keep running at all. From these three patterns follows what a process mapping must capture.

Once people have seen what is possible, they usually want to start immediately, and with the process that annoys them most. That is human and rarely the best choice. What bothers people most is not automatically what can best be automated, and annoying tasks are often annoying precisely because they contain many exceptions.

We therefore assess candidates against a few sober criteria. Frequency tells how often a workflow occurs per week or month. Duration tells how much working time it ties up per run. Error-proneness describes how often rework, follow-up questions or corrections arise. As a counterweight there is regularity: the more judgment a step requires, the less suited it is to a fixed sequence.

In practice this means: each candidate gets a card with brief details on these criteria, explicitly as a rough estimate and with the source behind it, such as “count in the inbox, four weeks” or “estimate by the clerk”. That keeps it visible which figure is documented and which is assumed. Cards without reliable details do not go into the selection but first into a short measuring phase.

It gets interesting when you lay the criteria side by side. A process that rarely occurs but costs half a day each time can be more worthwhile than one that occurs daily and takes two minutes. Conversely, a frequent, short, error-prone step is often the best entry point, because even small improvements prevent many errors. The weighting depends on the business, which is exactly why the conversation about it is worthwhile.

The obvious alternative to process mapping is trial and error: connect a tool, start a first run, improve. For very small, self-contained tasks this is defensible, for example when a single person handles a single step alone. As soon as several roles, systems or customers are involved, improving afterwards gets expensive, because every correction affects other participants and errors become visible late.

The second alternative is a comprehensive process model, as is common in large organizations, with notation, tooling and a series of workshops. For a company with ten to fifty employees the effort is rarely in proportion to the return. We deliberately keep the mapping lightweight: one interview per role, half an hour of observation at the workplace, a one-page sketch of the workflow. That is enough to make decisions.

Our sequence is: understand, simplify, decide, then automate. Simplifying is the step that is often skipped. Sometimes the need disappears as soon as a duplicate entry is dropped or an approval is cancelled. That is not a failure of the project but its most favorable outcome, because a step that no longer exists needs neither maintenance nor monitoring.

A third alternative is buying an industry solution that brings the workflow “out of the box”. That can work if your business matches the industry standard. If it deviates, you either adapt the software to your workflow or your workflow to the software. Both are legitimate, but it should be a deliberate decision, and that requires a picture of your own workflow.

The price of this approach is time up front. Documenting the process delays visible progress by a few days to a few weeks, depending on the number of workflows. In return, later rework is avoided. If you are in a hurry, you can start with a single, well-defined workflow and limit the documentation to it.

The interview does not begin with a question about the process, but with a specific case. "Tell me about the last request you handled" yields more than "How does it normally work?" The first question draws on memories of real details, the second on the idealized version. We ask to see files, mailboxes and scribbled notes where possible, and after every step we ask: What happens before, what happens after, and who is waiting for it?

Observation complements the conversation where people no longer consciously notice their own work. Someone who has maintained the same spreadsheet for years no longer mentions reaching for the second list. Watching also reveals waiting times: a process that takes one hour on paper actually takes two days because a folder is waiting on a desk for someone to return. This difference between processing time and lead time is central to the assessment.

The conversations produce the process map, at first as a simple sequence: trigger, steps, result. Each step gets four pieces of information: who carries it out, in which medium, how often it occurs and what exceptions there are. We mark media breaks in color, because they are almost always both sources of errors and good starting points. That is where things are retyped, copied or filed, and where most follow-up questions arise.

The reconciliation is important. We show the map to those involved and ask: Is this right? The corrections are the real gain in insight, because they reveal where perceptions diverge. Only when everyone involved says, "that is how it works here," is the current process considered documented.

From the current process we design the target process in two stages. First, we cut and merge: which steps create no value for the customer or for a demonstrably necessary check? Which information is captured twice? Then we decide which of the remaining steps a machine can take over and which stay with people. This two-part approach prevents automation from standing in for a decision that the business should actually make.

For the technical implementation, documentation and tool selection are separate questions. Rule-based processes with clear triggers can usually be solved with connection tools between existing systems, without custom software. Where texts, emails or documents need to be interpreted, a language model can take over individual steps, such as categorizing requests or extracting fields. In that case a plausibility check belongs before or after, because such models are occasionally wrong and do not indicate it.

From the documentation, each automated step receives three definitions. First, an input check: which data must be present for the step to be allowed to start? Second, an exit for exceptions, which hands the case to a named person instead of guessing. Third, a trail, meaning a log that makes it traceable what happened when and with what result. Without these three things, it is hard to judge in operation whether the automation improves anything.

A practical example: a request arrives via a form. The target process checks required fields, creates the contact, assigns the request to a person and sends a reminder after an agreed period. The quote itself is still written by a human, because price and scope are negotiated individually. Automation has not become smaller here; it has moved to the right places.

The first special case is the exception that is not one. During documentation, a special case comes up that everyone describes as rare. Counting in the mailbox then shows that a third of all cases are affected. That fundamentally changes the planning: either the special case belongs in the standard process, or the standard process is less standardized than assumed. We therefore check such statements with a sample from recent weeks, not just with memory.

The second case is knowledge that is written down nowhere. A long-serving employee knows which customer always wants confirmation by phone and which supplier likes to deviate on quantities. These rules are not documented and can only be found in interviews by asking specifically about surprises: What last went wrong, and how did you notice? Such experiential knowledge is either translated into a rule or recorded as a reason for human review.

Third, skepticism within the team. Anyone documenting processes asks questions about other people's work, and that can feel like monitoring or like preparation for job cuts. We state the goal openly: it is about handing off routine and creating time for tasks that require judgment, not about evaluating individuals. Statements made in interviews stay anonymous in the process map, and those involved see the result before it is passed on.

Fourth, there are processes with a legal or contractual framework, such as retention obligations or documentation duties. We know such requirements only in principle and do not resolve them conclusively. They belong in the documentation as a constraint, and in case of doubt a tax advisor or legal counsel should decide what must remain in the target process.

The benefit of process documentation lies first of all in decisions, not in automations. Afterwards you know which processes are worthwhile, which should be changed first and which stay manual. That lowers the risk of putting money into tools that fix the wrong bottleneck. This benefit is real but hard to express in euros, and we do not claim any amount.

Where automation follows, its effect can be read from a few figures. Lead time shows how long a case takes from receipt to completion. The number of follow-up questions and corrections shows whether errors become less frequent. The manual processing time per case, collected over a few weeks with a simple tally sheet or timestamps, shows the actual relief. It is important to record these values beforehand, otherwise there is nothing to compare against.

There are also limits. How much time is saved depends on the business and can only be roughly estimated in advance. Automation can also create new work: exceptions have to be handled, logs read and rules maintained. An honest comparison includes this upkeep. After rollout, expect a phase in which processes are fine-tuned, and judge the result after a few weeks, not after the first few days.

Not measurable, but noticeable, is the gain in clarity. When responsibilities are named, media breaks reduced and exceptions known, the business can be steered better even without technology. Some teams report in such projects that the documentation itself was already the biggest step. That cannot be guaranteed, but it is a plausible side effect.

First: start with one process, not all of them. A single, well-defined process delivers a result in a short time and shows whether the approach suits your business. Second: measure before you intervene. Without a baseline, every statement about success remains opinion. Even a two-week tally sheet is enough to recognize orders of magnitude.

Third: record what deliberately stays manual, and give your reasons. This includes steps involving judgment or relationships, such as a conversation with a dissatisfied customer or the pricing decision on a special order. Steps where errors cause great damage, such as payment approvals, should also keep a human confirmation. And processes so rare that development and upkeep would never pay off also stay with people.

Fourth: introduce automations gradually. An interim state in which the system makes a suggestion and a human confirms uncovers wrong assumptions before they have consequences. Only when the suggestions prove right over a longer period is it worth relaxing the confirmation. Fifth: name a responsible person for each automated process who checks its state regularly.

These rules are unspectacular, and that is precisely their value. They shift the focus from technology to decision-making. Technology is rarely the scarce factor today; clarity about your own process often is.

Anyone who wants to analyze and automate processes should do both in this order. The analysis clarifies how the business actually works, where information gets lost and what exists only out of habit. Automation then starts where it demonstrably relieves. In between lies the honest decision about what may stay, what changes and what deliberately remains manual work.

The next step is small and needs no project. Choose a process that regularly costs you time, and have two people involved sketch it separately from each other, just as keywords on a sheet of paper. The differences between the two sheets are the first finding. If they are large, it is worth documenting the process in more detail before any tool is chosen.

The same rule applies when talking to service providers. An offer that promises a fixed time saving without looking at your process rests on assumptions nobody has checked. Ask which steps the tool takes over, what happens in the case of an exception and who monitors operation. Anyone who can answer these concretely has engaged with your process.

We are happy to support this documentation and, after an intro call, will tell you openly whether automation pays off or whether simplification is enough. The second outcome is a good one too. It saves you a project that would have cost more than it brings.