CHRIS: That's right. Yeah. That's exactly right. And it's interesting because if you look at some of the SaaS-based platforms, especially if you're looking at the benefits, the pros and cons of SaaS, it truly is one of the biggest downsides to a SaaS-based model, especially a multi-tenancy model. And this is most of the SaaS platforms that are out there today. They're going to have some limitations. Now, it doesn't necessarily mean that they can't do what you need for your first phase of your project. And that may be fine. But we encourage clients to really look further down the horizon and really understand where things are going to evolve or potentially evolve so you can project forward.
One of the big things that we recommend looking for is, can the system that you're working with currently do some of the intricate customizations? Do they have the ongoing maintenance to be able to handle some of the upgrades to your systems? Is one of the things you need to understand whenever you're working with disparate systems is you're going to need to upgrade and patch those systems from just a pure security perspective, if not the functionality enhancements, etc.
And so whenever these things change, it can break the integrations and it can change the protocols for the integrations. And this can cause a lot of challenges logistically if you don't have good ongoing maintenance. But yeah, whenever you talk about customization, it raises the hair on my arms because it truly is one of the biggest challenges that you see with Multi-tenancy SaaS systems. And like you said, that's why we started doing this. That's where we really saw a huge value to clients is being able to provide this unlimited capability. Just to be specific here, whenever we do implementations, they're typically implemented as a single-tenancy SaaS eCommerce solution, which gives basically the majority of the benefits of being SaaS-based with all of the benefits of being able to fully customize. And so I think that's a huge strength that folks need to know about and just understand the limitations.
If you do choose to go with a lower cost solution or a solution that is SaaS-based, be aware of what the limitations are going to be. And in particular, understand what it's going to take to customize the system, because that's usually about 80 to 90% of the cost that is going to exist long term is going to relate to how many customizations there are, and what kind of maintenance there is? That's really where your cost is going to grow if you're trying to fully automate your processes. It's not going to be just the cost of the tool. It'll be the cost of actually implementing your business fully and customizing to cater to your business.
RON: I agree with that. I want to talk about two things. One, I'm going to mention something and then I want you to talk about securing the data, because that's a big one. But for me, one of the things that's been very interesting, I don't know what else to call it, data manipulation, data calculation. We really haven't talked about it, but this is where I've seen so many other platforms fall down. For example, we had a client who just had an eCommerce storefront and an ERP and then they introduced Amazon into the mix. Typically, not a big deal, right? You're pushing your products up to Amazon to be sold.
The problem occurred was every two weeks—instead of in real time, every two weeks—Amazon Central would send down the sales record of the money that they were being paid. Well, the problem would happen and I'm just going to give a quick example. They would sell four items on Amazon. Those orders come down in real time. Now, in the ERP, they have four items and let's say they each sold for 25 bucks just to make it simple. Now, in their ERP, they show four items. They fulfill it, they ship it, they're gone. Now, one of the people, whether they're being dishonest or not, they return that item. Well, they don't return it to them. They return it to Amazon. They request a refund on Amazon. Now on the 15th, when their sales record comes down, our integration is trying to reconcile the dollars that are finally paid from Amazon with their ERP fulfillment. But the payment from Amazon comes down and said only three units are sold at 25 bucks a piece. And there is no one-to-one line matching it's out sync. One of the things we had to do for this client is if the items that came down from Amazon, at the Connect level, we would sync. And if they were a one-to-one match, we would tag the item in the ERP sold.
If they didn't match, we actually built them administrative interface that they could log into a web interface and they could see everything that did not match. So they could go through and reconcile and say, well, which three ended up being paid and which one was the one that was returned? Because that information didn't come down from the sales record, they'd actually have to go figure out which one initiated a return. And then in that interface, they could go through and tag which one of the records is actually been paid, which one was returned. We had to do some additional data manipulation. And I've seen where people have had us turn Clarity Connect's database into a data warehouse where data from both sides of the integration were stored there and then have us throw a Power BI or one of our reporting solutions on there.
I've seen some really interesting things with data manipulation. Even pulling a sales order in, we go out and check to make sure it's a viable shipping address. If not, edit the address in line before we pump that address into the ERP for or fulfillment, things like that. Data manipulation and calculation can definitely be something you're going to want to know. But I'd love for you to go into securing the data and some of the different protocols and compliancy issues that we deal with that we address with our integration platform.
CHRIS: Absolutely. And yeah, what a great point on the data manipulation side of things and automating that where possible. It can be huge to be able to scale. And just along those same lines, being able to customize for specific security requirements. There are so many security requirements nowadays, mostly because there are a lot of breaches, unfortunately, that occur. it's expensive for the end users that have real issues because their data was breached and taken advantage of. In addition, it can be really expensive for the organization to be able to try to resolve that or patch up their credibility and maybe even impossible to do. And so it's very, very serious overall. And so yeah, ultimately, whenever we're doing an integration, especially if it's incorporating very sensitive data, then we want to work with your team to understand what the data is that is sensitive and help your team understand certain requirements if you don't.
We're not lawyers here, but we do have a lot of experience working with HIPAA compliant websites,or NIST, CMMC, GDPR, PCI DSS and other different compliance needs. And so we can really help get you started going in the right direction. We work with a lot of partners who basically will do audits of your internal systems and work with your internal team to make sure your entire process is HIPAA compliant, for example. And then as part of that HIPAA compliance, also audit and work with our systems to make sure that they're constantly patched and kept compliant. And so anyway, the point is that whenever we're implementing our connector, we're looking to bring to bear some knowledge and experience that we've had in your respective areas of security needs.
And in particular, we're happy to bring partnerships that we've had a lot of success with, into the relationship to help expand your capability there and make sure that things run seamlessly for your organization. And then specific to our connector, from a technical perspective, we have the ability to do some really interesting things. And I'll just give a few examples here, Ron. But just for the HIPAA scenario, as an example, we do have the ability to persist data for caching and performance purposes. And as you can imagine with HIPAA, that can be a really major concern. If data is cashed and persistent, most clients choose not to persist data that is secure. Maybe it's PHI data, for example. But ultimately, if there's a need to persist data, we can encrypt it at REST. We can allow the system to enable robust logging for HIPAA compliance.
We can enable a very specific key vault system so that all of the data that's encrypted is only decryptable on an individual account level or customer level, for example, or key record level for the data so that every single record has a unique encryption within the already encrypted system. And then we can further encrypt that by tokenizing the data and storing the secure data in another vault that only shares with us a unique identifier, that we then have to log in to be able to get the secure data out of the vault. And without boring you with all the details, the point is that the system that you're working with, it really ought to be able to handle very specific needs for security purposes. Mostly, making sure that the entire system is sanitized of any secure data. Whenever these integrations are running, you don't want to leave data in your connector and your integration platform, that could get compromised. Most of the time, the big requirement here, Ron, is just to make sure that it doesn't stay around after the job completes. But in some cases, if it does need to be persisted, it needs to be persisted securely.