UiPath Reviews

I started my RPA journey as a developer, and I first heard about UiPath as a low-code, drag-and-drop automation platform. Back then, it was very much in the beginning stages of its development. Ever since then, I've seen it evolve quite fast. I would say even faster than other RPA platforms that I've used, in just a few years.

Thinking back to when I first started using it, there are many new features and updates and it's my preferred platform for RPA.

We primarily used unattended automation, where you deploy the bots to work autonomously. This is unattended, end-to-end automation with no human in the loop, other than providing the inputs or checking the outputs.

We have several use cases, but our main one is reducing manual work. The processes that require a lot of manual input and have a lot of human error are the focus. That could be, for instance, processes that have to do with invoicing, billing, reporting, and coding, which require a lot of man-hours, are very reliant on a human being available, and are time-sensitive. Those are the ones that are on the top list to be automated.

Beyond that, I can't specifically talk about the processes that we've automated.

UiPath helps to implement end-to-end automation, although the discovery of processes, gathering requirements, and creating the design, all happen outside of UiPath. But the development, which is developing the bots, then testing and then deploying them, does happen end-to-end within UiPath.

The end-to-end development capability is important, but this is because every tool offers this and it is expected. That said, there is definitely room for improvement in that end-to-end should include process discovery. It is end-to-end, but those ends can extend further than what it currently is. In that sense, it's no different than other RPA tools.

Another way that UiPath improves the way our organization functions is that the robots can run 24/7. If you think about a human workforce, they work eight hours a day, they take days off, they get sick, they leave, and they take knowledge with them once they leave the company. But, the robots can be run non-stop 24/7, and each process can be scaled up. The same process can be run by one bot, or it can be run by 10 or 100 bots. This means that there's a lot more flexibility that the bots bring, especially for high-volume processes that perhaps even have some peaks, such as an end-of-month rush to produce invoices or meet a deadline or an end-of-financial-year crunch.

These robots have an easier time addressing and variability when it comes to volume. They really create a lot more scalability to where businesses can grow and know that they can meet the demands of the future. So, they're a lot more future-proof, whereas people are harder to rely on.

Speaking from a business perspective, it's the FTE savings. A company obviously needs to spend money on UiPath licenses and development costs, but those costs are oftentimes lower than the cost of that FTE, the full-time employee, whose work is getting automated. If you purely just think about the financial benefits, it's the lower staffing costs.

There is also the ability to free up people. This means that even if people aren't replaced and their salary isn't saved, what they can do is pivot their focus to, for instance, be a lot more customer-facing or do a lot more strategic or creative tasks that perhaps get pushed to the side because there's not a lot of time allocated towards performing them. Now, FTEs have a lot more capacity to contribute and perform tasks that still to this day cannot be automated, like creative thinking, complex decision-making on the spot, strategy, and just human interaction.

In the beginning, employees meet automation with a critical eye. They're thinking, "Well, what's going on? Why are these robots coming in? Are we going to work alongside them? How is this going to work?" But to be honest, in the end, there are winners and losers. What I mean by that is that some jobs are replaced, and that's just simply because of that FTE saving that is usually the driver to justify the cost of development. But on the flip-side, the employees that do stay and do work alongside the bots are usually a lot happier because they have to juggle a lot fewer things.

The robots are there to make people feel like people and not like robots, where they just do the same thing over and over and don't enjoy their job or don't enjoy what they do. A robot takes that away and helps people enjoy their work a lot more because they can do non-repetitive tasks. They can be a lot more customer-facing and perhaps build stronger relationships with their customers, know them better, and have more time available to work on other projects or work on other things that they may never have had the time to do.

In our organization, the robots work on multiple projects. The amount of employee time that is freed up depends on the project and what you are automating, but a pretty good estimate would be a 20% to 40% savings.

With respect to the reduction of problems related to human error, the fact of the matter is that some employees, whether you like it or not, are more error-prone. By automating a process, we were able to standardize it, and therefore, identify the cause of the human error and remove it by replacing the process with a robot that makes a more reliable judgment in terms of action. It is literally just an if-else statement. It's a lot easier to quantify and therefore it's a lot easier to evaluate, and therefore the result is a lot more reliable. Whereas with an employee, let's say the output of their work is a lot more unreliable simply because they could be working on 10 different things on the same day. There could be a deadline approaching, and the quality of work fluctuates with an employee because of it.

With a robot, you will notice that over time, in fact, the quality improves, and that's just the basic truth of RPA. It doesn't happen automatically, and it does require work. It happens because you see the results of the automation and you see areas for improvement, ultimately leading you to make adjustments. You iterate on the RPA solution and make it better over time.

Although it does not improve automatically, through a conscious effort you can be a lot more confident in the output and then be able to see unbiased results at the end of the day. Part of these results is your exception rates, which can be errors. It can be failures, whether technical in nature or decision-making business rule types of errors. Then, you can adjust your process to where it can positively improve that exception rate, and just iterate on that to where it becomes acceptable. Moreover, it's quite stable, which is not the case with the human workforce.

