Nintex RPA Reviews

We use it for unattended automation and attended automation.

We are working on automating a lot of the support processes that we do within our call centers which are very repetitive. In addition, there are rates and pricing in another area where we have introduced automation. We have some automated processes running multiple times a day to evaluate rates, provide reporting, and perform rate updates, as needed, without human intervention.

We are also looking at streamlining some areas on our franchise side, where we are building properties out in our systems and updating their property information. Therefore, we are looking at those components, as well as the onboarding of new hotels.

It has benefited our organization through automated rates and pricing. We built an automated rate system that runs four times a day. Our initial analytics coming back from that rate system for a single two-day period in July performed over 25,000 individual rate changes across just under 600 hotels. 

With this volume of activity, there is no way that we could hire enough revenue managers to perform those volume of rate changes. This rate system has allowed us to be more responsive and competitive with our rates with less human involvement. It is leaving our revenue managers free to work with properties, identify special events where things might want to be increased, etc., rather than spending their time updating rates. Instead, they can now just submit a special event and what they want the rates to be, then the system will adopt these into the existing strategy that is being implemented automatically.

It has been straightforward and smooth to use this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We have three dedicated environments: development, UAT, and production. We build things out, then test them in development. It is very easy for us to transition them out of development into user acceptance testing. Once our users are happy, it is a very easy, seamless process for us to transfer that into production, enable the triggers, and turn it on. The ease of being able to bring things into production and through the development cycle is quite straightforward.

This solution has helped our existing workforce embrace the digital transformation of our organization. We have multiple departments currently coming up to us, and saying, "Hey, when can we meet and talk about things? We have things we want to automate." We have other departments starting to to reach out and show an interest in having parts of their processes streamlined or automated. For example, one of the processes that we are working on automating would be a hotel room type of change. So, if a hotel has a bunch of rooms in their hotel, and they want to transform them into a different room type, it is a very long, slow process. It's very monotonous and repetitive. This is a really good candidate for automation. Right now, we are working with that department to automate that specific process. For them to do it by hand right now, it takes them almost a full seven days to perform, but with automation, we can do it in almost half that time. These type of requests happen regularly. Therefore, there are more of them to do than there are people. This automation will allow us to perform the requests that we have faster, but also keep up with future requests.

When we approach the departments about automation, we put a high stress that the solution is complimentary and will elevate the human workforce. This way they can do the more important things while not having to worry about filling out an Excel spreadsheet with 600 fields. Most of them, when they hear that they won't have to fill out all those fields anymore and they'll just have to worry about the more important aspects of it, they typically end up pretty happy. They seem to be pretty receptive to it. However, you'll always run into a few people who will have the concern that automation might take their jobs, but it hasn't happened so far.

With any of the processes that we have deployed, the accuracy and rate of errors coming back is much lower than what we would typically see. There have been a lot less things going through the automation that we need to adjust, fix after the fact, or touch manually.

We have relied heavily on the the data group base integration features, as well as the email and Exchange integration features. The ability to integrate with Office makes life a lot easier. One of the things that we do is interact with a lot of Excel worksheets and their information without having to load up the Excel worksheets themselves. Instead, we are able to pull the data directly from them and do the manipulations that we need, then put them back into the spreadsheet or into another worksheet without having to wait for Excel to load.

The ability to integrate with a database is a big perk from a scalability standpoint. Our automated processes for our rate programs are driven by database entry. We also use databases for our queuing systems and reporting purposes. It is proving to be the backbone of our analytics side of tracking and monitoring our automated processes and systems.

We have been using Kryon Process Discovery for about a year now. With our initial tests and monitoring just a couple people, we were able to identify 79 possible use cases within a one-month period.

For developers, Kryon is quite easy to use. I come from a scripting background. Adapting from scripting over to working in Kryon's development environment is very simple. It was an easy adjustment.

It is easy to move things through testing and into production. From a development standpoint, it is a pretty streamlined, straightforward process.

This need for improvement deals with the Office APIs in it. There have been some times when dealing with the macro interactions that we have had to build our own way of executing those macros rather than using the inbuilt tools provided by Kryon to execute them. I would like to see some improvement there.

We have also run into instances with some of the Office integration commands that are available, where we have had occasional troubles. They read the data once, hold a file open, or do something in the background. It would be nice to see the handling of this improved. This should probably be relatively minor improvements.

I would like the pool of advanced commands to increase. It does have a very solid base with a wide range of commands ranging from date manipulations through to SAP integrations. It needs to shore up those commands, harden them up a little bit, and maybe expand upon them. This would be something that would be nice.

I have been using it for five years now.

Overall, it is quite stable. I have seen some very minor occurrences where Kryon's interactions with Microsoft Office might cause the robot to hang. However, it is about one to two percent of the time where we are seeing this happen. It is such a small percentage that it's not even something that we are overly worried about. This would be where they might have some stability issues, but it could be the Microsoft Office API or how they are interacting together. It is such a rare occurrence that it is quite stable overall.

We are currently in the process of working toward upgrading our Process Discovery install. We are putting it out to a larger user base so we can start pulling in more possible use cases, which may not have been identified by somebody.

We currently have a three to five person developer team. Of that team, three of us would be critical for long-term maintenance.

It is very scalable. The solution will scale for whatever you build it to scale to. If you take the time to make sure that the design that you are implementing for processes are scalable and able to ramp up, it'll scale to do whatever volume you need, as long as you're able to throw the machine resources at it to provide the processing that it needs. In our case, we have one environment that manages rates for an entire brand of hotels, and we're looking at expanding that out to more brands.

We have three environments for the unattended side. We have a production, user acceptance testing (UAT), and development environment. 

• Production is the environment where we use it for anything which will be running and affecting real data and real environmentals. 
• UAT is strictly a testing environment. It gets used as we have processes which are ready for testing before we can deploy so we can make sure it's performing as the end users expect.
• Development gets a lot of use from the developers because that is where we are building our processes and testing them out prior to exposing the user to them.

In addition, we also have a very widespread attended side deployed across a lot of our hotels in North America. We have about 10,000 PCs with the application installed to provide training and support for the properties.

