The short answer
The processes to automate first are the ones that happen often, almost always follow the same path, have results that are easy to check and use data that already exists in digital form. Start with what combines high impact with simple execution, and leave for later what requires judgment case by case.
In practice, this usually points to typing and retyping data, cross-checking reports, classifying messages and documents, and reports built by hand. The first automation should be small enough to prove the gain with data from your operation, and the choice works better when it is made with the people who do the task every day.
Five criteria for choosing what to automate
Before thinking about tools, rate each candidate task against five criteria. None of them decides alone, but together they separate the automation that pays off from the one that becomes a never-ending project.
- Volume. How many times the task happens per day, week or month. A task of a few minutes repeated hundreds of times weighs more than a long task done once a quarter.
- Repetition. Whether the task almost always follows the same path. The fewer the exceptions, the simpler the automation and the lower the risk.
- Clear rules. Whether the task can be explained as "when this happens, do that". If the team can't describe the rule, the first job is to agree on it, not to automate it.
- Cost of error. What happens if the automation gets it wrong. An email sorted into the wrong queue is fixed in seconds; a duplicate payment is not. Cheap errors are good for getting started.
- Available data. Whether the information already exists in a digital, accessible form, in a system, spreadsheet or email. Data that only exists on paper or in someone's head calls for another step first.
It is worth adding a sixth, less technical point: the team's willingness. The question "which task would you like to stop doing by hand?" usually reveals the candidate with the biggest gain and the least resistance.
Prioritization matrix: impact x ease
With the criteria in hand, you can place each task in a simple matrix. Impact comes from today's volume, time spent and cost of error. Ease comes from clear rules, repetition and available data. A score from 1 to 3 on each axis, given together with the team, is enough for the conversation.
| Quadrant | How to recognize it | What to do |
|---|---|---|
| High impact, high ease | Frequent task, clear rules, data already digital | Start here. It is the best candidate for the pilot. |
| High impact, low ease | A task that weighs heavily but has many exceptions or scattered data | Plan in stages. Organize the data or agree on the rule before automating. |
| Low impact, high ease | A simple task, but rare or quick | Do it when there is time to spare, or bundle it with another automation in the same flow. |
| Low impact, low ease | A rare task, full of exceptions and judgment calls | Leave it out for now. The effort doesn't pay off. |
The matrix doesn't need to be precise, it needs to be honest. The most common mistake is rating a task as easy when it only looks simple because an experienced person resolves the exceptions in their head. That is why the mapping is done with the people who perform the task, not just with those who manage it. In the initial study, we map what is repeated, how much time it takes and where errors happen before proposing any automation.
Examples of processes to automate by department
Tasks change from one company to another, but the pattern repeats. The examples below are generic and serve as a starting point for your own map:
| Department | Candidate task | Type of automation |
|---|---|---|
| Finance | Posting bills that arrive by email and checking them against the purchase order | AI to read the document, a rule to check the amount, an integration to post it |
| Customer service | Classifying messages and tickets by subject and urgency and summarizing the history | AI to classify and propose a reply, with a person answering |
| Operations | Cross-checking reports from different systems and flagging discrepancies | Rules and integration between systems, without AI in most cases |
| HR | Checking onboarding documents and flagging what is missing | AI to read the documents, a rule for the list of what is mandatory |
| Documents | Extracting data from contracts, invoices and forms into a record | AI to extract the fields, human review before saving |
| Management | Building the monthly report by pulling numbers from several sources | Integration and automatic reporting, with no spreadsheet in between |
Notice that most of the examples don't depend on AI, or use AI only in the reading step. The difference between the two types is explained in how to automate processes with AI. Sometimes the report built by hand disappears because the system itself starts producing the number: in the patient management system we are building, the reports that used to end up in spreadsheets come out ready on the management screen.
Checklist for the automation pilot
Once the task is chosen, the pilot needs a few definitions before it starts. Without them, it ends without anyone being able to say whether it worked:
- A single task. The pilot covers one process, with a clear beginning and end, not an entire department.
- Today's numbers. Volume, time per task and amount of rework measured before changing anything.
- Success criteria. What needs to happen for scaling up to be worth it, agreed before the test: time saved, accuracy rate, errors avoided.
- Data from the operation. Examples taken from day-to-day work, including hard and out-of-the-ordinary cases, not just the neat examples.
- A responsible person. Someone on the team who reviews the suggestions, approves what goes out and is accountable for the result.
- Review point. Where the person steps into the flow, and which actions never happen without approval.
- Personal data handled. What can be sent to an AI model, what is anonymized and what is recorded, in line with Brazil's data protection law (LGPD).
- A date to decide. An agreed deadline to look at the numbers and decide: scale up, adjust or stop.
Stopping is also a result. A pilot that shows the task isn't worth it avoids a bigger investment in the wrong direction.
What not to automate (at least for now)
Some tasks look like good candidates and aren't. It is worth leaving them out of the first cycle:
- A process nobody can describe. If each person does it their own way, automating only makes the confusion faster. First the rule gets agreed on.
- A decision that calls for judgment in each case. Assessing a sensitive complaint, negotiating with a customer or deciding on someone's rights stays with a person. AI can prepare the material, not decide.
- A rare task. What happens only a few times a year rarely justifies the effort of building and maintaining the automation.
- A process about to change. If the rule is going to change next quarter, because of a law, a reorganization or a system replacement, wait for the change.
- Data that can't leave the environment. Sensitive information without a clear handling rule stays out of any AI model until that rule exists.
This doesn't mean these tasks will never be automated. It means their first step is a different one: organizing the process, agreeing on the rule or structuring the data. When the obstacle is an old system that doesn't talk to anything, the path goes through modernizing the legacy system.
After the first automated process
With the pilot approved, the next task on the list goes through the same cycle: map, measure, build, check the gain. Each new automation builds on what the previous one left behind, such as integrations, rules and the record of what was approved, and so it tends to come out faster.
That is how we run automation and artificial intelligence projects: one working automation per cycle, tested with data from the operation and with human review wherever there is a decision. If you are still torn between two or three tasks, tell us which ones they are. The conversation alone helps build the matrix.