Where to start with business process automation? Choosing your first implementation

In brief

It pays to choose your first automation where the work is repetitive, happens frequently enough, uses readily available data, and delivers an outcome that is easy to verify. Strong candidates include retyping data between systems, generating documents, updating statuses, or putting together recurring reports.

Do not start by picking a tool or asking where AI could be used. First identify the repetitive task, calculate what it costs, map out the rules and exceptions, and only then choose the technology.

Your first rollout should be small enough to safely pause or adjust, yet frequent enough that its impact becomes clear within a few weeks.

Do not start with "we want to implement AI"

This is one of the most common starting points in conversations about automation.

A business decides it wants to use AI, so it starts hunting for a process where a large language model can be plugged in. The sequence should be the exact opposite.

First look at what repetitive tasks consume your team's time. Only then consider what technology is actually needed to reduce that overhead.

Often, the best solution will be connecting two systems via an API, a webhook, a scheduled task, or a few simple rules. An AI model is primarily useful when the process involves handling content that resists rigid structure.

Business process automation and AI are not the same thing. AI is simply one of the tools available within Automation and AI.

Start with a list of repetitive tasks

You do not need to audit the entire company on day one. Simply ask a few team members which tasks they carry out daily or weekly using a predictable routine.

That list might include:

• retyping orders into an ERP,
• updating statuses across multiple systems,
• downloading and organising documents,
• putting together recurring reports,
• copying data from forms into a CRM,
• generating documents using system data,
• sending notifications when a status changes,
• reconciling data between systems,
• categorising customer enquiries,
• drafting repetitive replies or summaries.

Do not evaluate tools at this stage. The goal is simply to find work that happens often enough for an improvement to actually move the needle.

Map the process from start to finish

"Automate order processing" is far too broad for a first rollout.

A much clearer definition looks like this: once an order is paid, the system pulls the customer and product data, creates an order in the ERP, saves the ERP order ID back into the shop, and alerts a team member if any line item cannot be matched.

This kind of process has a defined trigger, specific input data, clear business rules, a measurable outcome, and identified points that need human attention.

Before implementing anything, answer these questions:

• what triggers the process,
• where the data comes from,
• what conditions need to be verified,
• which destination systems receive the data,
• how you know the operation completed successfully,
• what can go wrong,
• which scenarios require a human decision.

If you cannot clearly describe the process before automating it, you will struggle to determine whether the system is running it properly afterwards.

Sort out conflicting rules first

Automation will not fix a messy process.

If two team members complete the same task differently, you must first agree on the single standard approach or define exactly when each variation applies.

Data is no different. If a customer ID is sometimes kept in one field, sometimes in another, and occasionally tucked into order notes, merely connecting two systems will not resolve the underlying inconsistency.

Often, the very first step in automation is not writing code, but cleaning up data and establishing straightforward operational rules.

How to choose the best process for your first automation

Evaluate each candidate against the exact same criteria.

For your first deployment, stick primarily to processes that sit on the left-hand side of this table.

That does not mean more complex processes should never be automated. They simply are not the right testing ground for learning how your organisation handles designing, deploying, and maintaining automations.

Calculate what the process costs today

Before writing a line of code, establish a baseline.

In the simplest scenario, you only need four figures:

1. how many times per month the task is performed,
2. the average duration of a single run,
3. how much time is spent handling errors and edge cases,
4. the approximate hourly cost of the people doing the work.

Suppose a process runs 300 times a month and each cycle takes an average of four minutes.

That totals 1,200 minutes, or 20 hours each month.

Following automation, five hours might still be needed to handle exceptions and monitor execution. That leaves a net potential saving of 15 hours per month.

Assuming an hourly cost of 80 PLN, that amounts to 1,200 PLN a month. If tooling and maintenance come to 300 PLN a month, this simplified model still delivers 900 PLN in net monthly value.

An implementation priced at 9,000 PLN would reach payback in roughly ten months under these numbers.

This does not automatically mean 900 PLN in extra cash flows in every month. Rather than cutting headcount, a business can redirect that saved time towards higher-leverage initiatives. Either way, the calculation lets you weigh the potential value of automation directly against its implementation cost.

Do not overlook ongoing maintenance

