The most common mistake happens before a single line is built: in choosing the process. The reflex is understandable. You take the process that hurts most, because that is where the value seems largest. Often that is exactly the hardest one: many exceptions, unclear data, three departments involved. The pilot becomes big, slow and murky, and when it tips over, the whole idea is written off.

The suitable first process is rarely the largest. It is often frequent, rule-based, with clear inputs and good data access. Small process, clean proof. The big case comes later, once the team and the operation are practised.

The first process should not be the most important one, but the one you learn from fastest and most cheaply.

The second mistake is testing only the normal case. In the demo everything runs smoothly because you feed clean examples. In operation the cases arrive that follow no rule: the form in a new layout, the customer who phrases a request differently, the receipt with a missing field. Whoever has not gathered these cases beforehand only notices after launch how often they occur.

Exceptions are not a side topic, they are the core of any honest automation. The question is never whether exceptions exist but what happens to them. A good flow spots the special case, stops and hands over to a person, instead of quietly doing the wrong thing. That behaviour is exactly what you must provoke in the test, while errors still cost nothing.

The third mistake is planning the build and forgetting the operation. An automation is not a project you finish once but a flow that runs every day. Systems change, a portal gets a new field, a format shifts, a permission expires. Without someone watching, you notice the failure only when a customer complains.

Operation means three concrete things: monitoring that makes quality and cost visible, a defined error path for uncertain cases, and a named person who is accountable. Without that person, the best automation becomes an orphan nobody maintains. That is why the operation question belongs at the start, not the end.

The fourth mistake is starting without measurement. If nobody recorded how long the flow took before, how many cases arrive per day and how high the error rate was, then afterwards nobody can prove that anything improved. The value stays a feeling, and a feeling does not carry a budget decision.

A baseline is cheap. You measure the current flow for a few days before you change anything. Then you compare the same slice. That produces a defensible statement about value without writing an invented percentage into the case. Whoever skips the baseline saves a week and loses the ground to justify the next build-out.

This table makes the four mistakes concrete: how to spot each early and what helps against it before the build.

Answer these five questions before you build. At the first one where you get stuck sits the mistake, and before it costs money.

• Is the process frequent and rule-based, and do you have good data access to it?
• Which hard cases have you gathered, and how should the flow react to them?
• Who owns the result, exceptions and approvals in ongoing operation?
• What does the flow look like today, measured as a baseline before any change?
• How will you know it runs better after launch, and who watches?

Core sentence: an automation is in small part a technology project and in large part a clarification project. Who skips the clarification pays it later with interest.

The tool decides success or failure.

For most mid-sized flows the available tools are strong enough. The friction is in selection, exceptions, operation or missing measurement, not the platform.

A successful pilot automatically means stable operation.

Between pilot and operation lie permissions, monitoring, error handling and named accountability. A smooth test is the start, not the proof.

Process automation, Exception handling, AI operation, Baseline.

Which mistake is the most expensive?

Usually the first one: choosing the wrong process. A large, exception-heavy process makes the pilot slow and risky, and a failed pilot discredits the whole idea, although only the selection was wrong.

How do I spot missing operation early?

Ask who decides in the error case and who watches after launch. If you get a department rather than a name for both, the operation is not planned.

Is a baseline worth it even for a small flow?

Yes. It costs a few days of measurement and is the only ground to prove value later and justify the next step. Without it, success stays a claim.

No external statistics or unapproved client results are asserted as verified. Selection and operation are checked against the real stack before implementation.