For actively developing in Kryon, there is only a handful of us. That is all we do. We work with the departments to identify the processes to automate, then determine the steps needed to automate those processes and work through that.

We have about 40 revenue managers who are working with that automated pricing system that we have. There is also a handful of other users out there who are either developing content for the attended side of things or leveraging some of the automated tasks that we have. We have built out for them to free up time to work on more important things. Right now, outside of the revenue managers, there are probably another 20 to 30 users.

Overall, the customer support is fairly good. There have been some times where we have had to go through explaining the issue a couple times because it has gone through a couple of people's hands. There have been a couple of scenarios where we have had to re-explain the issue and bring somebody new up to speed on what is going on or what the problem is. Overall, they are very responsive and very helpful.

Previously, we had tiny bits of automation, but it wasn't automation like this. It was more scripted automation. Just people running bash scripts to perform certain things for them. There was never really anything official nor a real platform in place prior.

We looked into having an automation tool because we have a lot of processes which are very time consuming, e.g., data entry-centric. These tasks take a very long time for a human to do and are very monotonous. People tend to get bored doing them very quickly. Automation was a great way of getting that fixed so we can give the human workforce more important tasks and offload these menial tasks that nobody really wants to do. We can offload these tasks to automation and keep everybody a bit happier.

The initial setup was fairly straightforward. When initially setting it up, it definitely does benefit to have some IT experience in setting up different types of servers. Overall, the process itself was quite straightforward, though.

The deployment process was pretty quick. We did it between mid-March and mid-April, deploying three environments. A couple of which only took us a day to deploy. Once you are familiar with deploying the environment, it can be done very quickly.

We kept our implementation strategy basic. We have our application server and IIS instance together on one box, then we have our database server instance on a separate box. Then, we have all of our bots linked into it. They are all VMs, so they can be snapshotted, spun up, and spun down very quickly. If we do need to bring more bots online for any particular reason, it's very quick for us to do that, as well. It is a simple implementation, but it is virtualized. That virtualization gives us a lot of scalability and flexibility with where we want to go with the platform.

We used the Process Discovery tool to help us find and prioritize processes that are ripe for automation. We have also worked fairly close with Kryon on our automated rates and pricing platform that we built out. So, we had Kryon resources working onsite with us building and deploying that platform.

We worked directly with a couple of people at Kryon to set up our initial environment. It was a partnership sort of scenario where we worked with them to determine what our needs were, then we deployed that. However, we had some people on our end doing the actual work, while Kryon had a couple of people who were making recommendations or consulting on it.

Our experience with Kryon during the deployment was good. For the deployment of the infrastructure, we had access to some very knowledgeable people about the system who knew the ins and outs of the environment's back-end, which is useful.

Kryon is saving us money on the attended side of things. Attended automation has diverted 34 percent of training calls to our tech support centers. 

On the unattended side, we used automation to onboard a brand into our management systems this past January. The automation performed those tasks over a five-day period. It would have taken a team of 20 to 30 people almost a month to do that same work. So, we've definitely seen some benefits from automation.

Kryon came into the picture before I did. In the past, I know that we informally looked at a couple other products, but we never went in-depth with them. Once we picked Kryon, we stuck with Kryon. 

We did talk to WalkMe a little bit.

Take your time. Don't rush it. Ensure that you have a few good use case scenarios to start working with, because if you don't have something to work on right out of the gate, the system will just be sitting there doing nothing as part of the evaluation. You should know a handful of processes which are good candidates that you can use as initial proofs of concept just to make sure that it will fit your needs. You want more than one, so if you do move ahead, you actually have some work to do.

Kryon is easy to use. Somebody who is not tech savvy at all might have a bit of trouble picking things up. However, if somebody is a power user of Microsoft Office or familiar with the workings of macros, this is a platform that they will pick up easily. Even if somebody is not overly tech savvy and they are at least curious or willing to to read about things, working with the commands and interface can be easy. So, if they are reading up on how to go about doing what they're doing or reading about the commands, then they will pick up the system up well.

We use it to automate a lot of data entry or do manipulation in regards to our ERP system.

We are still pretty new with the solution. We have maybe a dozen wizards right now. Some of them are different variants of similar wizards. For the most part, it is used all around our ERP system. E.g., if we have a new product that we're going to make, we take the information from marketing and engineering. That gets handed off to the bot, then the bot enters that information into our ERP. This is a pretty intensive manual entry process.

Everything that we use is on-premise.

Our company has seen crazy growth over the last 10 to 12 years. We have been up 20 percent year-over-year for that amount of time. Without some of this automation, we would not have the time to invest in developing a full solution or custom applications to handle some stuff because things are changing so quick. It's not worth the investment or there is not enough time to keep up. Constantly hiring more people isn't always an option either. It's sort of a necessity with the growth that we've seen to use this to help with some of the pain points that we have just around growth challenges. Especially at the higher levels of the organization, they see quite a bit of value in the solution.

It has really helped us with efficiency and accuracy. We literally have teams of people just sitting in front of a computers typing in data from Excel sheets all day. That is all they do. We have so many other roles and new challenges associated with our business growth that we could use those bodies. People who have been with the organization a while that we can take those people and say, "Instead of just manually keying all this stuff, go work on something that's a value-add. You know the business and you're familiar with our systems, so go do this instead." That is the biggest win, especially with our state's unemployment being pretty low and filling jobs can be a challenge when finding good people. We want to take the people that we have and leverage them for the things which really help the organization.

It is still a small footprint. In the last 30 days, we've automated 216 hours of work. That is not a lot. However, when you talk about how many people hours that is, it's probably double, if not more than that. So, it is not a huge impact, but in the couple of places that we've deployed it, it has been nice to be able to just send an email in and have it turned around to you from the bot. Within 10 to 15 minutes, the task is done instead of having to send it to a person and rely on them to do it, then get back to you, or they might be on a lunch break, etc. Some of these are critical areas where there's not a lot of time. It's definitely been a benefit to those departments.

I don't think it saves any time from the analyst or IT side. It is an investment upfront to build this stuff and to dig in and find where the opportunities are. We just installed the Kryon Process Discovery service, but we haven't really used it a whole lot yet. Therefore, I can't speak to its efficacy. Hopefully, it will help in this area. 