The automation cloud Orchestrator has its benefits and negative sides. The benefit is the fact that it's web-based. A person who has the login credentials can access it without the necessity to have something installed. The development and the monitoring of the bots are separated in UiPath, where the development happens in the Studio and the monitoring happens in the Orchestrator.

In other tools like Blue Prism, it happens in the same place. I've used both, and the Orchestrator is nice. It has a very nice UI, it's user-friendly, it has a lot of features, and I find it quite easy to use. For example, you can see all of the machines, you can see the robots, and you can schedule them. If the business wants to see a lot more across the output of the Work Queue, they can have that visibility from Orchestrator, which is great.

The downside of Orchestrator is the package deployment, which is perhaps another minus of UiPath in general. The deployment of a new package does not take a long time, but there are a lot of steps. It's not an intuitive process. If you have to release a lot of packages, which does occur, especially in the early stage of deployment, when you are releasing hotfixes, or when something goes wrong and you need to redeploy a fix really quickly to minimize business impact, it does slow you down.

I wish it would be just one or two clicks, rather than the whole importing or exporting and connecting to the desktop application and everything that accompanies it. I wish it were a lot easier. Again, it has its upsides but it's not perfect.

The best feature in UiPath is their robotic enterprise framework because that is an inbuilt processing framework for utilizing their work queues. It's plug-and-play, and already pre-built to where you don't have to start from scratch. It's enterprise-grade and ready to be used. All you need to do is populate your dispatcher, create a queue, create a performer, and you're good to go.

The highest benefit of it is that it's just there, ready to use, and you don't need to start from a blank screen. You don't have to figure out, for example, how to create an environment where the robots can check if there's anything in the queue to be worked on. The framework is already there. The other tools that I've used, like Blue Prism, don't have that built-in quite as well.

My perspective and overview are from that of a developer, and I find that the recorder feature is really good. This is because UiPath lets you record your actions on the screen. So, if you want to interact with a web-based interface, for example, then you have UiPath record your actions and then build the activities that you would need in order to replicate those actions through the robot. It makes it a lot better and although it's not perfect and it does need to be reviewed and adjusted, it speeds up development quite a bit. This is especially true when it's basic back development like populating fields and clicking buttons and navigating on a web.

Compared to other RPA tools that I have used, something that stands out to me in UiPath is that it has a very extensive library of activities. Those activities are easy to search for and use.

When you are writing code, there is a feature called IntelliSense, which autocompletes your code. More specifically, when you're typing code, if you're starting to type the name of a variable, it will show you all of the variables available and you can just click them. It's very interactive and it's reminiscent of the Microsoft Visual Studio environment, both from the UI perspective and the coding perspective. This means that developers that are familiar with Visual Studio will probably feel right at home using UiPath. It's very developer-friendly and it's geared towards appealing to existing developers.

The UiPath Academy courses definitely help in the process of bringing employees up to speed. The Academy is the go-to place for UiPath learning and I think that other RPA tools are copying this model of disseminating knowledge, being a lot more open with training, making it freely available, and providing an online classroom. These are things that UiPath has always done, and it certainly helps new developers get upskilled in RPA, and specifically with UiPath.

When it comes to ease of use, UiPath is intuitive insofar as the basic features have a low learning curve. However, if you want to take full advantage of what UiPath can do, and if organizations want to create more sophisticated automation solutions, it is more difficult. For instance, automations involving back-end access, maybe writing directly to databases such as SQL or using API, that's a steep learning curve. In fact, I think the learning curve is exponential.

If you just want to make a robot that sends an email, that's really easy to do. But, if you really want tangible benefits, like if you really want something that solves a business problem, it is a huge learning curve and it takes a while to master. Obviously, it does have that low-code requirement, but I would say that's only for entry automation projects, like proof-of-concept or something along those lines. For something that really solves a business problem, you would need code, because that just makes it a lot more robust and a lot more powerful if you can custom-code certain steps of the process.

Features for process discovery would improve the end-to-end development capabilities.

From a developer's point of view, my biggest struggle with UiPath is debugging. The debug mode in UiPath feels clunky and it is a sore spot. It feels it's hard to control the flow of the process. There are a lot of internal errors and it's not intuitive. In general, debugging is not a good experience and I don't enjoy doing it. In contrast, Blue Prism has better debugging capabilities.

Blue Prism is a little more dynamic; you can adjust variables, you can jump around the flow, and it's easier to control. With UiPath, it's a little bit of a nightmare. It becomes harder to debug the bigger your automation is, because it's quite unpredictable, and it's quite unstable. Definitely, if debugging was improved, I would say UiPath would get 11 out of 10.

Something that I noticed recently is that they have moved to paid certification for developers, whereas it used to have free certification. This is a little bit outside of the platform itself but the pain point here from my perspective is that there is a barrier to entry for new RPA developers, or ones that want to renew their certification. It has become a lot harder and that used to be a differentiator for UiPath. It had a very strong online learning offering and it offered no-charge recertification on top. This is now very similar to what other tools are doing and I see that as a negative.

