Most RPA efforts in the mid-market fail not on the robot but on the scope. The start is set up too broadly: a tool is chosen centrally, a centre of excellence is declared, a list of thirty flows is gathered. After weeks there is a lot of structure and little proof. Nobody has seen a bot reliably handle a real case in daily work.

The reason is understandable. RPA sounds like infrastructure, so people treat it like an IT programme with governance first. But a software robot is at heart a very diligent clerk for a very narrow task. You do not learn its value from a roadmap but from the first flow that actually runs. Everything you need to know about volume, exceptions and operating effort shows up on a real case in a few weeks, not in a feasibility study.

You do not learn an RPA programme from the roadmap but from the first flow that holds up in daily work.

That is why the pragmatic start is small and concrete. One flow, one clear success criterion, one named person. If this first bot holds, you have not only a result but also an honest basis for the question of whether and how you automate more broadly.

Not every flow suits an entry point. RPA is strong when a person does the same thing over and over today: copy fields from one system into another, create a record, check a status and pass it on. The more uniform the task, the better the robot fits. A good first candidate has noticeable volume, because only then does the saved time stand out, and fixed rules, because RPA follows instructions and interprets nothing.

Just as important is the stability of the input and the interface. A bot clicks through screens and reads fixed positions. If an application's layout keeps changing or the input arrives in varying formats, the robot breaks quietly and does the wrong thing. For the first flow you therefore want a calm interface and a structured input. There should be exceptions, but in a manageable number and recognisable, so a person can take them over.

The last and often overlooked point is ownership. A bot needs a business owner who is accountable for the result: who decides what a tolerable error is, who approves exceptions and who looks after launch. Without that person, even the best bot becomes an orphan nobody maintains.

The mistake in many rollouts is treating go-live as the goal. For a software robot it is the beginning. RPA works on the surface of other applications, and those applications change: an update moves a button, a new mandatory field appears, a login screen is rebuilt. Any of these changes can stop the bot. That is why every RPA rollout needs an operating plan that defines who notices the bot has stopped and who gets it running again.

Then there is the error path. A bot should not guess when uncertain but stop and hand over. The flow needs a defined point where an unclear case goes to a person, with enough context to decide quickly. That point is not a weakness of the automation, it is its safety net. A bot that dutifully handles the easy cases and cleanly passes on the hard ones is worth more in daily work than one that tries everything and scatters errors.

The third building block is simple observation: is the bot running, how often does a person step in, how high is the exception rate, what does operation cost. Without those numbers you do not know whether the flow is worth it and whether you should build it out. With them a gut feeling becomes a decision.

A pragmatic first RPA flow needs no grand methodology but a clear order. Stay with one flow until it holds, and expand only afterwards.

• Pick one flow that is frequent, rule-based and easy to measure, with a stable interface.
• Record the baseline: how long the flow takes today, how often it runs, where errors arise.
• Gather the exceptions before you build, and define the handover point to a person.
• Build the bot narrow and test it on real cases, including the unpleasant ones, while it is cheap.
• Set up operation: monitoring, an error path and a named person who maintains the bot.

Core sentence: a first RPA flow is in small part a build project and in large part an operating decision. Who skips operation has, after the next update, a robot nobody repairs anymore.

Introducing RPA means choosing a tool first.

The tool is rarely the bottleneck. The bottleneck is the right first flow, a clear error path and a person who owns operation. The tool question answers itself once the flow is set.

A bot that runs in the test runs in operation.

Between test and daily work lie software updates, new special cases and the question of who maintains the bot. A pilot proves feasibility, not stable ongoing operation.

Robotic process automation (RPA), Exception handling, AI operation, Baseline.

How small should the first RPA flow be?

Small enough that a person can describe it clearly today, and large enough that its volume is noticeable. A single, often repeated handoff between two systems is a better start than a whole business process with many branches.

Do we need an RPA strategy before the first bot?

No. For the first flow a clear case, a baseline and an owner are enough. A strategy pays off once several flows are in play and you need a sequence and governance. Before that it only costs time.

What is the most common reason an RPA bot dies after months?

A change in the application that nobody catches. The bot runs on a surface that moves, and without named maintenance it breaks quietly on the next update. That is why the operating plan is not an add-on but part of the rollout.

No external market figures or unapproved client results are asserted. The scope of the first flow and the operating plan are checked against the real stack before implementation.