Automation is not a one-off build that runs untouched forever.

APIs get updated, access tokens expire, source platforms adjust data formats, and internal business procedures evolve.

That is why your calculations must budget for:

• automation platform subscriptions,
• API and AI model usage costs,
• process monitoring,
• exception and error handling,
• integration updates,
• time spent refining the process as the business evolves.

An automation that saves five hours a month but demands four hours of maintenance is almost certainly the wrong candidate for your first project.

Hard rules or AI?

Once you have mapped the process, you can decide what technology it actually calls for.

When data is structured and decisions can be written as clear conditional statements, standard logic integrations are easier to monitor and control.

A typical example: if an order is paid, specifies a supported delivery method, and every item maps to an ERP SKU, send it straight to warehouse fulfilment.

AI models prove their value when you run into unformatted text or data that cannot easily be mapped to a static schema. They can classify incoming support messages, pull key fields from varied document layouts, draft concise summaries, or propose suggested responses.

In many setups, the best result comes from combining the two: AI interprets unstructured input, while deterministic rules run the remainder of the workflow.

The higher the cost of error, the tighter the controls

Not every workflow should run fully hands-off right out of the gate.

If a system makes a minor mistake drafting internal meeting notes, an employee can easily correct it. If it automatically reprices a thousand products or triggers a bank transfer based on an inaccurate classification, the fallout is severe.

As the business risk increases, so should your checkpoints.

A sensible first phase might prepare all the data and queue it for human sign-off. Only once a significant track record of verified runs is established should you consider removing human validation from those steps.

Design for exceptions before going live

A well-architected automation does not just map out the happy path—it specifies every exception.

Consider what should happen when:

• a required field is missing,
• a product does not exist in the second system,
• a third-party API fails to respond,
• the system returns an error halfway through a multi-step operation,
• the same payload is delivered twice,
• the process is rerun manually?

Define which operations should automatically retry, which must stop immediately, and who should be notified when an alert triggers.

Building in idempotency is essential. Retrying a failed message should never produce duplicate orders, invoices, or payment requests.

Every automation needs an owner

After deployment, someone must own the process.

They do not need to watch it around the clock, but they should track error alerts, understand which edge cases land in manual review, and know when to escalate an issue to the technical team.

An ownerless automation can quietly run for months until a silent breaking change in an external system halts critical business steps.

The process owner is also the person who verifies that the automated workflow still reflects how the business genuinely operates day to day.

Keep your first rollout intentionally narrow

You do not need to automate every order, every document, or every customer workflow from day one.

Limit the initial scope to a single sales channel, one document format, a specific department, or a well-defined subset of cases.

This allows you to validate system behaviour against production data without betting core operations on it.

After a few weeks, you will have concrete data: how many runs succeeded automatically, how many demanded intervention, how much time was genuinely recovered, and how much effort maintenance took.

What to measure before and after automating

Record baseline figures before launch so you have real metrics to reference later.

Without clear baseline data, it is easy after a few months to simply conclude that "it runs fine"—without being able to prove whether it delivered any genuine return.

What makes the first project a success?

It does not need to automate 100% of cases.

If 80% of standard operations execute automatically and the remaining 20% are handed over to a human with all necessary context pre-loaded, that is a far better outcome than a fragile system trying to anticipate every single exception.

You should also evaluate whether the error rate remains acceptable, whether the workflow is simple to monitor, and whether ongoing maintenance leaves the time savings intact.

Only once those questions are answered should you look at extending the solution to new edge cases or adjacent workflows.

How to get started in practice

Pick three repetitive tasks your team performs and document each one: frequency, time taken, data sources, logic rules, known exceptions, and the cost of an error.

From those three, pick the process that occurs frequently, runs on clear rules, uses accessible data, and can be tested safely within a limited scope.

It does not need to be flashy. The primary purpose of your first automation is to prove your organisation can measure a process, model it cleanly, and maintain it over time.

At Dock, we build automations, integrations, and AI solutions starting with your actual process and data, not specific vendor tools. If a standard integration solves the issue cleanly, we do not add an AI model just because we can.

If you have several candidate processes and are not sure where to start, get in touch. We can review their frequency, cost, risk profile, and data readiness to identify the right scope for your first rollout.