What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using it for five years now.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What about the implementation team?
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.
What was our ROI?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?