AI process automation – where to start?

AI process automation is best started with repetitive tasks based on clear rules and delivering a measurable effect in time, costs or error rates. The most common barrier at the outset is often not the technology itself, but a lack of order in describing how the process actually works and where the “manual” work accumulates. For this reason, the first step is to diagnose how teams operate and choose 1–2 initiatives that can be delivered quickly and fairly measured for results. The key is to build a baseline (how much time and how many errors the current process costs), so that ROI can later be calculated reliably. Equally important is establishing whether AI is meant only to recommend, or to act with human approval (human-in-the-loop), because that determines the risk and the approach to implementation. Below are practical criteria and a way of selecting the first processes for automation.

Diagnosis and selection of processes for automation: what should you automate first?

First and foremost, it is worth automating tasks that repeat often, have transparent rules and deliver a measurable effect (time, costs, errors). The simplest start is to inventory the 20–50 most common tasks in the company and describe them as: input → decisions → output. This notation quickly shows where work boils down to routine (e.g. copy-paste, transcription, formatting) and which elements of the process can be separated and handed over to automation. In practice, a simple, consistent task-description structure works well, allowing candidates to be compared against the same criteria.

• Collect tasks from the areas of sales, customer service, finance, HR and IT, and break them down into short steps (input → decisions → output).
• For each task, add: frequency, average time, error risk and the systems used to carry it out.
• Conduct 10–15 short interviews with the people doing the work, asking about the most tedious steps and the places with the highest number of corrections.

Most often, the “first winner” turns out to be the quadrant from the value vs difficulty matrix: high value and low difficulty, because it helps maintain implementation momentum. A good example of a quick initiative is automatically summarising conversations and creating notes in the CRM, or classifying emails into the right queues together with a suggested response for approval. To avoid making decisions on intuition, it is worth calculating the cost of manual handling as a baseline: (time per case × number of cases) + error cost + delay cost (SLA). Without a baseline, it is difficult to assess ROI credibly later, because you do not know what exactly improved.

The choice of process should end with a precise definition of the goal, i.e. indicating exactly what is to count as the result (a decision, document, system entry, customer response or recommendation). At the start, it makes sense to choose a “human-in-the-loop” model, where AI proposes and a person approves, and only later consider full automation. At the same time, appoint the business owner of the process (PO) and the minimum set of roles needed to deliver and maintain it (process owner, analyst, integration/automation engineer, security specialist). Finally, translate the assumptions into a backlog with acceptance criteria and a definition of “done”, so that you select a maximum of 1–2 projects to start and carry them through to completion.

1. 01Task inventoryList 20-50 of the most common tasks.
2. 02Process structureDescribe: Input → Decisions → Output.
3. 03Detect routineLook for: copy-paste, transcription.
4. 04Quick winChoose: high value, low difficulty.

The best start is automating repetitive tasks with high value and low implementation difficulty.

Criteria for selecting processes: volume, variability, risk

The best processes to automate first combine high volume, low variability and moderate business risk. High volume means many similar cases (e.g. hundreds of tickets per week), which quickly translates into time savings. Low variability means repetitive scenarios and similar input data, making it easier to maintain a stable level of quality. Moderate risk makes implementation smoother, because errors can be detected and corrected more quickly.

If you are wondering whether AI is “suitable” for a given process, first check whether the output can be verified quickly and whether you have historical data for comparison. A good starting point is classifying emails into queues and suggesting responses, with a person approving before sending. This approach balances speed with quality control and reduces reputational risk. A simple, practical question also helps with the choice: is the automation supposed to create a decision/action straight away, or is a recommendation for a person enough at the outset.

At the beginning, avoid automating areas with low error tolerance and difficult verification, especially without mature governance. If a process can lead to incorrect settlements, contract breaches or legal risk, design safeguards such as validations, limits and an approval requirement. In such cases, it is safer to start with analytical support and draft generation rather than “autopilot” decision-making. This builds trust, gathers feedback and only then gradually raises the level of automation.

Analysis of manual cost and setting the baseline

You establish the baseline by calculating the real cost of the current, manual execution of the process before you automate anything. In practice, this includes (time per case × number of cases) as well as the cost of errors and delays linked to the SLA, so that you do not overlook the “hidden” corrective work. Without a calculated baseline, it is not possible to assess ROI fairly later, because you do not have a reference point for comparison. Such a measurement should be based on data from the systems in which the process actually operates (e.g. helpdesk, CRM, ERP), rather than on declarations alone.

The simplest way to start is with one process path and calculate it using data from the last month: case volume, average handling time and typical mistakes. For example, the baseline might look like this: 600 enquiries per month × 8 minutes = 80 hours, which corresponds to approx. 0.5 FTE and gives a clear starting point for discussing return. When the team asks “is it worth it?”, it is precisely the baseline that helps you see where time is being lost and which elements (e.g. errors, SLA breaches) are adding to the cost. Only once you have that on the table can you sensibly set the automation goal and the metrics you will later compare 1:1.

1. 01Measure manual timeTime × number of cases
2. 02Account for errorsCosts and SLA delays
3. 03Set the baselineROI reference point
4. 04Use dataReal data, not declarations
5. 05Monthly example600 enquiries × 8 min ≈ 80h (0.5 FTE)

Set a realistic baseline to assess the ROI of automation fairly.