They make it pretty easy to use this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We just installed Process Discovery. In theory, that should work quite well. It recommends what processes if identified are best for automation versus those that are highly complicated or have a lot of bearings. We haven't gotten the value out of that yet because it's brand new. 

The bot is typically about twice as fast as a person and more accurate, as long as the data going in is good. That is the biggest advantage.

I do like the feature if you find an opportunity that it is very simple to export the recording of that process and import it into Kryon Studio as a starting point to build that automation. It's a really good tool for our business process managers because they can take all that information to their constituents in their departments. Even if it's not robot automation, they have an opportunity to improve the process as a whole. I find that that is an added benefit to this piece of the tool. Just using it as a place to start the conversation and really look at what people are doing on a day-to-day basis. Because managers may be aware of their people's tasks, but might not know the level of manual effort that it takes to do certain tasks. We are finding this helpful. Also, building it in Studio and deploying it into production is a seamless process. It is all very simple and easy to use.

It is just great to be able to traverse software platforms. With all the variable handling and  logic that it has, It is an easy tool for a non-technical person to work with and automate across apps. Some of our business people are like, "It's like a giant macro. It works with everything." I'm like, "Yeah, at the basic core, it's a giant macro." 

We primarily use it for unattended bots, so it's pure. We don't use any attended bots. So, it's all completely automated using email triggers.

The bot will put in whatever data it receives and it has been really quite effective.

The tool helps with speed to market on anything that we are doing. It is such a quick tool to use if you're doing any sort of automation, even if it's just SQL based. 

Process Discovery is brand new. We are on 19.1 for it. I know on 19.2 that they change the architecture completely. From talking to some other companies that use this, it sounds like we are missing some pretty big features that we will need. We will be doing an upgrade here in the near term. In general, Kryon's upgrade process is basically uninstall/reinstall at this point. They don't have an easy way to upgrade the software in place, which would be an added benefit. The process is not difficult. We have just a handful of robot machines with high availability enabled, along with a couple of app servers and a couple of database servers. Still, that's 12 machines which all need to be upgraded, and that is no simple effort when you're talking about a full reinstalled software. If we fully utilized our licensing by scaling out, we'd have more than 30 machines. We would have to upgrade on the field. Then, it's a pretty big task if they release new features and things that we want to take advantage of going forward. I see an opportunity for improvement from them here.

We are using it to do some automated reporting, and right now, we can't put images into the HTML formatted body of an email. We can either attach an image or embed a link to an image, but we can't just drop in an image into the HTML. That is feedback that I have given them. It would be nice to be able to have a bot take an image and paste it in as you would in Outlook. Otherwise, we have to provide either those images on a public website. If we want them just to be attached, it just doesn't look as clean. Especially people in our sales force, who are on their mobiles a lot, are not on our network a lot. These are a challenge for them when they just want to be able to glance at the report and go on with their day. It seems like a small problem, but it's limiting for us in some of the areas where we could deploy more of this solution. We have a feature request in for this, and I'm hoping it will be included in the future.

How it delineates file names on email attachments could be better. It is a hard coded comma, and if somebody includes a comment in a file name that messes it up. It is such a ridiculous thing. Who puts commas in file names? But, you would be surprised, and it happens. This is another simple thing they could easily tweak.

Their Tier 1 support is pretty basic. You either have to jump through the same hoops every time or escalate to a different Tier through your rep. 

We purchased the solution in January.

The stability is pretty good. The only unstable part is Studio where you build this stuff. In our version, the 5.25. It has a memory leak. If you leave it open for too long, eventually it just freezes. Saving your work, closing, and opening it just once a day is all it takes. However, this is a bug that I have noticed about the stability of the actual tool. Our production console and robots have been rock solid.

We are still a fledgling operation with it. We have one guy who works part-time on the PDF and another full-time contractor working with the business to build more bots and wizards and also finding more opportunities. Then, there are two of us who are dabbling in it in addition to our regular jobs. 

It is also helpful for certain one-off updates. I am a support analyst myself for a lot of our software. People in the business will come to me with really simple problems. E.g., HR had to send out an email to every intern with some of their employment credentials and links to sites for things that they needed. However, they all had to be personalized. Each email needed to have unique information to each candidate in it. So, they built the template real quick. They handed me the email and we dumped a list of the interns from our HRS system on it. We just threw that in the bot real quick with a couple of loops using the email template with some variables and were able to send out an email to all the interns in minutes, which could have taken a whole day, if done manually. For one off things like this, it's such a simple tool and really easy to use. 

While there are other ways of doing these type of tasks, e.g., a lot of HR systems have some sort of bulk email feature built-in to send new hires information. Our HRS doesn't have that or maybe it's too clunky to use. This just makes it super quick. 

We also use a lot of similar things with one off SQL automation where we could build a complicated script and run that. However, the bot can run a loop of queries for whatever variable it might be and spit out a report. This takes literally minutes to build and run versus hours if you go different paths. This makes it a very sleek little one off thing.

Scaling is simple and very quick. The longest piece of adding any more robots is creating the VM piece and installing all the software that we need onto that virtual machine. Once infrastructure does that piece and hands it off to us, it takes minutes to configure a bot, point it at the server, name it, and get it credentials, then adding it to a production group within the console is very quick. That piece is quite easy.

For part-time use, there are about five of us who are developing it.

There are 50 to 60 people now who interact with the bot by feeding the bot information to trigger it. Also, in our finance space, we have the bot doing some automated work. It doesn't post anything, but it prepares what is called a journal in our system. It prepares a journal, then someone from our finance team will go and review it, making sure everything is accurate before posting that. They are a customer of the bot at that point. That is just a time saver, so they don't have to manually build anything. They can look it over, then they're good. 

There are a lot of people who are receiving reports from the bot. I don't know how many there are. It is probably in the hundreds of thousands.

We would love to increase our usage here in IT. We see such value with it. The biggest challenge that we have isn't even with the tool, it is internally funding the tool. The strategy around it is to automate time, then take that time and have a chunk of that time go back to funding more resources to do more automation. It's a self-feeding model and self-funding model. We're still so small that we haven't hit critical mass where we can start really adding more people to it.

