Repetitive screen tasks that run by themselves and alert when they fail
I first check whether an API integration solves the case. Where there is no other way, I automate downloading and uploading data on portals with bots that log every run.
35questions on tasks, portals and credentials, in 8 minutes
A bot that does on screen what a person does today
Robotic process automation (RPA) mimics what a person does on screen: logging into a portal, downloading a report, copying data from one system to another. It is useful when the target system has no API.
It pays off on high-volume tasks with fixed rules and stable screens. When an API exists, integration is almost always better because it does not break with a design change.

Signs your company needs one
- There are people dedicated to copying data between portals
- Reports are downloaded from banks, the tax authority or customers every day
- The target system has no API
- Tasks follow fixed rules and repeat the same way
- Keying errors cause complaints
- Tasks pile up outside working hours
RPA: who it is for and when it does not fit
A good fit for
- Teams that download reports daily from bank, SUNAT or customer portals with no API
- Back offices that copy data from one legacy system to another, field by field
- Companies evaluating a commercial RPA platform that want to pick the first tasks well

Not a fit when
- The target or source system has an API: an integration is more stable than a robot
- The task requires judgement in each case and follows no fixed rules
- The portal changes its screen often or uses a captcha on every login
The cost of staying as you are

Hours on low-value tasks
Downloading, renaming and uploading files every day ties up people who could handle exceptions or serve customers.
Keying errors
A number miscopied on a government or customer portal is fixed through a formal procedure, not a click.
Dependence on one person
When that person is away, the task does not get done and nobody quite remembers how it worked.
How I assess RPA in four steps
Before writing a robot, I look for the API. Only tasks with no other way out and fixed rules move to screen automation.

I measure the tasks
Hours, errors, volume and portals of each candidate task, over two weeks.
I look for the API first
If the system offers an API or bulk upload, I integrate; the bot is kept for what has no other route.
I document and build
Step by step with exceptions, and a bot with logging, retries and an alert if the screen changes.
I run and measure
Successful and failed runs per week, hours saved and a manual fallback procedure.
What your company provides for the robotic process automation project

A recording of the task
A video of the person doing it today, including the odd cases they meet during the month.
A dedicated service account
A portal user in the robot’s name, not an employee’s personal password.
A machine to run on
A server or virtual machine with portal access and a schedule agreed with IT.
Current task time
How often it is done each month and how long it takes, to compare later.
From assessment to implementation
Task selection
An inventory of repetitive tasks with hours, rules and the recommended route: API or bot.
Browser automation
Bots for portals without an API, with their own user, logging and failure alerts.
Commercial RPA platforms
Requirements, comparison and bot design when a platform with an orchestrator makes sense.
Diego Muñoz
I implement screen-task automation with browser automation (Playwright and similar) for portals without an API, and I first check whether an API integration solves the case better. For commercial RPA platforms, I help you choose and design the bots.
I implement this type of system
Take the assessmentMarket options
RPA platforms differ in their orchestrator, cost per robot and desktop application support; open source covers the web well.
Other platforms I assess
- UiPath
- Automation Anywhere
- Microsoft Power Automate Desktop
- Blue Prism (SS&C)
- Playwright / Selenium (código abierto)

Selection criteria
- Number of tasks, portals and runs per day
- Need for an orchestrator, schedules and work queues
- Tolerance to screen changes
- Credential handling and a log of every run
- Per-bot licensing versus open source
RPA: limits and alternatives
Fragile robots
A screen change on the portal stops the robot. That is why each one alerts on failure and has a manual fallback procedure.
Commercial RPA platforms
On UiPath or Automation Anywhere I help choose and design the robots; you contract the licence and its operation with the vendor.
Portal terms of use
Some portals forbid automated access. Their terms are checked before building.

Which other systems it connects to

Integration platforms (iPaaS/ESB) and APIs
The API comes first; the bot covers what has no API.
See the systemBusiness process management and workflow
The bot does the screen task within a flow with owners.
See the systemArtificial intelligence and agents
AI reads documents without a fixed layout and the bot loads the result.
See the systemEnterprise resource planning
Each task’s output flows into the ERP automatically.
See the systemDocument and enterprise content management
Downloaded reports are stored and classified.
See the system35 questions and 8 minutes to see where to start
This assessment reviews the tasks your team repeats on SUNAT, bank and client portals, and how existing bots operate. The questions describe observable situations in rules, input data, execution, measurement and access.
Scored dimensions
- Task selection and design. It looks at whether the task to automate follows fixed rules, is written step by step with its exceptions and was first compared with an API or a bulk upload.
- Input data and destination. It looks at whether the data the task needs arrives complete and in a fixed format, and whether the result, such as a downloaded report or a filing status, enters the system that uses it automatically.
- Execution and portal changes. It looks at where bots run, whether they stop and alert when a portal changes its screen and whether a failure reaches the owner with the error detail.
- Measurement and manual backup. It looks at whether hours, runs and errors are measured before and after automation, whether each bot has a business and a technical owner and whether someone can still do the task by hand.
- Bot identity and traceability. It looks at which user the bot uses to log into SUNAT, banks and portals, where its password is kept, whether each run leaves a readable log and whether a mid-operation failure avoids duplication.
What you receive
At the end you receive your automation level across five dimensions and the gaps ranked by weight. Each gap points to a first action your team can check.
17 scored questions and 13 context questions (type of operation, size, current system). Context questions are not scored: they let us read the result against similar operations.
Free of charge. Only Diego Muñoz sees your answers.

Before you start

I build browser automations with open-source tools such as Playwright. If your company prefers a commercial RPA platform, I help you choose it and design the bots.
The bot detects that it cannot find what it expects, stops and alerts the owner. It is fixed, tested and runs again; meanwhile, the manual procedure covers the task.
The bot should not use a person’s password. It gets its own user with minimum permissions, and the password is kept in a secrets manager, not in the code.
The online assessment and the 30-minute review with Diego are free and carry no commitment.
Only Diego Muñoz sees them, to prepare the review. They are not shared with third parties or used for bulk mailings.
Review your RPA case with Diego in 30 minutes
Diego Muñoz replies in person, on Lima time. If you have taken the assessment, he comes with your answers already read.

WhatsApp +51 919 488 260 · damunoz@dmunozgroup.com