The use cases are technically things that can be easily virtualized and offered as a service on a public cloud. For example, we can use some services like software as a service on the public cloud. However, we can't do this with other services, like the legacy system of an IBM mainframe, some old databases, or some applications that we cannot transfer. So the capabilities of the legacy system determine what we can do.
We have developed our own KPIs and based on those, we can see the productivity of MTTR measured in the time between failures, recovery time, and flexibility. We can see productivity in terms of manual work that has been automated. So ControlUp makes us leaner through automation and optimization of the processes.
In terms of the public cloud, ControlUp's features make us feel very secure. Security, uptime, and reduced capital expenditures are the main reasons we use ControlUp. So basically, the money that we consume is based on the amount of time we are using a service. ControlUp offers a return-on-investment type of approach that helps us.
Integration is always a problem, and we feel that we are doing our best and the service provider thinks they are doing their best. I guess if ControlUp's system could be more capable or if people could understand the integration part, that would be better. The service providers feel that this might be some inherent deficiency on our end, and I think this is their problem. So I believe integration is one issue. Everybody is looking for a seamless transition, so integration needs to be very seamless. Also, everything should be more automated and visible, so we have a key performance indicator or something that we can quickly evaluate. If those types of things are available in the solution, it'll be easier for us to make decisions. And it'll be better for the service providers to market their products because they can say that these are the most significant features or these are the essential aspects.
I've been working in security for the last 20 years.
We do have a quality assurance department and a performance department that reviews all those types of things. They have a set of criteria for the system, including errors, false positives, false negatives, and system downtime. They also have the criteria for change management, including patches and updates. So there are multiple key performance indicators, and based on that, they come up with a report that shows this is very stable or unstable or needs to replace a wrong or right decision.
But stability is a relative term. We want everything to be error-free and crystal clear, but there is always a gray area. And the gray area is that the service provider comes up with software updates, new features, or feedback from other customers, and they implement it in our system too. So it's a moving target even if it's a turnkey project. And I believe it's turnkey, but the product is not mature, whoever the vendor is. So, for example, let's say you are the vendor, and I believe you guys are not fully functional. I know that the solution is 90 percent functional, and 10 percent can be modified, but it looks like they are just trying to learn like us. I may be a little bit paranoid or a perfectionist, or maybe I'm on the extreme side of Six Sigma, where I want 99.99999 percent, or I don't want to pay. So stability is a crucial factor, but we compromise based on our budget constraints. At the end of the day, you get what you paid for.
Scalability is also another trap. Say, for example, we initially established a master service agreement that says we need to do this much work, and it covers three years. And over three years, we are locked in because the new features and services mean the rate will be higher. So we could end up at a point where we have to ditch ControlUp for another company that can give us a better bargain. So there needs to be some long-term planning regarding scalability. You need to have 5 to 10 years of visibility to know on the first day what your partnership will be with the client in the long term. You need to predict constraints, features, or costs two years from now. Take Oracle, for example. If you have the Oracle system database for expansion, you need to pay any licensing fees. So what may happen, that company may use Oracle for some things and IBM for others.
Scalability is a tricky thing. It's up to ClontrolUp to figure out how to handle it. The solution should be scalable to retain a client in the long run rather than a short-term benefit. If you get a short-term benefit, maybe you can make money on the client's first 100 clients. However, you may not make money from the next 100 clients because your price is so high that the client switches.
I think this is related to our strategy. At this point, things are changing because of COVID. There are so many projects on hold, but we randomly get new projects because of remote work and those types of constraints. We reevaluate our scale regularly. I can't say it's every quarter, but the senior management must reassess what they should do and prioritize based on need. We had an ideal vision and a definitive strategy two years back, but now this strategic plan is tied to the short-term tactical plan. We're thinking about what is essential to do right now, rather than the plan we set several years back.
After-sales support based on the warranty or SLA that we agreed on is another thing they can improve. I would prefer a service provider who gives me peace of mind although it'll cost me, and we have a limited budget, and you might say, "We cannot do this thing." ControlUp will do more business and get more customers if it can raise its integration expertise and become more very flexible.
In terms of support, there are two constants in the field. One is technical know-how. There are older technicians who have been on the job for 20 or 30 years. Often they are reluctant to change themselves or it's hard for them to adopt virtualization or different kinds of new technologies. So it is an inherent deficiency from the customer side.
The reason we switched to ControlUp boils down to flexibility and cost. Miscommunication is another factor. By that, I mean there are disagreements because we assume something and the other party assumes something else. So I think it's a fight-or-flight type of situation right now. Maybe you can get a contract today for two years, and after two years, perhaps our expectation is too high or maybe your expectation is so high, and the market is very fluid right now. There are so many complete solutions coming up with different offerings, so a client switches.
The initial setup is complex because they have the template. For example, say you are the service provider with a template or some use cases for another retail store or another customer. Your engineer, architect, or solution manager thinks that people like this, but one size doesn't fit all. So you are customer support or pre-sale support, and you're helping a retail customer like Coles, JCPenney, or Starbucks. It's possible that the Starbucks template might be helpful for Dunkin' Donuts, but Dunkin' Donuts might have a distinct set of constraints.
First, we did the pilot program in one geographical area because we operate all over the United States. So our strategy was first to do the pilot then deploy on a regional basis in the Northeast region, like New York, New Jersey, or Connecticut, or in Northwest California and Nevada over the next three years. It will be in phases, but there will be a pilot first. However, sometimes a vendor will go above and beyond during the pilot just to get the contract. But when it comes time for the real thing, they say, "It was something different we were not expecting." We believe that in a pilot, you need to deal with all kinds of scenarios. So maybe it's our fault that in the pilot, the salesperson came to us and we gave them our answer, and he made the pilot. But I think the project's integration should be seamless from end to end, whether you blame me or you blame yourself. The critical thing is that if you blame the customer, the customer is not happy in the end. Customers are not willing to work. They are not very proactive or agile. Customers are not like salespeople, who are providing the product. You are selling your product, so your mindset is different from the customer mindset.
For deployment, we usually do a partnership with the vendors. So they handle about 75 to 80 percent of the deployment, and after deployment, we are responsible for 100 percent. But this depends on the footprint. It depends on the whole scope in that region, area, or department — in that enterprise section of a business unit. But we always have issues with the operation. That's why we try to automate more. Operationally, staffing is a constraint for us, so we want less and less manual intervention.
There are several scenarios for deployment. In one scenario, we prefer some managed service provider or integrator from our pre-qualified list. For example, there is a procurement department, and they have a preferred vendor or something like that. So they approach them and do some pre-implementation, or sometimes we go out of the box, or we go for some other new venture with a new vendor. In another scenario, we may hire a consulting company to assess where we are and what we need to do. For example, there are some regulations that we have to comply with under the California Consumer Privacy Act. We can hire a company who can help us with compliance. We know what we have to do, but we employ a consulting company to help us and even interview us to make sure that we don't make mistakes. Even we interview ourselves and assess ourselves, but having an extra set of eyes is safer.
ROI is relative. I cannot disclose any specific figures, but I can detail our approach to ROI. When we made our contractual agreement, we set some baseline expectations. And if those are met, we are okay. But if we deviate from those benchmarks, then it is a problem. If that's the case, it's better to switch to a different vendor because this vendor is not delivering as promised. So for us, we expect everything that is in our scope, and if the vendor twists it around and says, "No, this is not the case," then this is a gray area. And I think it should be black and white. Although from the customer side, it's better for me to make things gray to get as much service from the vendor.
I think our license is yearly, and there's a limitation on the number of licenses that we agree to. It's somehow related to the number of licenses, but I think everything is consolidated in the annual agreement. They always come up with a new story or something that isn't covered or that these facilities we are asking for are not part of the initial agreement. So there are some hidden charges and some service charges that we were not aware of at the time of the agreement. It's not a one-time deal that was settled when we signed the contract. It is a two-year contract for a certain amount then there are hidden service and maintenance charges along with some extraordinary root cause analysis issues. For example, when we have some problems, we go to the vendor, and they say, "We can do up to this much, but if you want further, it'll cost person-hours, then you need to pay."
There was a whole process. First, there's a request for proposals and a proof of concept. They evaluated different vendors according to some baseline criteria for the system and features we must have. And based on those essential criteria, the procurement department assessed and considered a shortlist of providers according to features, return on investment, service-level agreement, and the expansion plan.
I would rate ControlUp Real-Time eight out of 10. I think from the customer side, you need to know what you want and have a clear idea of the scope so that there isn't scope creep. From the standpoint of a service provider, you should articulate your questions or your questionnaires or talk with a customer. It should be enough that the customer doesn't say after three months they weren't asked. Your questions should be very agile and open-ended so you will know inside out when you assess any proposal. But at that time, what happened? The salesperson went, "We just need to get the purchase order." It's okay that you got a purchase order, but if I work for a company, I will always be on the other side of the fence. I will never represent any manufacturer or something, but I believe that their mindset is focused on the account. Their mindset is centered on the purchase order, and I think it's good that you have a purchase order or that you won the account, but the important thing is that scope should be well defined from your perspective when you have the scope.
A customer may not tell you everything, and then you've dug yourself into a deep hole where you won't foresee an integration issue happening. And you have no clue, and you are saying, "We will see." And the customer said, "We need to complete this task by this date." So everyone needs a well-defined scope written down at the outset. It will save you from haggling later on because something needs to be descoped. Customers will not say that "You need to do this thing. You already show that this was another part of the scoping."