We have used the technical support a few times. It is pretty standard. Their Tier 1 support asks all the same questions that you always get when you send in a help ticket. Our sales rep is extremely responsive and very helpful with escalating things if we need them to. Once we get past the Level 1 tech support team, then we get some answers.

We are in the process of talking to the technical support a little about doing the upgrade. We personally haven't gone through it yet. The upgrade process is just what I've heard from them so far on how we go about doing it. Once we go through the process and understand it in and out, that will be a big piece of feedback that we will give to our reps.

This is the first RPA solution that my company has used.

Someone in the business found the solution. We weren't in a position where we were actually looking for it. One of our business partners stumbled across it, then reached out and said, "Hey guys, this tool looks really cool. We should get a demo going." So, they set one up. Though I didn't participate at that time, one of my colleagues went and participated in that. Then, they came back with an almost like this tool sounds too good to be true.

The tool says it can traverse all apps and can take data from Outlook, Excel, and whatever ERP you have in the web, then put data in, take data out, and manipulate it, or whatever you have to do. They say it can do everything. It was like, "Can you imagine if that's accurate? What we could do with this thing? There's so much potential."

We have grown so fast and our processes have not evolved with the company. We haven't caught up there yet. So, there was a lot of manual stuff going on that we can use the tool for, and we were like, "Wow, okay. So, we definitely have to keep looking at this thing, "and that's when we got our hands on the demo. 

We might have been the first company who used the demo once they published it on their website. I remember talking to them after we purchased it, and they're like, "This demo is brand new. You're the first people that we know of to to actually use it or call us and ask questions about it." From there, we did a little proof of concept with it to make sure it would interact with our ERP, then we were off to the races.

The install of RPA was very straightforward. The Process Discovery service install went well, but configuring it properly took a couple of iterations of calls with Kryon to ensure that we had it done right.

We had QC stood up in half a day of production, not including the virtual machines. That wasn't on our team, but the actual install and configuration of Kryon was about half a day. We had two or three calls scheduled to install and configure everything else for RPA and production.

We wanted to make sure that we had a development and QC environment, then production environment. The only strategy that we had around it was to make sure that we followed the best SDLC practices that we could, as far as testing, not coding and prod. One of our guys just set up a call, then we went and did it. 

The bot took a month or so to stand up and test, then vet with the business off and on versus the six months that it would have taken to actually build a full solution. Then, if something had changed with any of our systems, that time would have been lost. That is a big savings too, just the opportunity to use this instead of dedicating a whole team of resources to a project like that.

One of my coworkers did the initial setup. We worked directly with Kryon to install it. The resource that they assigned to us was extremely helpful. Even though they are out of Israel, they were very accommodating with our schedules and always willing to help answer questions. They were very helpful and good.

We just needed one team member to deploy it and Kryon did it with us, just one on one. That was a really nice thing. I don't know about the RPA space, but a lot of times when you work with some of these bigger companies, they don't want to support their software or help install the software. They hand you off to a partner. It was really nice just going right to the guys who work to build this stuff and support it. That was a great advantage.

We are almost to a point where if I scale out what we're using it for today to the end of the year, then we have paid off the software.

We are probably saving $6000 to $8000 a month in labor costs. It's not a ton, but we're right around $60,000 to $80,000 a year with our current deployment. 

We haven't looked into it yet, but for our next opportunity, one of our business partners came across what he thinks is some significant savings in one of our departments. He is really excited to get in there and start looking at the opportunity and evaluating it for viability. If it's good, that'll be a huge win for us. They're talking about six to eight people that we can displace with the bot and and reallocating to other things.

They license per robot and we have 25 robots. You get so many robot licenses and can allocate those licenses to either attended, unintended, or Process Discovery bots. If you have 25 licenses, for example, you could have 20 automation bots and five process discovery. This allocation is flexible. There are also maintenance costs.

We also looked at Blue Prism. We just briefly looked at some demos, then we even got pricing, but we were sold from the get-go with the Kryon tool because it was so inexpensive and easy to purchase. It was very easy to learn. We were self-taught before Kryon actually came onsite and did any training for us. We had the demo for a month or two. We played around with it. The demo was very easy to learn, which was a huge benefit for us because then we didn't need to hire an expert who knew the tool already. We could just go and use it. 

Kryon is a fairly new company comparatively versus the other players in the space. There are still just the learning too.

Kryon is the most simplistic solution and the easiest to use, but the con that I've heard from other people is that the competitors are, in general, more powerful tools. However, with everything, we've thrown at it so far, we haven't found a use case where it hasn't been able to accommodate, which has been pretty impressive to me. I thought maybe we'd hit a brick wall because it just doesn't have that function or logic to do something, but it's pretty amazing what simple, basic bot programming can do with some logic.

I would really recommend the tool. I definitely see a lot of value with it. Just in the few release notes that I have read for some of the versions they've released since we installed it, it sounds like they are still adding a lot of features and functionality. We are very excited to get this upgrade under our belts and see what new things the new version brings to the table. It has been a great value-add for us personally and easy to use. We are happy with what we bought. No buyer's remorse here.

The biggest challenge that we have had isn't even with the tool. It is with the business funding it. Make sure you have a good funding model set up for funding. Our model is fine if we could actually get more funding for it. That would be the biggest thing. If we could get the business to get behind it a bit more, giving us one or two headcount to really go after stuff.

While it is a pretty simple tool to use, keep all the management centralized in IT, e.g., the operations side of the robots and keeping production access limited to a Kryon administrator who sits in the IT function. That is something that we have done really well. It just helps the stability of the bot. You don't have to worry about anybody going in there and poking at production code or breaking a process. If we did it again, that would be something we would definitely do. Once again, the challenge with that is you need to be able to fund enough people to do that.

We haven't had a lot of challenges with the tool.

I primarily use Kryon RPA for attended and unattended bots and back-office automation. I've also used it for fulfillment cases in the retail domain, where it's been working quite well.

Kryon could be easier to use, especially in comparison to UiPath.

I've been using Kryon RPA for five years.

