Attended or unattended is the first architectural decision on any RPA build, and it is often made by default. The licence that was already bought, or the demo that was seen, decides it. That is backwards. The process should decide, because the choice changes almost everything downstream: where the bot runs, how it is triggered, how it handles an exception and what the user sees.
The two models, briefly.
An attended bot runs on a person's own machine, started by that person, usually while they are working on the same case. It is a power tool. The user stays in control, supplies judgement at the points the bot cannot, and sees the result immediately.
An unattended bot runs on a dedicated machine or virtual desktop, started by a schedule, a queue or an event, with no one watching. It is a batch worker. It processes transaction items from a work queue, handles what it can, and leaves exceptions for someone to review later.
Most platforms sell both and most mature programmes run both. The question is never which model the organisation should use. It is which model this process needs.
Six questions that settle it.
1. What starts the work?
If the trigger is a person deciding, in the moment, that this case needs the process run, the bot is attended. A service agent on a call who needs an address changed across four systems is the classic example. If the trigger is time, a file arriving, a queue filling or a system event, the bot is unattended.
2. Is there judgement in the middle?
Look for the step where a person reads something and decides. If that step is in the middle of the flow and cannot be moved to the start or end, the process either needs an attended bot, or an unattended one that pauses the item and routes it to a person through a human-in-the-loop action, then resumes. The second is more work to build and far more scalable.
3. How much volume, and when?
Attended bots are limited by the people who run them. Fifty agents each saving four minutes a case is a strong attended result. Twenty thousand records to reconcile overnight is not an attended job at all. Unattended bots scale by adding machines, and they work while the office is empty.
4. Can the bot get in?
Unattended bots need their own credentials, their own machines and a way through multi-factor authentication that does not involve a person's phone. If a target system enforces personal MFA with no service-account option, an unattended design will stall at the security review. Settle this before build, not after.
5. What happens when it fails?
In an attended bot, the user is there. The bot can stop, explain and hand back control. In an unattended bot, failure at two in the morning has to be caught by the exception design: retry transient errors, log and skip business exceptions, alert on system exceptions, and never leave an item half-processed. If the team has not yet built that discipline, an attended first bot is a safer place to learn it.
6. What does the licence actually allow?
Licensing differs by platform, and the numbers change, so check the current terms rather than relying on what was true last year. The pattern is consistent though: attended licences are per named or concurrent user and unattended licences are per bot runtime. Modelling the cost for the actual volume often changes the answer, in either direction.
The hybrid patterns worth knowing.
- Attended front, unattended back. The user kicks off a request and gets a reference number. An unattended bot does the heavy work and emails the result. The user is not tied to the screen.
- Unattended with action centre. The bot processes items until it needs a decision, creates a task for a person with the context attached, and resumes when the decision arrives. This is how most document-heavy processes end up.
- Attended as a safety net. Unattended for the standard cases, and an attended version of the same workflow for the exceptions a person has to rerun with corrections.
What we usually recommend for a first bot.
If the team is new to automation, an unattended bot on a stable, high-volume, rules-based process teaches the most: queues, scheduling, credentials, monitoring and exception handling all have to be done properly for it to work. If the sponsor is a customer-facing function and the win needs to be visible to agents, an attended bot wins hearts faster. Either way, make the choice from the six questions and write the reasoning in the solution design document, so the next team understands why.
The licence you own is a constraint on the second bot. It should not be the reason for the first.