My first introduction to UiPath was in early 2018 or late 2017.

The robots could be a lot more stable, which is another area for improvement. The stability issue with UiPath is a prominent one, especially in comparison to other tools like Blue Prism. I feel that there are a lot of errors that are caused by the UiPath framework, as opposed to the robot design. Sometimes it's just very unreliable and crashes unexpectedly, which creates serious issues in terms of reliability. In early deployment, it always happens that it's very late nights, and there's a lot of babysitting processes. The robots need it because you never know what's going to crash.

In comparison with other RPA tools, it is average when it comes to reliability. I would rate other tools a little bit easier to manage expectations as to what you can reasonably expect to go wrong, and what you can reasonably expect to break. With UiPath, our developers, even our experienced ones, oftentimes get errors that we've never seen in our lifetime. This is partly due to the flexibility of UiPath, with it being so easy to adapt to all types of applications and all types of environments and it being so malleable. It is one of the most versatile tools; it's industry agnostic, platform-agnostic, and tool-agnostic, but that flexibility creates a lot more room for error in the code. It means that a lot more things can break or interfere with each other, compared to other platforms that are perhaps more niche and more targeted in what they're actually trying to solve.

UiPath is definitely scalable. It is modular, where you build a workflow and that can be reused across multiple robots or multiple processes. Those processes can then be run by one, two, three, five, and 100 bots, provided that they can work concurrently in the same environment, performing the same process. It's wonderful and the scalability is uncapped. If you have licenses, then you can use them, which is great.

The only limits are how many licenses are you willing to buy, and the inherent limits of your own infrastructure and your own process. It comes down to how many robots can realistically work concurrently in the same infrastructure and in the same network without breaking it.

We have approximately 20 developers who use UiPath. We have business users, but it is difficult for me to say how many there are.

I have been in contact with technical support, and I have experienced submitting a support ticket to them. I even got on a call with them and they were very helpful. We had been having issues with automating a platform and we wanted to get their specific insight as to what was going wrong. It had to do with UiPath not being able to extract selectors from that specific interface.

I was really surprised because they spent the time to not only address my ticket and answer my questions, but also to allocate time to schedule a meeting, and really look into the platform via screen share. I was sharing the screen with them and showing them what was happening, and they really looked into it and gave it a lot of attention.

I understand they get a lot of tickets, and I really felt they provided a good answer. They responded really fast, I would say within 24 hours, and we began exchanging details through a back and forth conversation.

They provided me with the outcome that I was happy with. It was a very good experience.

In addition to UiPath, we used Blue Prism and Automation Anywhere. UiPath is king here, and I rarely hear anything about the other two. I would estimate that we use UiPath 95% of the time, perhaps even 99%.

The alternative to UiPath that I am more familiar with is Blue Prism. From my perspective, UiPath is geared towards developers. The audience towards which it's skewed is the developer or the technical person. Blue Prism is geared more towards business people. It's geared towards converting business people, including SMEs and subject matter experts that know the process well, into developers. You will find that the language that each program uses is one that's geared towards the target market. Consequently, UiPath uses a lot of developer language and developer concepts.

For example, UiPath works similarly to the Visual Studio Environment. Blue Prism, on the other hand, uses a lot of flowcharting visuals, as well as the language that it uses for the same concept. It's going to use a definition that's more from a business process flowcharting realm. Recently, both platforms are converging onto each other and I feel like they're becoming more and more similar, but they still have a few things that are different.

One thing that stands out for me is that Blue Prism has wonderful debugging. It's a lot better than UiPath, and it's an all-in-one tool where the monitoring and the building of the robots happen in one application. The deployment is also really easy.

Blue Prism also offers online learning, which is great. They didn't use to have that offering, and I think that they got a lot of inspiration from UiPath. Their online courses have been great because previously when I was learning RPA, I had to use YouTube. Now, they have a whole Blue Prism university, which is amazing.

Blue Prism has inbuilt version control and a lot of other great features. They have a heavy emphasis on security and encryption, which UiPath perhaps needs to improve on. Companies such as banks, insurance agencies, and finance agencies are a lot more interested in Blue Prism because of its very strong security protocols. The encryption offering is a key requirement for companies that work with a lot of sensitive personal data.

I have never been involved in the initial setup, although my understanding is that it's quite a journey.

The areas of the organization with the most ROI from UiPath are operations, finance, HR, and sales. Those are the key departments, although it's across every organization because those departments have a lot of manual work-intensive processes that are the first contenders for automation.

We have a yearly licensing model that gives us access to the development and production environments. The cost of licensing is expensive.

Part of automation is the analysis and optimization of processes because the analysis phase is a by-product of wanting to automate a task. If you want to automate something, you have to break it down into parts and really look at it and think, "How can I reduce this into a series of business rules, a series of decisions, or series of steps?" It's an exercise of process optimization in and of itself because a good practice in automation is to not just take what it is and automate it, but to think, "Does what is currently in place actually work? How can it be improved? How can it be streamlined? How can it be done in fewer steps?" It's a good chance to practice some process review, improvement, and transformation.

