Robotic process automation services start with a first bot, and that bot should be scoped on what will break it in month two and on what it will do. Provider guides cover cost and selection at length. Failure gets a general explanation, and the scope items that prevent it get little space. Six of those items follow. Every one answers a failure you can see coming: a screen that changes, an exception nobody owns, and a licence with no line for upkeep. A short definition comes first.
What do robotic process automation services include?
Robotic process automation services find a repetitive task, build a software bot to run it through the screens a person uses, and keep the bot working. An engagement covers process discovery, plus build and deployment, with monitoring and maintenance after them. Providers may also supply the bot licence and the control room.
Five stages sit inside most engagements. Discovery documents the steps, the rules, and the people who own them. Build creates the bot, and deployment puts it on a machine. Monitoring watches the runs, and maintenance fixes the bot when something changes.
The discovery stage deserves more weight than buyers give it. A bot copies a process exactly, so a process with unwritten rules produces a bot with gaps. A day spent with the person who does the task today saves weeks of rework. Ask to see the discovery document before the build starts.
Buyers meet several names for the offer. RPA services, RPA consulting services, and RPA development services overlap, and a provider may use all three on one page. Read the stages in the proposal and skip the label, then check which of the five are priced.
Burhani's robotic process automation work covers stable tasks executed through existing screens. Cost structure is a separate subject. A post on RPA tools compared covers what you pay for, so this guide leaves it alone. Day 40 is the concern here, once the pilot glow has faded and the first screen change has arrived.
If your question is wider, our post on what process automation is explains where RPA sits among the other kinds.
How do you scope the first bot in robotic process automation services?
Six items make up the scope: process discovery, stable screens, the exception queue, maintenance effort, the bot licence, and control room monitoring. Each item blocks a failure that appears in month two. Skipping any of them prices the build and leaves upkeep to chance.
Scope item
What to define
What breaks in month two
Scope item: Process discovery
What to define: Steps; rules; inputs; process owner
What breaks in month two: The bot automates a process nobody agreed on
Scope item: Stable screens
What to define: Which screens the bot uses and who can change them
What breaks in month two: A screen change stops the bot
Scope item: Exception queue
What to define: Where failed items go and who clears them
What breaks in month two: Failed items pile up unseen
Scope item: Maintenance effort
What to define: Who fixes the bot after a change and how fast
What breaks in month two: No one owns the upkeep
Scope item: Bot licence
What to define: Attended or unattended run, and the licence line
What breaks in month two: Licence scope fits a pilot only
Scope item: Control room
What to define: Who monitors runs and receives alerts
What breaks in month two: Failures found by users
The two items to settle first are discovery and the exception queue. The first decides what the bot does, and the queue decides what happens when it cannot do it. The other four follow once those are written down, so start there. Here is an illustrative scope line for maintenance. The vendor fixes a screen-change failure within 1 working day of the alert, and a named person on your side approves the fix. Another line covers a release calendar: the application team warns the bot team 10 days before any interface change.
Describe failures without percentages. No verified failure rate for first bots is available to us, and several pages quote one name with no source. The scope should rest on a list of causes.
Take stable screens as an example. A bot reads and clicks fixed positions or fields, so a changed label or a moved button stops it.
What should the scope say about exceptions?
UiPath's Orchestrator documentation separates two exception types. An application exception is a technical issue, such as an application that does not respond, and a retry can solve it. A business exception means the data is incomplete or missing, and it is not retried by default. Assign an owner for each.
The UiPath Orchestrator documentation gives an example. A project extracts phone numbers from an employee database and enters them into a financial application. A freeze in the application may clear on a retry. A phone number missing a digit never will, and the documentation suggests notifying a person.
The page describes one vendor's platform. The principle applies in other tools, because a transient fault and a bad record call for different responses. A bot that retries a bad record forever wastes runs and hides the problem.
An exception queue is the place where failed items wait. Give it a named person who clears business exceptions, and a time by which they must act. A human review step is the usual answer for items the bot cannot process, and the bot passes each item on with the reason attached.
Exceptions are the most specific section of any RPA scope, so write the section before the build starts. The section decides whether the bot's failures reach someone who can fix them.
What breaks a bot in month two?
A bot built on screens breaks when a screen changes, when an exception queue fills with no owner, or when nobody watches the control room. These are scope failures and not build failures. The table has a line for every one, and any of them can be priced before work starts.
A screen change is the easiest to picture. The application vendor updates the interface, a field moves, and the bot stops at 2 a.m. The fix is small, but finding the fault takes someone who watches the runs, and the maintenance line needs a named owner.
A full queue is quieter. Items fail and wait. Nobody clears them, and the business assumes the bot is working. A month later, a manager notices that a process has been stuck for 3 weeks. No one was careless, but no one was assigned. The third is an unwatched control room. That console schedules and logs the bot's runs, and with nobody assigned to read it, a failed run looks the same as no run. Alerts need a recipient.
The examples are illustrative and map failures to table rows. None describes a Burhani project.
What should the bot licence and control room line cover?
State whether the bot runs attended or unattended, and name the licence line for that mode. Name who monitors the control room, how alerts reach them, and what response time applies. The RPA tools post explains the cost structure. The item only needs to be named and priced in the quote.
An attended bot works beside a person, who starts it on their own machine, while an unattended bot runs on its own schedule with nobody triggering it. The two need different licences. A quote that does not say which one it prices has left a gap you will pay to close. Suppose a pilot runs 1 attended bot for 2 users. Moving it to a nightly unattended run changes the licence line, so ask for both prices up front.
The control room line has three parts: who reads the runs, how an alert reaches them, and how fast they act. Put each part into the support terms. A response time with no owner is a promise nobody keeps.
Keep the item brief, and make sure it appears.
That item closes the six with the two lines that recur every month. Do not skip it, because bots run all month, and every run needs a licence, a log, and a reader.
Where does Burhani Technologies fit when you buy RPA services?
Burhani Technologies owns stable tasks executed through existing screens in its RPA work. A task that needs judgement on every item is a poor first candidate, and we say so at discovery. Our engineers work with platforms such as UiPath and Automation Anywhere. Process discovery comes first, then scope and quote. We make no partnership or certification claim here.
→ Describe the task, the screens it uses, and who owns the exceptions, and book a free consultation.
FAQs on robotic process automation services
What are robotic process automation services?
The service finds a repetitive task, builds a bot to run it through the screens a person uses, and keeps the bot working. First comes discovery and build, then deployment, with monitoring and maintenance after. Together they make up the usual stages. A good scope prices all five. The proposal also names the owner of the upkeep. Ask for both.
What is an exception queue in RPA?
An exception queue is the place where items wait after the bot fails to process them. A named person clears the queue, and a time limit says how soon. Without both, failed items pile up unseen, and a process looks automated while its backlog grows.
What is the difference between a business exception and an application exception?
An application exception comes from a technical issue, such as an application that does not respond, and a retry can solve it. Incomplete or missing data causes a business exception, which UiPath does not retry by default. A person usually has to correct the data. Name an owner for each type.
What is an unattended bot?
An unattended bot runs on its own schedule with no person triggering it. A control room starts the run and records the result, then raises an alert if the run fails. The bot needs a licence for unattended use and a person who reads the alerts.
Why do bots break when a screen changes?
A bot clicks and reads fixed positions or fields. When a label moves, a button changes name, or a page loads a new layout, the bot no longer finds its target and stops. Maintenance fixes the fault, so the scope should name who maintains the bot. It should also say how fast that person responds to a change in the screens.
What is an RPA control room?
An RPA control room is the console that schedules bot runs and logs them, with monitoring on top. The console shows which runs passed, which failed, and why, and it only helps if someone reads it. Assign an owner and a response time.
Which failure will you scope for first?
Scope the exceptions, the upkeep, and the monitoring before the build, and the first bot has a month three.
→ Describe your first task and get in touch.