Kryon RPA is very stable - we've not had many disruptions, and the product is updated regularly.

The scalability's good, and it's flexible in terms of how you want to scale it up.

We've received good support from Kryon.

The initial setup is straightforward, without any issues.

Kryon is slightly more expensive compared to UiPath.

We evaluated Automation Anywhere and Blue Prism and found Kryon to be more approachable.

I would recommend Kryon to those thinking of installing it and would give it a score of nine out of ten.

I use Kryon RPA to make bots for the telecommunication and banking industries. 

I like Kryon RPA's ability to use automated and manual processes with any bot.

Kryon RPA's integration with other solutions could  be more seamless. 

I've been using Kryon RPA since 2019. I started at my previous company about four years ago, then I took another position at Banco Pichincha Ecuador. I'm a development architect working as an independent consultant at the bank. 

Kryon RPA is scalable. It's easy to create bots and schedule when they should run.

Kryon RPA's interface isn't as developer-friendly as UiPath's. I'd also like to see more seamless integration with other solutions. For example, with UiPath, we can use a lot of APIs. I also like Orchestrator from UiPath. We can control all of the robots that we're developing in the machines in the bot runners. UiPath Apps is a new tool that I like.

Microsoft also has some amazing tools, like Power Automate Desktop, Power Apps, and Power Automate Online. These tools can integrate with bots on Power Automate Desktop.

I Kryon RAP 10 out of 10. I recommend starting with easy processes. You should discuss the processes with the client, and go over things like cost, tools, time, and other things that are critical for the business.

We're looking to discover routine processes that our users do and ultimately automate those processes and deploy them to robots.

We've really been looking at just about any of processes. We've initially used it for processes that update invoices or update data on our system. We've used it for processes to send emails such as notification emails. We've used it to run scripts and to run data updates, and as a scheduling tool as well.

We've already automated about 40 hours' worth of weekly savings. It has definitely helped us to implement some of the workflows that I've shared with you and to take that work away from our partners so they can focus more on other, more valuable work.

The thing that we find the most value in is the Process Discovery component and the ability to really see what users are doing on a day-to-day basis. We're starting to make sense of the processes that they're doing and getting visibility into what they're doing. Overall, the Process Discovery is very good. The product is very new to the market so there have been some issues here and there but Kryon support has been great in working through that. It has really helped us drive understanding of what's happening. It certainly helps us understand the work the users are doing, the like things they're doing, and it helps us filter some of that work.

The product requires some more time in development. It still has some bugs and some things to work out. They're constantly releasing. They need to continue working out the general issues of using the product at scale, first and foremost.

I've talked with some of their product teams about features that I would like to see. With the Process Discovery, they're collecting a lot of data and they're spending a lot of time in the algorithms of the data. But one of the things we've talked about very recently is being able to aggregate or summarize what a user is doing in a day. That summary wouldn't necessarily be in the context of a process, but in terms of the applications they're using, the timeline of what they're doing, the number of clicks per hour. That sort of information could be very valuable.

We've been using Kryon for about for about four months or so. We are using version 19.4 of Process Discovery and 19.1 of the RPA solution.

The stability has been pretty decent. There are certainly opportunities in terms of stability, but with each subsequent release it gets more and more stable.

The product is becoming more and more scalable. On the Process Discovery side, you can collect a lot of data very quickly, so there is opportunity there. But overall, it's working pretty nicely.

We want to deploy Process Discovery across the majority of our company, which consists of about 1,200 or so people, to identify what they are doing. Over the next year, we are likely going to be deploying it on at least a couple of hundred users' machines.

Tech support is great. They've been really good and very responsive. We submit our tickets via our portal. We feel that we get really good support from them.

Our interactions with their customer service are great. Really great. We've had a variety of people off and on, not a specific person. We've probably worked with half-a-dozen people, and all of them have been able to help us pretty successfully. We do have an account rep who manages our account from a higher level, and she has been consistent with us and has been really great.

We did not have a previous solution. We came across Kryon from an RPA consultant who wrote a book on RPA. He used it a while back and recommended it to us.

The initial setup was pretty complex. The install is certainly not for the faint of heart. There are a lot of options and a lot of ways you can install. Given that we were installing in the cloud too, it took some time and it took some troubleshooting and work, but we got there.

It took somewhere in the neighborhood of a month for us to get the AWS environment up and running and then figure out all the nuances and dependencies of the install.

Our implementation strategy was to work side by side with Kryon and our network teams and get it installed. They gave us some initial pre-reqs and things to install and things to look at. We were one of the first to get everything operating in the AWS environment, so there were some specific things to us that we had to figure out on our own.

For the deployment, we had the equivalent of one dedicated person for a month. And we have the equivalent of two people maintaining it. They are RPA developers who work on setting up RPA jobs and configuring Process Discovery, etc. We have five users in total.

We've done it all internally thus far.

We have absolutely seen return on investment. We felt that we had to get to between 40 and 80 hours of weekly savings to get our ROI and we're already almost there, and that's good news overall. So far it's saving us about $80,000 annually. We expect that number to grow.

In terms of business analyst hours, it hasn't saved time there yet, but it will over the long haul for sure. It has definitely increased operational efficiency and has reduced human error by a pretty great degree, for the things we've automated. It does what it needs to do pretty routinely and pretty flawlessly.

The cost is fairly similar to its competitors' costs. It might have been a little bit more reasonable than the others, and that cost was with Process Discovery in addition.

There were no other licensing costs, but there are our hosting costs and our own AWS cost.

We evaluated Automation Anywhere, Blue Prism, and UiPath a little bit.

The biggest difference was that Kryon had Process Discovery and the ability to discover your processes across your base, and the others did not. That was a big differentiating factor for us. Automation Anywhere was starting to come out with its cloud deployment so users won't have to deploy everything internally. That was something that sticks. But in terms of the rest of the capabilities, they were relatively at parity.

Spend time focused on standing up your center of excellence around the solution. Kryon gave us some great advice on that in the sales process regarding defining what we're trying to do with it. Get key sponsors and then get a key team that works through the implementation, together.

