I have been involved in Automate since the proof of concept, and I've been working on the setup and maintenance of this project for the past three years. Setting up Automate isn't too complicated. However, installing any software application involves some prerequisites and planning. You need to understand the best practices of the project. It was a little more complicated initially than now. After three years, we can set up a bot with our eyes closed. 

Deploying attended and unattended bots is similar because we have the figures you can use for how you want the robot to start. It's pretty easy to say that I want an attended bot because I am the user, and it is a mixed project. Sometimes we have a complicated process we need to program, like when we receive an email request and we need to start a bot to make a ticket. It's not complicated. 

We started seeing value about six months after we created the automated processes. By that time, we had begun to develop some best practices. When you get an update, you need to install it the first time. You don't lose anything, but it isn't automated. They have two or three updates every year. There is routine maintenance, but you don't need hard services to maintain it. We typically review every new process and need to do some maintenance when there are errors. 

Deploying Automate required a few people. We need some IT people for technical requirements because it involves the Active Directory and configuring the servers. We also required functional people who understand the process and an implementation consultant. The team size depends on the organization because some organizations have mixed profiles. You might be able to do it with three, but it's easier for us to have the most qualified person in each area. 

The Initial setup was not complex in any way. It was pretty straightforward. We didn't really have any issues with it.

In terms of deployment, everything happened quite rapidly. You can basically download it and install it and then you can work with it immediately. Then, around 50 days later, this system will ask if you want to continue working with it. If you do, you can send just an email and it can be used permanently. It was very simple.

The initial setup is straightforward. We need to install the solution and open a few ports. The deployment can be completed in one hour on my own.

Automate doesn't make much of a distinction between attended and unattended bots. They are essentially the same thing, just with different workflows. For example, if we are setting up an attended workflow, there will be some actions that require user input. An unattended workflow, on the other hand, is completely automated. The pricing for both is the same and it is relatively easy to deploy. Once we have developed the bot, we can set up a skill, trigger, or file and it will run on time.

Once we have Automate up and running, we can begin working on it if we have a developer console. Setting Automate up is part of the process. So, once it is set up, we can start developing from there. A simple task, such as reading an email and moving the file to a folder, can be developed in two hours. However, this is a very basic task.

I was not involved in the original deployment, but I've been involved with deploying the newer versions. In this case, there was a process with deployment because we had to pull every customer service rep for every account and what type of reports they wanted to customize to SQL and then deploy it, automate, and identify whom the reports need to be sent to. That process was just logistically challenging but not hard in the tool itself. For example, if you set it up for one customer, you can replicate the same task and just change the query, and then run it for another customer and change the folder structure and the to and from emails. You just need to go live once you set it up and test it. As a work multiplier, setting it and forgetting it is really good.

It takes about two weeks to fully deploy the solution because of the number of customers we had and the number of customer service reps, and testing and getting the customer feedback and things like that for every single customer. It took me a couple of hours for each individual, but that's just based on response time with emails and people. But once it was tested, I got the feedback, and it looked good. I just set up the schedule and ran it. It was often running. The sad thing is when you create a tool like that and make it so robust and functional, you have to maintain it. You have to then check on people to say, "Hey, does the customer still want this report? Are they still an active customer?" Because we just have automations going on, and no one's looking at them. Fortra's Automate is one of those things where if you set up too many tasks, you have to manage them. Or if you have a break/fix, like a server goes down and you have to build it back up, you have to make sure you automate your backups, replicate the server, and make sure there's a backup server, make sure you have your contacts to get a backup of license keys and everything else. That hurts because when you have an application that's so important, it hurts you when or if it goes down.

It's agnostic. It can work on the cloud or on-prem. Some customers want it on-prem, and some customers want it on the cloud. It doesn't make much of a difference from Automate's perspective. It's the same software, and where you deploy it doesn't make much of a difference. We have integration with AWS and Azure. 

I work in development, so I am involved in deployment for clients. It's pretty straightforward. You just install it and set it up. There are some prerequisites where you have to open a few ports and do things like that. Overall, it's straightforward. You can do it in maybe an hour.