The idea is to make it optimal because the current process usually has unquestioned practices that maybe haven't been reviewed for a very long time. A lot of businesses say, "We've always done it this way," and they've never thought to revisit the approach. RPA gives you an opportunity to think about whether what you've always been doing will work when it's being done by a robot. Most often, the processes get streamlined through the requirements gathering phase, understanding the as-is, and then a key part of that is doing the process design, which is the to-be vision.

During that time, processes go through a few design iterations where they are optimized and streamlined because we want the robots to be as efficient as possible. This means performing as few steps as possible without sacrificing value and efficiency. It is important because any inefficiencies in a robot are going to scale with the number of times you're going to run that process. If you run a process a thousand times, and let's say there exists inefficiency that results in an extra minute being used, that could be shed if you were to review and optimize that process.

Ultimately, optimization is an important exercise because the benefits include a further capacity to run more automated processes, and less time is taken up by inefficient steps.

Something to be aware of is that updates to the platform have to be managed because any update could impact the performance of a bot that was built with an earlier version. To avoid having a newer version impact the performance of something that was built previously, all of the updates need to go through a due diligence process.

The biggest lesson that I have learned from UiPath is surprising; not everything needs to be automated. It feels weird to say it because thinking, "Well, I have this platform, I have these bots, why not just automate absolutely everything?", but the truth is that there are things that can be streamlined outside of RPAs. Also, some processes can be automated through other means. Consider the very simple example of sending automated emails, or sorting out your inbox by putting the right email in the right folder, those types of things can be done with email rules rather than RPA.

If a platform already has some sort of inbuilt automation, whether that's a social media platform, email platform, networking platform, or any other type of platform, it's always better to explore that first before looking to solve that problem with RPA. There are times when an Excel Macro or an email rule will be a lot faster and a lot more cost-efficient. RPA should be directed towards big-ticket items, big problems, and large volumes to where no existing solution would provide the same level of value.

My advice for anybody who is considering UiPath is to try it out for themselves. The most beautiful thing is when companies take the leap to have a very small citizen developer team, where they upskill a few technically-minded people with free courses and try to build a small proof of concept to see if RPA is the right path for them. I really encourage that sort of curiosity and experimentation because all of the resources are out there and anybody can learn, as long as they're driven and passionate and curious about automation. I would really encourage people just to give it a try and see what comes out of it.

In our organization, UiPath is the number one RPA tool. Being close to the industry as a developer, and I do feel like it's the preferred tool, at least where I'm based in Australia. It is definitely the preferred RPA solution on the market. Our usage is definitely going to increase in the future. I feel like the future is bright for UiPath. That said, it isn't perfect.

I would rate this solution a nine out of ten.

We're mainly focused on finance for the time being so we've used UiPath for invoice processing and e-billing reconciliation. It makes sure that all of our converting information matches within our client databases. We've done a couple of solutions that track budget spend for certain clients, making sure that if the budget overruns or comes close to overrunning, then someone gets notified. If we get a new client or if a new legal case is opened, automation can make sure that all that information is then uploaded into our database. 

We've done a couple of smaller automations for the legal teams. These have been fairly basic ones though. There were a couple that download files from an email for them, and then rename them with the correct naming conventions, and saves them into correct drives. 

Another use case is to remove outdated users or information from our databases in line with the GDPR system.

In a general sense, UiPath has helped with data lineage, understanding where a process starts, who it rests with, and where it ends. It has made the process that we have automated a little bit more clear of which parts of the process are necessary, which are the parts that hold up the whole process, and which are the ones that are needlessly complicated.

For starters, it just helps give a bit more of an understanding of our processes once they're automated. Secondly, it's changed the way that we approach problems. We're tied into contracts that we might necessarily not want to be, but because we rely on the solution, we don't have a choice. Whereas, because UiPath is so versatile, we can use that to fill in gaps to take over processes, which otherwise in the past, we thought that only one specific tool could do for us. Now, we feel like we'd be less reliant on these specific tools to do a specific job. 

Third, a lot of teams are starting to understand that things can be automated. Whether it's in finance, HR, or even the legal teams, we started speaking to all the different teams and now they're bringing work to us and they're getting an understanding of things that do need to be done by a person and which don't. People aren't just doing work for the sake of it now. If they think there isn't a point to something and it can be automated, they bring it to us and we automate it. So, it's changed the way that we look at processes and don't just hardheadedly get someone to do it for no reason.