What we're learning from using the solution and what we're really still trying to figure out is what is a good candidate for an RPA process, versus the other ways we could automate, whether it's process elimination or deploying some of our core engineering teams to write different tools. We're still trying to figure out what the framework is for picking the best processes.

The processes that lend themselves to RPA are processes that are highly repetitive, high volume, low-judgment types of processes, where you can write down the process in a Word document, write down the logic, and then turn that into an RPA solution.

We haven't been able to make that leap yet, in terms of Kryon's full cycle of automation from the discovery of our processes to turning on the automation and scaling it up, but we see the potential there. We haven't quite gotten to that point yet, given how early on we are in our journey.

When it comes to using the solution, for both business users and developers, you do have to have some technical background to use it. It's unlikely that you would deploy it to somebody who doesn't have any background in it. But people who are somewhat technical have been able to use it pretty successfully.

I would rate Kryon at eight out of ten. It has a lot of potential and we see that potential. It needs a few more iterations for me to bump that score up higher. It has been a good experience so far and we're looking forward to the future.

We only use unattended bots right now. We build processes to help business departments in our company to improve processes through automation of pretty easily "bot-able" ideas.

We have a bot that creates a proposal using a request-for-proposal template that people fill out. We then create the proposal, based on that information, on our internal site. Another one is where we mail out payroll files that come in by reading a portion of the file to get payroll dates and the like. Those are two of our really big ones. The payroll bot saved 15,000 hours last year. For the other one, while I don't have specific metrics on total time saved, it went from a 30-minute, manual prep process to an eight-minute bot process.

It has helped us to find and prioritize processes that are ripe for automation, when we go searching for ideas. We just haven't been able to reach every department in our company yet because we're a big company and there's only so much time.

Our business users love it. Those 15,000 hours saved are a fantastic result and we're at a 99 percent success rate. Our bots very rarely fail, and if they do, most of the time it's because something is wrong with one of the websites that we are using and an unexpected error pops up. But they are loving it.

Finally, it has helped to reduce employee errors.

We do have bots where we use .NET plugins to make some of them faster, but other than those, I have built most of the bots that we have. Even though I'm in IT, I'm a business analyst. As a business user, it's so easy to use. With the recording of the processes, we didn't need to hire a specific developer. We do have one now because there was only one of me, but we are able to build most of our processes without having to develop the actual development skillset. It's nice to have that skillset here, because we can scale by using .NET, but the simplicity is the biggest win.

At first, we had problems with the object detection but in this latest release it has been better, and I think it keeps getting better. They also came and trained us a little bit so that helped.

There are some known defects that are on our list for the next release, but that happens. It's technology. They're aware of them and they're working on them.

The stability has been great. We've had one incident in a year-and-a-half, where we were down for about four or five hours. It affected everybody, not just our company. As far as I know there was a hotfix that they had to put out. But in all that time there has only been that one day.

The scalability has been good because of the .NET aspect. If it wasn't for that, they wouldn't scale.

For example, we had one bot that we built which needed to run every day to download documents off a website. It had to go download a lot, sometimes up to 500 documents a day. It never finished because the website wasn't stable enough to run for hours and hours. The bot would end up failing because it took hours. Now, we download one document now from the website and use .NET to split out the PDF files for each separate document that we need. Instead of downloading one at a time on the website, we use .NET to download one, and separate all 300 of them. If we didn't have .NET they wouldn't be able to scale.

With that capability I don't see any limitation to that scalability. .NET has been a lifesaver.

We had another one that we had to change recently because it took the bot six to eight minutes to do the whole process the way the business users were doing it. We needed to do 900 in a day. Even running it on two different servers, it wasn't going to get everything done in the time that we needed it done. Instead of throwing it away saying, "Sorry, we can't use it," we changed the process for the business users and said, "Hey, can we do it this way?" and used .NET. There is a little more front-end work that the users have to do if there are errors, but not very often. Most of the time it goes through. With .NET, it does the process in 30 seconds.

We use the. NET plugin everywhere that we can because it makes things faster.

Their tech support is pretty good. The people I've worked with have been good. The time zone issue sometimes was difficult at first, but they've fixed that with a USA support team now. It's gotten much better.

In terms of customer service, everyone that I've worked with is great. Ryan is our guy and he's very good. Whenever we've had to escalate things — we've had some issues with bugs and things that we weren't expecting — he has done all of the escalations for us. 

They came out here and gave us a four-day-long training but it just wasn't going to work for us to go to them in September or October when they were going to have more training. So instead of us going, they offered to come to our office and have a mini-training session with just us. That was awesome. That was part of their standard service.

We did not have a prior solution.

I was not included in our initial setup. That was done before I was brought onto the team. But I am familiar with upgrades. 

The first upgrade that we did was not fun at all. It took seven or eight hours. The second time, when we upgraded to the 19.1 version, it was an hour-and-a-half, both because we got better and because they provided better documentation. We also got a QA environment, which we didn't have before. When we installed our QA environment, I don't think it even took half a day.

Part of the difficulty with the upgrades was that we didn't know any steps that we should have taken, because their documentation wasn't step-by-step. So we were on the phone with them, walking through the upgrade the first time. We missed steps because the documentation wasn't there. But the second time, the documentation was great. We knew exactly what to do. Our app engineer had all the setup stuff done before we had our meeting with Kryon, and we just walked through it. It was awesome.

There were two of us, from our organization, involved in the upgrades. Kryon had people on the phone but they weren't doing anything. They were just watching us.

In terms of maintaining the solution, there's one person who handles all the bot servers and there's one admin on Kryon but he's super-part-time. It takes maybe five percent of his time. I haven't had to talk to him for weeks. And there are two of us on the team who handle the support and the bot building. There are six departments that we have built bots for, and I don't know how many people are in those departments, but they don't handle anything with them. They don't have access to Kryon. We handle everything.

The OCR reader, to help read non-digital PDFs, has a separate charge. We don't have that plugin. The only other cost that I know was separate, at the time, is the Process Discovery. I don't know if that's included in a bundle now.