After you have it up and running, you can just start working on it. You have a developer console, and as soon as it's set up, you can start developing and deploying from there. A simple, basic task such as reading an email, taking a file, and moving it to a folder can be developed in two hours. 

In terms of the ease of setting up and deploying the attended or unattended bots, we don't do much differentiation between attended and unattended bots. They're the same thing for the most part. It's just about how you'd set up the workflow. If you are setting up an attended workflow, for example, you'd have some actions in the workflow saying that wait for a user's input or something like that. For unattended, it's going to be completely end-to-end. We don't make much differentiation in that case. The pricing is the same, and it's pretty easy to deploy them after you've developed them. 

The initial setup is straightforward; it's just a matter of installing the tool onto the server, and that's very simple. There were three staff members on the deployment team. Now I maintain the product by myself, and it's very lightweight in terms of maintenance. Upgrades come in once or twice a year, and it's just a matter of running the installer to install them. 

Setting up attended and unattended bots is very simple; we can develop on one and then bring it over to the other. The timers, schedules, code, and so on are all brought over. We began developing RPA workflows half an hour after deployment.  

The implementation is ongoing. It's not a one-time thing for us. We build new automations every few weeks for new software, involving requirements, development, and testing.

It does not require much maintenance, thanks to backward compatibility. We haven't needed major code changes due to version upgrades.

The initial setup is very, very simple. In fact, one of the banks that is a client of ours for some other products plans to move from UiPath to AutoMate mostly due to the complex implementation process involved with UiPath. They have asked us to wait actually until the business comes up and then they will move to AutoMate.

It does not take a long time to set up. We have only one server, and any number of workflows can be created with one license depending on the size of the file and aspects like that. You just need a one-server setup. You don't need different kinds of products when your number of workflows increases. That is a real added advantage ofthe implementation. Our USP is, easy to implement, fast return on investment, and scalability.

I wasn't a part of the deployment process. It was done several years ago, and I joined the team just this year.

In terms of the setup and the environment, it's virtualized on-premises. We have three EXE servers, one service box, and one server that we run the client on.

In terms of maintenance, I'm not aware of any maintenance requirements.

The initial setup is probably pretty straightforward, or, at least, that's my understanding. We had people System Engineers that we're able to set up pretty easily.

The biggest part about deployment is setting up the dedicated servers, which we're actually installing on the services, and therefore it is pretty painless.

The initial setup was challenging as we, being the first bank in the country, had limited knowledge about transitioning to the cloud. Obtaining authorization from the central bank was a critical step. With significant assistance from the enterprise and Microsoft, leveraging Azure, setting up on the cloud posed its difficulties. Although Fortra's Automate is on-premise, our CRMs are cloud-based. We're in the process of using APIs to bridge our CRM with the on-premise database, creating a hybrid solution, although the CRMs are entirely cloud-based.

I found the initial setup to be quite straightforward. It's nice and easy. It's not an overly complex process.

The deployment is pretty fast. We got it done in under one day.

The initial setup is straightforward and very easy. A user company just needs to follow the the implementation steps. 

We found the initial setup to be easy. It's not overly complex or difficult. It's straightforward for the most part.

The deployment is pretty fast. It takes about two hours to deploy the solution.

The initial setup was easy. One person is required for deployment and maintenance.

The initial setup is quite easy for us, although this is in part because we have been working with the partner for a long time. We have lots of direct connections for support, so if we have a problem that is a show-stopper, or something urgent, then we have a direct channel that bypasses the usual help desk.

The installation of HelpSystems was not difficult at all. I'm not technically strong, however, I could do it myself without too many problems. It's pretty straightforward, even for non-technical users.

I don't remember how long the deployment took, to be honest. It was one of the easier installations I've dealt with on the platform. When I've looked at other platforms, I've found that some of their rivals were very difficult to install for a person with my lack of experience. For example, Micro Focus was one I tried to download and install and I gave up due to the fact that it was just too complicated. I can compare this experience to Micro Focus where I just found I wasted a lot of time and got very poor feedback. I found HelpSystems refreshingly easy to install.