It checks our invoice stage for one of the processes that we do for e-billing. Previously, there wasn't anyone to check the financial data that we have in our systems against our clients and our recipients, and making sure that it all matches up. That process wasn't done at all so a month or two months later, a client would come back to us and say, "Hang on, you billed a strong amount or you've put our billing address wrong" which is obviously a little embarrassing. These things went completely unobserved for months. The client had to chase us, complain, and tell us we needed to fix it. Whereas now, it's more of a proactive approach rather than waiting for clients to come to us and tell us that we've done something wrong. We actually have the automation that can check and then validate those mistakes before they're even a problem and before they're spotted by anyone.

We're still in the early stages but we are starting to reach the point where UiPath is speeding up the cost of our digital transformation.

The digital transformation has made a couple of the lawyers' jobs easier by getting rid of the admin staff. It's freed up time and it makes things easier for everyone.

UiPath has definitely reduced our processing times as well. It really depends on the process but it has sped up. 

It has also decreased our error rates. At the moment we're looking to purchase an orchestration platform. At that point, we'll be able to collect more information about exact numbers and we'll actually have the analytics. 

The ability to use APIs within UiPath is really helpful. The web scraping is really great. It's so easy to use, it's very intuitive, and it's usually pretty consistent. When web pages change you need to update it, but it makes it quick. If you need to do another quick process, it's really easy to get it quickly and set something up. I can just scrape data from a website and save it somewhere.

The ease of building automation depends. UiPath makes things that are fairly simple but looks a little bit tricky in another language really easy. But if you're trying to do something really complicated, then sometimes it can be a little bit more tricky. It depends, sometimes it's really simple for fairly basic automations, I think it's fantastic. But when you want to try and get into the nitty-gritty and try and write your own code and then stick in there, it can sometimes be a bit difficult to use.

The documentation can be a little bit lacking. I think they improved it a little bit last month. Last time I checked, it seemed like they spent a bit of time trying to improve it. Sometimes some of the processes are nicely documented. UiPath offers training, which they provide on their website. They teach you how to use it, but for some processes, it just seems like the documentation isn't really there. It makes it a little bit difficult when you're using a specific process from the first time. 

If you're trying to invoke a method in UiPath, if you're trying to write a C# in there directly,  or if you need to do something which can't really be done in UiPath, but it can be done in C# or Python or something else, sometimes it's not that intuitive. It can be a little bit more complicated than it needs to be. I think that integration with other languages could be a little bit better.

We have been using UiPath permanently for around eight months, but we've been using it in-house for about a year before that.

UiPath itself is very stable because it interacts with so many different applications. I noticed in the past, at times, when using it with browsers, for example, using it with Google Chrome or Firefox, occasionally Chrome or Firefox will update and UiPath can take sometimes a week or two to update with it. For that week, you're able to use any solution that involves Google Chrome or Firefox, because it's waiting for that update. I've seen that happen with a couple of different applications, not as much recently. UiPath itself is very stable because it can interact with anything. If anything is updated and UiPath doesn't have time to update drivers to match that, sometimes you can get left a little bit stuck.

It's not really easy when you're using orchestrator to scale up and create a server, add a new bot, get a new license, and get it running. 

At the moment, it's just me using UiPath. I'm a developer and the architect for the solution as well. But we're planning to expand the team next year. 

We have a couple of processes that are running constantly, so I think we're using it as much as we can, and as much as our licenses allow. We're at a point now where we need an orchestrator to keep track and run everything at the same time. We're in the process now of purchasing that. I'll see where we're moving to, to expand quite far beyond that after we've got it. We're just at the point of ramping up.

I've sent a couple of requests to support when we needed licenses and when we changed to a different computer or a different user, and they got back to us really quickly and solved it within a day or so. I've been pretty happy with UiPath so far. I think every time I've sent a request to them, it's been resolved pretty quickly, and even if they couldn't resolve it super quick, the response times are usually within 24 hours or so, which is really good. I can't remember a time where we've been stuck in the dark with them.

I've used Automation Anywhere, but I haven't really used it within my work.

The initial setup was pretty straightforward. I implemented UiPath for a couple of years before I came to my current company. It was quite easy, but even the first time it's always been quite easy and quite simple to implement.

The initial setup only took a couple of days to get it all installed properly and cleared with IT. In terms of getting the first process up and running, it took about a week or two because we already had a couple of processes that were available. That's just a case of tweaking them, making sure they're all okay, and then just getting them set up and getting more packaged up.

Our initial strategy was mainly to focus on finance and to try and reduce the outsourced headcount with a couple of the finance teams. We outsource a lot of our work to a couple of other companies and we want to reduce the cost of that, so I automate it in-house. Our other strategy was to try and free up as much time for our lawyers as possible to make sure they weren't bogged down with work. It gives them more time to focus on the clients and work up better relationships with them.

We're still looking at the process that we've automated and seeing how much time and money we're saving with this crisis, but we don't have that information at the moment.

The pricing is pretty fair. Sometimes the pricing can be a little bit strange. There are different prices if it's for a specific user, a specific PC or if it's an attended bot or unattended bot. The price can be quite different, but I think when you talk to UiPath or when you look at the pricing sheets, there's not always a justification of why a certain license is more expensive than another. 