We evaluated Automation Anywhere and Blue Prism. I wasn't involved in all of that process, but the biggest thing in our decision to go with Kryon was that IT didn't need to own it. Although our IT has it right now, a process improvement team could have actual business users building processes. It can't just be them, because we have to have oversight with the .NET stuff. But with the easiness of it, we just had to go with Kryon.

The biggest lesson we've learned through our time using it is the .NET component for scaling. One of our biggest lessons is to use that wherever possible because it makes things so much quicker. Also, if you look at some of our old bots that we built versus some of the bots we build today, it's crazy that we even knew what we were doing. The process flows and understanding what can and can't be bot-able, have gotten way better.

My advice would be to have a team. Make sure there's a developer so you can do plug-in things and make sure that you understand the setup and the admin tool. That was a huge lesson learned for us, going back. The way we did the setup was incorrect so we had to re-record all of our bots the first time, and that was a disaster. We didn't have it set up right because nobody told us how to do it. We didn't have that support at the front-end, for the setup pieces, for everything we were doing. 

And always have a QA environment first. We did not have a QA environment. When we first went live we didn't know it was an option, and I don't know if it was an option at the time. I imagine it's standard now. We have a QA environment now, but we don't have any data set up or any automation to set data up so we can't test bots in QA. We have to test them in production because we didn't go through that work. Testing was a mess. That's no longer true for our current bots, the ones we're building today, but it was a mess for all of our old production bots, anytime changes were needed. So always have a QA environment or a Dev environment.

It's been hard to get it off the ground. We have a really small team, so there are not very many examples. We have quite a few bots that have saved a lot of time, but I know that we could have way more. We just need a team, and I think we're going to get one, although not right this second. Kryon hasn't helped our workforce embrace the digital transformation of our organization because we only have that small team right now. People are seeing things and say, "Yeah, that's awesome," but we can only move so fast because we're so small. So people are not super-excited about it yet. They still need more exposure to it. We have about 15 bots in production right now, but it's pretty much focused on one section of our organization, and we're a huge organization. We have plans to increase our usage of the solution. There's a whole new process improvement team coming. Once we get out there more, I'm sure it will expand.

The Kryon Process Discovery is not included in our license right now. We just haven't done it yet. We've looked into it but we haven't done it yet because it's pretty complex. With the version that we saw originally — it might be different now — when it first came out, you needed special computers for it which we would have had to buy and deploy for the users who use the processes. It wasn't something that we were going to do at the time. It's not something that we have thrown off the table, but at the moment we're not using it.

Just learning what bots do, what RPA does, what I can and can't do, has been part of it. I can go to any business unit, now that I've built bots, and say, "Yeah, I can do that," or "That's not a good idea." I know exactly what I can and can't do in Kryon. I don't know if any other tool can do things better because I've never seen any other tool, but I know what I can and can't do in Kryon.

The original training that we got was a week long and we were trying to build bots in that same timeframe. So we didn't get a whole lot at that time. When we took their training classes online and had them come to us and train us in more in-depth, it helped a lot.

Everything that we do use, that we know how to use, works nicely. I love it but I'm not going to give it a ten out of ten because there are issues. I would go with an eight. They've gotten so much better at all their stuff. The tech support was part of our issues for a long time, but it has gotten a lot better. They're getting all the training classes online and they keep those pretty updated. They have a community now. They're learning and growing and they always ask us for feedback on every aspect. They put that in their backlog for future prioritization. They're listening to us.

Our company buys products from vendors and sells services to end-users. Most of the RPA processes done in Kryon are related to order raising, as well as retrieving reports. We have automated processes involve SAP, Pegasus, ITSM tool, Words, and Excel.

It takes a lot of work and time to complete the business processes manually. When the users utilize the Kryon solution, it cuts off more than 50 percent of the processing time as the logic has been pre-built. There are less orders being delayed. Adopting Kryon solution has significantly improved the turnaround time.

The image recognition in recording actions is very helpful. It runs stably as long as the graphics on the applications are not changed.

The environment of storing the variables could be defined as local, which will only be accessible within the wizard itself and cannot be read by the embedding wizard.

It will be good if Kryon has a function to find/replace the keywords and collapse/expand the groups.

We did encounter some issues regarding to trigger often but our support team is able to resolved it later. Other than that, it is quite stable.

It is very scalable. All we need to do is to set up the robot accounts and assign the access to it. Once it is done, we have to configure the trigger for the robot. Scaling up and down can be done in just a few steps.

The customer support is outstanding. They are very responsive and will accommodate with our schedules.

No, we started with Kryon.

Setup for Studio and Robot is pretty straightforward. We have to install the Studio and Robot on the machines, create accounts for the users and assign access rights. Then login Studio to develop wizards and Robot to run the wizards.

The initial setup of server was done together with vendor. Subsequently, vendor team came down to help us with the upgrade. They are very helpful and knowledgeable.

I am not too sure how much cost was saved. But there are a few people in the department were redeployed when one of our processes is up and running fine.

I am not involved in any of those.

We are using UiPath in conjunction with Kryon. I feel that Kryon has a better image recognition than UiPath.

I have tried a few solutions and Kryon is the most user-friendly.

The solution is easy to use. Although I felt the solution is a little restricted sometimes as I could not call any external libraries, I am able to use the advance commands, which are the built-in functions in Kryon, to program the RPA solution by changing my initial idea. It makes me think out of the box and test how good my logical thinking is.

We use it for rapid process automation, but we also have Process Discovery. We use it for billing and collections, business administration, and insurance.

We have some idea of what we wanted to start with. We have been able to expand on that since embracing Kryon a bit more. We originally went into this solution knowing there were some processes which were extremely manual and wanted to take on automating. Once we got into using more of the advanced commands, we got through with some of our first, second, and third wizards, then we were able to take a step back, and say, "Here are all the functions that I've now learned to work with. I want to put them into higher level of development." We were able to expand the idea of something very simplistic, a three or four-step process, then move it over to a 50 or 60-step process. Because of those advanced commands, we could condense them down, which was something we didn't know at the time would be a reality.

Kryon has helped our existing workforce embrace the digital transformation of our organization. We now have people who are more interested than ever in moving over to digital processing. We are able to focus on key components of the business which can't be processed through automation.