Mapping user pain points: how does AI save time?

AI saves time when it eliminates the most tedious, routine parts of work, which today boil down to “clicking” and manual retyping between systems. The surest way to identify such areas is to conduct 10–15 short interviews with people carrying out the process and ask directly about the steps that are most tiring, require the most rework and involve the most data handoffs. The answers usually feature tasks such as copy-paste, formatting and retyping data, which are well suited to automation at the level of individual stages. A good signal that automation is worth targeting is the presence of custom Excel macros or ready-made email reply templates.

Mapping pain points works best when you combine the “employee voice” with the specifics of the process: where the input is, what decisions are made and what the output is, and then identify which steps are pure routine. This makes it easier to decide whether the goal should be only a recommendation for the person, or a draft version (e.g. a suggested reply) for someone to approve. This approach aligns expectations and allows you to design acceptance and exception handling where users most often correct the result. As a result, AI supports work in the most expensive parts of the process rather than “tacking itself on” to stages that are already fast.

Identification of data sources and permissions: how to prepare the foundations?

You will prepare the foundations once you have first listed all the systems the process uses and then defined roles and permissions for them. In practice, this means a map of data sources such as CRM (e.g. Salesforce, HubSpot), ERP (SAP, Dynamics), helpdesk (Zendesk, Jira Service Management) and document drives and repositories (SharePoint, Google Drive). At the same time, assign data owners and access rules so it is clear from the outset who is responsible for the quality and sharing of information. AI does not need access to everything — grant the minimum access, per use case, with auditing and a list of roles (RBAC).

To avoid uncontrolled “spreading” of access, assign permissions to specific process steps and describe what data is needed as input and what is produced as output. This approach makes later integrations easier and allows you to better control who read the data or launched automations, and when. It also clarifies responsibility: data in CRM is managed differently from data in ERP, and differently again from a knowledge base on a drive. As a result, preparation for automation does not end with “connecting the tool”, but with a conscious design of access for a specific process goal.

1. 01List all systemsMap data sources (CRM, ERP, drives).
2. 02Define roles and permissionsAssign owners and access rules.
3. 03Minimum access (RBAC)Grant access only to necessary data.
4. 04Permissions in the processAssign access to specific steps.

The key is a clear map of systems and precise, minimal role-based permissions to ensure data security and quality.

Data quality: completeness and consistency are the key to success

The quality of automation is determined by data completeness and consistency, because AI will not fill gaps in records or reconcile conflicting formats. If CRM is missing statuses and tickets have no categories, the model starts to “guess”, which directly reduces the predictability of outcomes. The most common sources of discrepancies are different date formats, different product naming conventions and duplicate customers across systems. If AI results are inconsistent, the problem is very often not the model, but the input data.

To quickly assess data health, carry out a short quality audit: take 100 random records and count the missing values in key fields. This gives you a clear answer on whether you first need to fill in fields, standardise naming or reduce duplicates before automation starts working reliably. This test also works when comparing results over time, because it lets you measure progress in data cleansing step by step. Only with a clean input is it easy to maintain a repeatable automation effect in processes based on CRM, ERP and helpdesk systems.

Choosing the technology: LLM, RPA, rules or BPMN?

It is worth basing the choice of technology on the type of data and the predictability of the process. Simple rules work best where the logic is unambiguous and can be expressed as conditions (e.g. “if the amount > 10,000 PLN, escalate”), because they are cheaper and more predictable than a language model. LLM makes sense when you work with natural language and unstructured inputs, such as emails, conversations or documents with multiple content variants. Not everything requires an LLM — often the fastest and safest way is to start with rules where they can be clearly defined.

Choose RPA when the process requires working in applications without an API or with limited access, because its job is to perform “clicks” and entries in the interface. In practice, RPA and AI often go hand in hand: AI can extract information from an email or invoice, and RPA can enter it into the system and save the reference number. If the process is long, has many stages and exceptions, BPMN or workflow help control the flow, error handling and transitions between steps. This approach organises automation so that it is not a “pure chat”, but a repeatable flow with control.

Assess the final choice of tools through the prism of costs, security and later maintenance, not just the licence price. When calculating the total cost, include monitoring, updates, prompt versioning and regression tests, because in practice these determine stability over the longer term. If you are considering SaaS and self-host, bear in mind that SaaS shortens the time to launch, while self-host provides greater control over data and at larger scale can reduce costs. It is also worth deciding from the outset who will be the operator of the solution (IT, data team or the business), because this affects the pace of change and the maintenance model.

MVP instead of a “big transformation”: how to start with AI?

Start with an MVP, that is, a minimum automation handling one specific case with a measurable effect. A good MVP has a clearly defined entry point, an unambiguous output and manual approval, which reduces risk and allows you to quickly gather feedback from day-to-day work. A typical example is automatically summarising a ticket and preparing a draft response that a human approves before use. The MVP should be small enough to be implemented in 2–4 weeks and tested on real data.

Plan the scope of the MVP so that it consciously handles a limited number of variants, rather than trying to “cover everything” straight away. This way you will verify more quickly how the automation works in practice, where exceptions arise and which elements need to be clarified. When the MVP delivers value, only then expand it with additional paths, integrations and edge cases. This approach helps maintain the pace of work and make decisions based on results rather than assumptions.