Licenses are more expensive than another but I wonder why there's such a big difference, why attended is four times more expensive, and that sort of thing. In terms of the orchestrator, I think it was a bit too much. It used to cost about 20,000 pounds a year. Now, they are ramping up costs. If you get an orchestrator but with just a few blocks, it's cheaper and then you can add up more parts to the orchestrator. So the cost goes up, which I think is better.

Definitely to try and get as many teams involved as possible to open up the conversation about RPA within the business. It works best when you've got lots of teams who have an understanding of RPA and how it works. They can come to you with their potential projects and you can filter through them and see which ones are going to be the most helpful.

It's hard if no one else in the business really knows RPA or how it works, or if there's a bit of a wall there. It's important to introduce RPA to as many different teams as possible and to encourage people to get involved, think about the processes that they do in it, and try to identify what can be helpful.

It's important to keep RPA close to the applications and the IT teams because if you're using RPA or UiPath you're going to need to be able to be speaking to your team who need permissions or admin privileges, or you need apps to be updated. It's important if you're going to put it in, have it as close to apps and development as possible.

It's a case of understanding that it's not a case of trying to get everything automated that you possibly can. The goal shouldn't just be to automate everything. If you've got a process and you can do 99% of it automated but you can't automate the last 1%, you can but it's going to be really fairly inefficient. Understand that it's fine for a process to have some bits that are automated, some of which are done by a person. The hybrid workforce, rather than going into the strategy of just automating everything is ideal. I've learned that trying to find that balance and getting that communication between the two is good.

I would rate UiPath a nine out of ten. 

The primary use case is invoicing and billing. The first thing that we used it for was some content migration from one video hosting provider to another. We later on moved to invoicing and billing, which included time sheets, management, and feeding data into our accounting system.

The features that we use the most for our use case include reading PDFs, email integration, and web and desktop automation talking to other desktop software.

We have generally found it easy to use, but we also develop some extensions. We are actually a software development shop, so we have developed extensions to the core UiPath platform. They have made it pretty easy to do that.

UiPath could use more OCR use cases to help with those features.

I would like to see higher end AI type features natively in UiPath. Some native integration over time would help.

We found it to be quite stable.

We have a relatively small use case. Most people have entered the market on a small scale. The maturity will come in, maybe over this year, as people start to scale up. 

I expect some issues will surface when it starts scaling up. However, that happens with any software. 

The eagerness of UiPath engineers and their salespeople to help us along the process has helped us align ourselves more with UiPath.

Support is good, helpful, and eager to help.

The UiPath Academy is great. It was one of the reasons which made us choose the tool, and align ourselves with it. It was easy to get the software, and train on it. If you're doing professional work, you don't want to have untrained people work on it. This will not lead to success.

As a software development shop, we value training quite a lot. They made it easy to help our developers come up to speed with the software and get certified.

The initial setup is quite easy. We have worked with some other RPA tools, but they took us quite awhile to get setup. With UiPath, it was relatively easier to get started.

We have seen ROI by it saving some hours for us. We are a small company. We use the tool mostly because we want to learn about the software. We also save some hours, but we do it to learn and help other customers who are doing it at much higher volumes. The savings for us is relatively lesser than the savings for a larger customer.

ROI is a bit tricky. Customers need to implement simpler use cases: Get ROI from the tool, learn it, and re-implement it. This is just the nature of how RPA works. I see a lot of opportunities for it.

When customers start scaling up their use of RPA and have learnt how to use it, that is when the real ROI will start trickling in. When you start off, it will take some effort to get it right. Once you developed some maturity with the process, and you're scaling up a lot of use cases, and you have one bot doing a lot of different things and being able to share a lot of processes with a few bots, that's when you will start seeing good ROI.

This tool gives opportunities for people to be productive in other areas, which is hard to measure sometimes. The first step is to get them there, then determine where you can go from there. ROI is a very long term thing. The product lets people focus their skills on what they are good at, which is a type of ROI.

UiPath made it easy to learn their software. When we looked at a variety of RPA tools initially, UiPath was the easiest to get started with. It has good Academy content and an open platform, which is easy to download and start using (the Community Edition).

We have been looking at other RPA solutions, but we like UiPath quite a lot.

The primary use case is to have a platform which allows us to scale rapidly without adding a lot of human labor. We are looking to go global without being dependent on recruiting heavily on back office functions.

We combine this RPA solution with predictive analytics. We are in the hairdressing industry, so we predict the amount of haircuts that we get every month in advance. Based on that prediction, we set up our work shifts based on it. We do that predictably, then we use UiPath RPA to fill in the work schedules for each employee in advance and measure it, since it is really important for us to get an accurate number of shifts based on predictive analytics.

It is fairly easy to use. We are using it with a lot of integrations with separate tools to get the flow of data going.

Valuable features include rapid development and the scale of solution. The most valuable feature would be accuracy: The ability to perform the same job accurately and consistently.