We have seen some significant drops in employee errors. However, your data is only as good as what you receive. Errors have reduced by 80 percent based on the processes that we have automated by the sheer fact that we don't have people touching so many of them.

We have been able to streamline some processes just by using RPA. That has improved them.

Its ability to work with multiple platforms within the same application or "wizard". Some of the SQL functionality has also been extremely helpful. All of our platforms are homegrown. We don't use an out-of-the-box software, which makes our availability to using RPA software suites pretty limited. Then, you have a product like Kryon which is flexible. We use PowerBuilder as our application building codex. Kryon adds flexibility when we have the functionality of SQL, where we can take sets of data out of the back-end and run complex computations or do a bunch of data validations inside the wizard. It can save us sometimes dozens of steps, then if we were to try and do those same reviews using the user interface completely. The balance that we get from using Kryon RPA, alongside being able to screen scrape and frequent screen, gives us an advantage that we haven't had previously with any of our other attempts at robotic process automation.

Kryon Process Discovery is a very exciting thing. We are rolling it out to approximately 100 VM machines, but we will be using it comprehensively for the next few years, as long as we can get it rolled out here soon and start gathering more information. It's been a very exciting thing for us here at LTCG.

We haven't finished rolling out Process Discovery. We only have it on three computers right now for the test environment. However, one of the most complex tasks that we are using two full-time employees to do was have it record and monitor these employees, along with all its variations, and how they are working through a process. We then exported that from Process Discovery into Studio. Now, instead of starting from scratch on a process that a developer wouldn't know, we have a framework and outline on how to make that work from end-to-end.

The read from screen functionality needs improvement

We still do a lot of stuff in the user interface. Finding UI information and split UI need improvement.

I would like them to add more functionality from Excel, especially when you pull data from Excel.

We've had a lot of good success using this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We would like to see having a little more specific documentation, or some of the examples be easier to find. One of the big things that we get directed to now is the Kryon Community page, but a lot of that wasn't in existence or publicized when we started doing our training and education. Now, we're stumbling through using it. For the majority of the time, we have either had to try and interpret what the instructions meant or do a service desk ticket.

I have had two people go through the online training. My feedback would be that they need to focus a bit more energy on that. I would like to see that online training be a bit more comprehensive in the projects that they create, so we can say, "Here's what we have," or, "Here's what we need." I don't know if maybe they should sit down and try to develop "training" documents as well. Or, like dummy wizards, where you have to copy and paste this wizard, start from scratch and learn these steps, then you put it together to make it work, which would be similar to what we did with the in-house training. 

They could add a bit more to the online training too, since it's still relatively new for us. We don't have a "dedicated" team of people who do this. This has been a learning experience, because we only have a limited number of people who can dedicate hours to it.

It is a very stable process. It has been a learning experience for us. We have learned to make some changes in our system to add stability that users were experiencing. They were experiencing the same instability issues that we were having. RPA shed that light. We've made some changes structurally to our IT and business processes to avoid that in the future.

We have seen bugs and had frustrations. When we've done software upgrades, or opened service desk tickets, things can get frustrating because of a slow response. There might be a system outage, where we weren't informed of it until everything at our site went dark. So, we have had growing pains.

Scalability is still a possibility for us, as we will probably need more of the solution in the future. I don't have any concerns about scalability at this time. We do have plans to increase usage. 

We have two attended machines, because we have such a low demand for it right now. However, we do have nine unattended machines that run daily. We average about 1200 to 1300 wizard runs a month.

We have five developers, all from different subsets of the business. We have some that specialize in finance, account management, or those of us who came from more of an IT background (or a more structured IT role). We have a good mix of of SMEs with some IT mixed in there.

Kryon's technical support is very good. They made some core changes that have improved the solution over the last two years.

We have used other RPA tools previous to my time at LTCG. None of them were successful after the original deployment. Therefore, we decided to wash the project. While I don't remember the name of the software, the reason they were unsuccessful is because of the language that our user interface is built in.

The initial setup was complex for us, but that was, in part, from the way we operate at LTCG. I wouldn't put that on Kryon.

From start to finish, the deployment was four months.

We did the deployment all internally.

We do upgrades three times a year for both Process Discovery and Kryon RPA. Essentially, we have a structured team set up who opens up in a project, then we start reporting against the project. We try to get all the requirements built, but it all runs through me. So, I run it as a type of the project manager. Then, we deploy the upgrade alongside the customer review team. It is not as rigid as some other projects should or could be.

We currently have four total users from IT, who assist us in maintaining the Kryon server, Process Discovery server, and upgrades for deployments, which includes security and overhead. There is also my role, which is just performed by me.

We've more than broken even over on the license. Year to date, we are at $120,000 in savings.

We have been able to alleviate two FTEs, which was a big savings for us. We were able to reuse those resources in other locations. It is over 5000 hours a year in total savings.

We were able to reduce our processing speed in time by 65 percent. That is just simply by using a robot versus a person.

Licensing costs are about $100,000 a year without any additional costs.

We had requests out to four vendors: Kryon, UiPath, Automation Anywhere, and Blue Prism. Kryon did not end up being the most financially inexpensive, but it did make the most sense based on the ability of having business users develop, not IT people. The product bridges the gap in terms of ease of use for business users with no tech background, compared to a UiPath or Blue Prism. With those solutions, you have to be a .NET developer to use them. Kryon allows people who are business-oriented people to use it.

Understand that you need to have a very well-documented framework of what you plan to automate. Not necessarily the idea of, "I want to automate this task." But, as a company, don't be narrow-minded to believe that these are the only tasks that we can automate. You'll find that there are a lot of groups which are doing things that you may not know of that you can automate very quickly. Be very open-minded when you start working with the solution, because you'll find that a lot more doors are open than you originally anticipated.

As with anything in software suites, you are always going to have challenges where people didn't know something was a function or didn't know this is how that worked. Kryon has a good start in trying to bridge that gap between the developer, who would look at something, and go, "Yup, I can pull a lot of this data from SQL, and I just need to click these buttons," versus someone who doesn't have a technical background.

There is still some growing to be done. It is necessarily the product that has been the problem. It has been necessarily some of the responses that we have gotten from Kryon itself.