We use UiPath only in virtual environments. If it came out of the box like a software as a service, it would be a whole lot better, especially in our case. All our internal systems are cloud-based systems, so we have no dependencies or legacies in terms of installed software in any way. We could be completely in the cloud all the way through.

I would like to see direct integration with the Google BigQuery platform. 

I would also like an Orchestrator self-service desk.

The stability is as good as the developer makes it.

The scalability looks pretty solid. We haven't been working with it too long, or long enough to see it really scale yet. 

Orchestrator should have better scalability with a better payment model in terms of number of processes that you want to use. Instead, you have one product which covers this size with this fixed price. You're getting a box of options, but you can't really scale it.

We have not really used the support. We did spend a bit of time on the community forum, but that's about it. The community forum is pretty good. This is one thing which differentiates UiPath from the pack: It has a community and access to information.

We did not use a previous solution. We went straight to UiPath right from the get go. 

I have worked with automation before. We saw a rapid gain in terms of automation where we couldn't automate in any other way. 

The initial setup was a bit complex. It could be better, especially with Orchestrator. 

Orchestrator should be a separate solution, straight out. Just sign up and have a heavy solution for it. Instead, we spent a lot of paid consulting hours setting it up on our Google Cloud platform and virtual server in the cloud. That was just wasting money for our organization. It should be its own software as a service. 

We used PwC for the deployment, who was very good.

We've been in production for about two months, and we have seen tremendous ROI. The accuracy of the job was far more valuable than the man-hours spent.

It has helped to eliminate human error by a huge amount.

While it has saved us time, we're a small staff business, so there's not a whole lot of time to save.

Licensing costs are high, but still well within a positive return on investment.

We like the hybrid model, but it would be very costly for us to have one Attended Robot for each person in the organization. Although, it would be nice to have, we don't do many mundane, repetitive tasks in entire our organization. We actually have UiPath to do all the work that we don't do, which means we can think about it differently from the start. If we can consolidate all those tasks on Unattended Robots from the start, then we save on licensing money, which we try to keep as tight as possible.

The main cost driver is developing and maintaining the software. Ensure that you don't spend unnecessary time implementing something you don't know. Get someone who knows it to get it up and running. Let that be the basis of your tech choice. I like UiPath roadmap, and the roadmap of the product should also be very important.

Getting the ROI, which we expected within one month, would be impossible to do with another tool.

We did not look at other solutions. I am managing the system, not developing it. I am a self-service manager for the operations, and I only knew UiPath. Therefore, the cost of implementing something that I didn't know would be higher than the cost of implementing something I did know. Plus, it works for work we need.

The automation technology at our organization is pretty good. We use a set of combination batch/cron jobs for a Google Cloud platform together with some AI automation tools, like Dialogflow, in combination with the RPA tools, like UiPath.

It is a very good product and very much stable. I love working with it. Though, it still has some limitations when it comes to integrations and development. Sometimes, you find yourself in a situation where have to add a bunch of code to make it work faster, or you will be stuck with it dragging and dropping. While this works in most cases, for the 20 percent where you want to add code, it does becomes annoying.

We are currently implementing a solution for a large telephony company to migrate data between systems. This data is fetched from a system A and placed on a system B. Much of UiPath's functions are well used, such as integrations with PDF, OCR, Excel, and a few others. The financial return tends to be large since the robot manages to work 24/7 and with almost zero errors.

UiPath is a simple tool to be used, has a friendly interface and at the same time powerful and useful to automate most repetitive processes. From an academy with training courses that enroll anyone who wants to join the RPA area, teaching from basic to advanced takes around 20 hours. Available features, integrations with other applications, and a large amount of community-made frameworks that are very active are the things that make UiPath more feasible to use or choose from its competitors: Automation Anywhere and Blue Prism.

UiPath will surely win over anyone planning to join the RPA. The tool is friendly, simple to use, very visual, courses are well produced and explained, and certification is free until the end of March.

Despite all the good points, UiPath still leaves a bit to be desired with the documentation. ReFramework, which is an adopted community framework, is too nebulous to be understood and poorly documented and presented in the course, causing us to scour the internet for help. Another downside is that the passage of arguments and the number of native commands is not as vast as one of its competitors.

No, UiPath was the first RPA solution I used.

Despite being an expensive tool, it brings considerable returns.

Ease of use, market leadership, and cost.

We use it to automate repetitive processes. We are also using it to manage people and costs.

I have used it for automation in telecommunication, HR, and finance. I have also done two projects for IT. It is a combination. I have worked on all these different projects.

UiPath helps with cost savings and staff savings. We can use manpower for high-value tasks rather than for repetitive tasks.

UiPath helps with end-to-end automation. I have created end-to-end automation through UiPath. It is a high priority for our company. I have not yet worked on the AI functionality.

UiPath reduces human error. If it is a repetitive task, then bots cannot go wrong. They have already been coded with whatever is required, so human errors are generally not there, but there can be scenarios that have not been covered, and they can result in exceptions. We have to work on them and update the bots so that we do not get the same issues.

UiPath improves accuracy. The teams for whom we have done automation are happy. There are no errors. It improves their efficiency. Bots can work 24/7 or at whatever time they want. There is no dependency on time, which is not the case with humans.

The time savings vary from project to project. On average, if a human takes three hours for a task, a bot would take about ten minutes. UiPath reduces the costs, but I do not have the metrics.

UiPath is very user-friendly. There is ease of use. People can understand it very quickly.

It is very easy to use.  It is very good. There are many people who are uploading learning sessions on YouTube, which are free. It is good to learn from there as well. There are many sources to learn and explore it. There is also a community of UiPath users.

UiPath Academy has complete courses for developers and business analysts. A business analyst can follow the course path created for business analysts, and a developer can follow the course path created for developers.

I have been working with UiPath for the last four years.

It is a stable solution. However, if your applications are changing, you will have to do some manipulations in the code. Now they have a feature where you can keep your UI things in your config or in the assets, which is helpful. It is easy.

I do not interact with them directly. There is a team that communicates with their support. 

I know Automation Anywhere, and I have also done a certification on it about four years ago, but I did not work on it. I am not familiar with the features currently in Automation Anywhere, so I cannot compare it with UiPath. I have more experience with UiPath because we got more UiPath projects. We were going to work on a project with Automation Anywhere, but that did not happen.

I have also worked on UiPath Document Understanding, but most of my experience is with general automation.

I have set it up from scratch in one of the companies. It was not that hard. It was easy to set everything up. I was doing it for the first time, so it was a little bit confusing, but it was good. There were forums and YouTube videos. The UiPath team is also available if you need help with installation and what to use. It was good.

After the code is ready, the bot deployment takes 10 to 15 minutes. Three years ago, it used to take us an hour.

I have not worked extensively with any other tool. My experience with UiPath is good, and I would rate it an eight out of ten. I am satisfied with UiPath.

I have used UiPath for a city utility. The main purpose is if they want to dig in a particular location, they need to know how many pipelines are underneath the road, what the situation is regarding high-tension wires, gas pipelines, et cetera. For that, we needed to go to about 18 websites and scrape the maps from them into a local repository. We use UiPath to save that data from all the websites.

From there, there is an AI/ML solution that identifies the danger signals and notations on the map. It summarizes them and sends them to a mobile application used by a person who is at that location. That person can determine whether they are able to dig in that particular location or not.

UiPath reduces human error by automating a lot of manual steps. 

It also helps free up employee time. The amount of time depends on the use case. For the use case I described above, for the utility, the whole process of preparing one package would take one person two and a half hours. Automating it using UiPath and AI reduced it to two and a half minutes.

In terms of costs, for that use case, it has saved that company 30 to 40 percent.

Scraping with UiPath is easy, as is integration with some services. It's also easy to deploy solutions. 

Building automation takes place in a normal programming environment like Visual Studio. It's the same environment developers use. If you know development, building automation in UiPath is easy. Visually, it's all interactive and easy to work on.

The platform also has features for logging and monitoring things and communicating when there are errors.

The UiPath user community is a very good ecosystem with information about a lot of new features like AI, chat integration, and WhatsApp integration.

For training purposes and certification, we use the UiPath Academy. It's a very good resource and you get very good support from the community.

We also use the solution's AI functionality but so far only on low- to medium-complexity processes.

I would like to see them transition to the cloud and provide services there. That would be an improvement.

Also, it needs more integration with external services, and I would like it to have generative AI and more artificial intelligence features.

I have been using UiPath for about one and a half years.

The stability is good. I am satisfied with it.

The scalability is also good.

UiPath's technical support is good.

Positive

I used Automation Anywhere. I switched because our clients switched since UiPath is cheaper.

There is definitely ROI from using UiPath. Based on the fees and the load of the input, ROI will be calculated and used to decide whether the use case is worthwhile or not. It will be decided in the analysis and discovery phases. If ROI is feasible, only then will development take place.

With UiPath, there is an additional cost for Document Understanding. If the use case demands it, that feature should be used.

Even though our clients may have an Automation Anywhere ecosystem, they choose UiPath due to budget and cost. Apart from cost, both platforms offer almost all the features. However, from a technical perspective, Automation Anywhere has more utilities and components for building bots.

If it weren't for the cost, I would personally choose Automation Anywhere, on the technical side, because it has huge utilities and components for building bots. The move to UiPath is driven by budgets and costs.

As for end-to-end processing, when you are trying to come up with use cases for RPA, you will probably look at existing legacy applications that are not extendable. They won't have any more new releases but we still need to extract value from them. Use cases include reducing the processing steps and manual steps done, day-to-day, by people. End-to-end automation will help to stitch all the gaps and reduce the processing time.

UiPath is not cloud-based yet, so most of the work is done on-premises.

In terms of maintenance, one person on our support team monitors all the bots and attends to any problems.

I would recommend UiPath for small and medium-sized automation. If a company doesn't have a large budget, UiPath is the solution.