Google Play / Apple Podcasts / Spotify
On this episode of the podcast, we talk to co-founders Jackson Ostler and Dave Aditya about their company Plena Data. Plena has built their own RPA platform and has focused the offering on some very specific finance and accounting use cases. We talk about their experience getting into the RPA space as well as their model for how they operate and deliver value to their customers.
Interview with Jackson Ostler and Dave Aditya of Plena Data
SPEAKERS
Jackson Ostler, Mark Percival, Brent Sanders, Dave Aditya
Brent Sanders 00:02
On this episode of the podcast, we talked to co founders Jackson Ostler and Dave Aditya about their company Plena data. Plena has built their own RPA platform, and has focused the offering on some very specific finance and accounting use cases. We talked about their experience getting into the space, as well as their model, how they operate, and deliver value to their customers. Thanks for listening. Jackson, Dave, thanks for joining us. We'd love to hear about your experience with RPA and automation. So why don't I hand it right over to you give us a little bit of background? Tell us about yourselves in Plena data?
Jackson Ostler 00:38
Yeah. So I'm Jackson, I'm here with my co founder, Dave. And we definitely had a winding road into finding ourselves eventually, you know, building an RPA platform. And it started back in 2017. When I was enrolled in dental school, and my co, my who then became my co founder, Dave was a senior software engineer at Adobe. And he, the same my sister met me ended up marrying my sister and convinced me to withdraw from dental school to join his startup company that had zero customers and zero revenue. And for some reason, I thought that was a good idea. So I convinced my wife, we withdrew from dental school, we were supposed to go to the Midwest, to Indianapolis. And I moved back to Utah. And Dave and I started this little company that we named Plena data. Yeah. And so it was an interesting story, how we kind of morphed into an RPA platform, I would say, late 2018 and early 2019. So originally started off with my background was in report automation. So we were automating these reports and our early customers, fortunately happened to be CFOs, and controllers and accountants. And so we were very in sync with their accounting processes as a result of, you know, wanting to automate their reports. Quickly that automation into reports turned into like, Hey, can you automate stuff side reports, because it got a really competitive market on the report automation side with Domo with other Power BI and you know, BI tools coming in. So we started automating general task and accounting, and quickly realized that each of these automations, we were building or custom bots for each of our customers. And so, as a result, we didn't know what RPA was back then, we just developed a platform internally, to make our automations more efficient, and to you know, roll out more of these automations to a larger audience, and quicker automations, if you will. So we built a platform internally for the sheer purpose of building bots for ourselves. And as we were doing that a few months into, we kind of realized that there's an industry out there called RPA. And people are actually building platforms to build bots. And our platform is quite different than what's traditionally out there. We will dive into that when you ask that question. But yeah, that's and and let me just, excuse me, let me make one extra point there. So I want to plug our first two employees who joined us in late 2018, and then 2019, as Zach lounsbury. And Andy records, they have been amazing assets to our team, and it's them alongside Dave really built our platform to where it is today. And it's been, like Dave mentioned, the first time that we heard the words robotic process automation, or realize that that's what we had been building was 2019. And so it's been maybe 18 months into this, you know, with the foot on the gas pedal fully inside of RPA.
Brent Sanders 03:42
That's great. Yeah, I mean, the word or the labels in this industry are confusing. And we typically have a nomenclature discussion with each guest, and it varies slightly, but it is funny, you know, the automation of business process, the automation of, you know, what needs to be done in order to pull a report or just operate a business. It's like, I thought that was just software injury. That's what you, right? I mean, I, my background is largely in software engineering, and web and mobile development. And just part of what has become RPA has been just connecting the dots, it's like, Hey, we need to get certain pieces of data in place in order to do something larger. So it's funny when you hear about RPA. Now hyper automation, or whatever your latest pieces is put together with it. hyper intelligent automation . hyper Intelligent Automation even better, yes, you're up to speed, I'm glad. But yeah, it's funny, you know, they're the labels really put a sort of I would put it like a face to a name and a sense of like, what we're actually trying to do here is to limit the amount of, you know, labor intensive work, that is going into things that aren't a good use of a person's time.
Jackson Ostler 05:00
Yeah, and I would say the kind of the, the purpose of the label is really to encapsulate the whole, the end to end process of automating things and kind of giving it a giving it giving it a name so that the business user can understand, you know, here's a specific piece of technology and what it does, because there's, like you said, there's a lot of noise out there. And there's, there's so much automation on specific workflows on specific tasks. And there's automations on, you know, specific back end processes. But RP kind of is like the umbrella under which, you know, you can kind of build any kind of automation, no matter how complex or how intricate your processes, and an evolution that happened with us, Brent in early 2018, is we realized that out of the customers that we had 90% of what we were being asked to build was accounting automation. And so I would say today, our go to market strategy, or the way that we're interacting with prospective customers, the way that we're new bots that we're building for our current customers, it's almost exclusively in the accounting space. Yeah, we happen to stumble into an area of high demand. At this point, it happens to be accounting and finance where bots are desperately needed. And we're kind of sticking to it because we don't see other RPA providers focused on a vertical or industry industry segment. In this case, we are doing bots for you know, CFOs and controllers, who are looking to automate typically, their month in closed process, accounts payable, accounts receivable, bookkeeping, sometimes payroll and commissions. The other sprint that we're seeing right now a high demand for is integration bots. Yeah, and this is an interesting one, because this really takes the kind of the benefits of RPA to a next level. Typically, integrations in the software industry have been done using API's. And if a vendor software provides an API, then you kind of have to build, you know, some sort of API get and put request calls, and then go connect to the other software you want to integrate with. And that also has to have an API. But what happens when you do not have access to an API or what happens when the API given is not sufficiently robust? Meaning it's not touching all the endpoints you wanted to touch? or worst case, you know, there's no API, and the vendor restricts any sort of integration all together. So now the end user of that software is stuck, the only option for them to kind of add efficiency to their processes is to switch systems. So we introduce will say, hey, what if we make a bot that will go open one of your applications that is not, you know, integrating with the other one, and these two systems don't talk to each other. But we will read the screen from one of these systems, go to the other system and write to that screen, and run it frequently enough, and thereby creating an integration on the front end, without actually, you know, having anything to connect on the back end. And this integration is very custom. It's super robust, it can be fully, you know, adjusted to the client's needs. And it doesn't have to, it doesn't need any interaction with the vendor. So it doesn't cost the end customer anything more than what they just have to pay for the bot?
Brent Sanders 08:07
It's great. Yeah, I mean, when you look at the types of integration bots that you guys are working at are, are they typically integrating with like legacy really old school systems? Or they a mix of new and old? What's the profile generally look like?
Jackson Ostler 08:23
Yeah, when we shot this idea around, we were like, Oh, it's going to be mostly useful for customers who have legacy, you know, old systems that don't have API's or just running on their own Windows server somewhere in the basement. It turned out that it's a combination of both the legacy and relatively new systems like NetSuite or, you know, fairly robust DRP systems. The reason being, state of the art integrations available. But it doesn't exclusively give you access to everything that's available in QuickBooks Online. Right. So the API will have, let's say, 20 endpoints. And if something you're looking to integrate is outside of those 20 endpoints, you don't have an option to integrate it. Moreover, the way you can update that endpoint is only through the you know, the get the put the Delete and the update calls the API provides. But what if your business logic is a little more nuanced, and you need some more, you know, additional calculations or computations to be done along the way, you can do that. But on the UI, you can go update the form pretty easily. So that integration, surprising to us. But you know, that's also a pretty common like, we're doing it with Shopify, we're doing it with WooCommerce. We're doing it with you know, NetSuite. We're doing it with, sage. So there's all these relatively intact Microsoft Dynamics, relatively robust systems, there still require a UI dependence for the integration.
Mark Percival 09:57
Yeah, yeah. I mean, I think you see this a lot of times, with right? They kind of lag behind the rest of the software package. Because they're kind of an in a lot of ways they're an afterthought, right? It's QuickBooks first needs to address the customer UI. And then it's okay, we need to add something to the API later on.
Jackson Ostler 10:14
Right? And ADP has not really kind of their high demand, you know, it's not the product that they're servicing. It's something they're having to do, because the developers are knocking on their door. But their main product is the UI itself. And so that's where all their focus goes to.
Brent Sanders 10:27
Yeah, it's interesting. So when you guys are looking at integration, I'm curious, you know, within your own platform, I guess, let me backup a second because that actually reminds me so you're writing all of your automation is run through your platform? Maybe we could back up? And you could tell us a little bit about, you know, how does the planner platform compared to like, your generic UI path or automation anywhere? Like, where do you guys fit in into the realm of existing vendors.
Jackson Ostler 10:59
The first point of differentiation is that on our platform, developers build bots, the platform is designed so that software developers build bots for end users.
Dave Aditya 11:10
Yeah, so that's the key fundamental difference. And as a result of that difference, we get two offshoot benefits that come with it. One is the functionality of the bots we can build is, you know, can be extremely complex, and really highly functional bots can be built, because when you're dealing with developer, developers, they have access to APIs they have access to we can structure the platform in a way that you don't have to drag and drop things, you can write a script, you can write really complex business logic in there. So that's the first thing, the second thing is the cost. And we believe we are pioneering the penetration of bots and mid market, because our cost of building a bot is a fraction of what it would be in UiPath automation anywhere, primarily because we can build a bot in five to 10 business days, you know, a really complex bot. And so the biggest cost of building a bot, as you know, is the development of it. So if the time to build a bot shrinks to, you know, a few business days, the development cost goes down dramatically, and you're not compromising any of the functionality. Now we understand the pros of UiPath automation anywhere I've taken they have gone after what they call the citizen developer, meaning anybody who's interested in building a bot can quickly go through a manual and started earning their platform and doesn't really have to be a coder to you know, build their first bot, in fact, doesn't have to be coded to build quite a few of their bots. And when they do get and coders do get involved, it's usually on situations where the UI path at the platform itself cannot handle something off the shelf.
Brent Sanders 12:41
Right, yeah. And we've had a couple of guests on and they've described, you know, the most successful of the citizen developer programs are very labor intensive to get going. I mean, it does require a lot of work to get a program going and continuing to develop that sort of talent, right? I mean, it, it's getting someone you're you're gonna learn to code, essentially. And that might work really well in the context of your role. If you know your job very well. And you know, the operations and, you know, you're going to move a spreadsheet from one place to another and email it along. That may be great. But I mean, I've always been, we've we've been skeptical around the claims of you know, what, what gains can actually be had, once it gets beyond a certain tipping point, it's like, okay, you're going to need, like a software engineering culture in order to make this thing work long term.
Mark Percival 13:36
But you know, on the flip side of that, there's the issue that the software engineer not only needs to be capable of, you know, actually producing the code, but writing the code actually understanding the problem. And I think a lot of that is what drives sort of the low code platform desire is that a lot of times the person that understands the problem to be automated is actually not a coder. How do you guys kind of address that?
Jackson Ostler 13:55
Let me first start by saying the way we address that is by the amazing CEO and co-founder sitting next to me, because during our the inception of Plena data, he learned how to translate business requirements into software, deliverables. And to this day, he, you know, as we hire and onboard and build our company, he teaches all of our software developers that skill, that is, I guess, not innate inside of most software developers.
Dave Aditya 14:25
Yeah. So this is that's a really interesting point you brought up mark. So I essentially became almost I would say, you know, an ad hoc accountant, just talking to so many CFOs and accounting, I was like, Okay, I need to learn their lingo. So I just sat down, I went to like, cpa.com websites, I'm reading books on Monday, doing stuff that I have no interest in doing,
Jackson Ostler 14:44
but I let me interrupt him and say I would, as we were building our company walked into his office, which at the time was a bedroom and he had YouTube videos pulled up of accountants explaining an Account Reconciliation, a cash credit card reconciliation, and so he everything he's saying, absolutely. I watched him do it, he became a pseudo accountant.
Dave Aditya 15:04
Yeah, so it's just my thing as a founder, right? Like Jackson had to wear so many different hats. And then I had to wear so many different hats. And we kind of constantly are evolving on what our role is right at the beginning was just like, I'm the only coder available, then Okay, now I've got some coding help. But now, you know, somebody's got to sell. And then somebody's got to sell some he's got to learn how to sell and you know, all those things. Just Anyway, I'm derailing from the question in hand. But basically, that's the key. That's the key piece that is required to translate the business knowledge are the business logic of what the bot needs to do to the software requirements on how to build a bot. So there is a gap, and typically needs to be filled by somebody who can understand enough about the business and understand enough about the software to fill that gap. And that's a very personnel level question. So we typically have those resources in our company. So when we sign up a customer, the customer scopes out the process for us, and we say, okay, you just tell us the business requirements. And we will convert that into, you know, the technical requirements for the bot.
Jackson Ostler 16:07
And we've now reached a point in our company where we've brought on partners such as Deloitte, other smaller accounting firms. One out in New York, we just started working with called Citrin Cooperman. And they have a team dedicated to generating leads scoping bots, and translating business requirements into technology. Now, we're still part of that translation, but it's becoming much easier. As we outsource that piece.
Dave Aditya 16:34
Yeah, it's almost becoming a service in and of itself. And the best people to do it at this point are, you know, like the accounting firms we listed. And if I can dive a little more into why we chose to go down the route of focusing on developers, because I think like you guys, we believe that the best person to build a bot is a software engineer and not the CPA or not the, you know, back office worker who has a good business understanding, but doesn't quite have that there's only so much you can do in a drag and drop interface, right? There's only so many buttons and widgets you can put in there. And at some point, it becomes even more complex, the more widgets you have. So we figured the approach we would take is like the process try per plateau, because like, hey, let's bet on the fact that the people building the bots, would be developers, and they would be the most efficient at building bots, I understand. They don't have the business knowledge or the business document. But that piece can be translated. And the biggest cost is decoding cost. So if we can provide the most efficient coding platform for developers to build bots on, that's where we're eliminating the chunk of the cost to give you some, some numbers to back that up is like our bot implementations ranging from as low as $2,000, to, you know, sometimes as high as 25. But on the average, we're kind of sitting around the five to seven k mark. And that's why the mid market penetration is feasible for us.
Brent Sanders 17:56
One, one, depending on the platform, you're on, you know, another huge fee, depending on again, the size, your organization, and your license is the license cost. And so I'm wondering, you know, how do you guys navigate that? I mean, because one approach we've heard we had, we've had on twice and Antti from Robo Corp. And, you know, they've been trying to take an approach where the license fees are, you know, significantly lower in the licenses, are you really paying for like, worker minutes? And I always say it's similar to Heroku. But, you know, I'm curious, where do you guys fit in terms of licensing? How does that fit into your model?
Jackson Ostler 18:37
Licensing is part of our pricing model. So on, like Dave described, there's an upfront cost for implementation, which right now on average per customer is $7,000. And then our licensing fee, we list all of our prices on our website, we've definitely gone through an evolution to arrive where we are today, as most startups do when it comes to pricing. But essentially, we structure our licensing costs around the complexity of the bot, the number of processes that it's doing, and the business size, meaning the end user, the end user, their company. Are they a small business medium, or are they enterprise?
Brent Sanders 19:21
That's great. Yeah, I mean, so when you look at a, let's say, you know, someone brings you a project, I'll just call it a project is probably a better term for but there's an automation or suite of automations. You're mostly working with a partner do you look at? Like, I know, a lot of consultants, they'll actually look at the process that's being run as an opportunity to like, Hey, does it make sense to rethink this a little bit in order to kind of encapsulate or get it ready for RPA or automation like a digital automation, versus like, this is just what john and account Does and we just need the computer to do that as a how much re-imagining? Do you guys take on? Or does that happen upstream?
Jackson Ostler 20:08
Yeah, no, that happens as we're scoping out the bot with the end customer. And from my perspective, we are able to cut out some of the fat or the waste that is happening manually. And then when the bot is built it is the process becomes much more streamlined.
Dave Aditya 20:24
Yeah, and some of the fat is mostly because the process the way they're currently doing it, they don't know any better. What I mean by that is, the only way you could manually execute that process is by going through, you know, a set of 20 steps. But when you get a bot involved, a lot of the computation can be done dynamically, there's a lot of lookups and references that can be eliminated. So some of it is just a factor of transitioning from a manual to a robot doing it. And some of it is a factor of industry expertise, right. And that's where our partners come in, is like, if you have a specific industry and a specific process, you know, our partners would have seen, you know, hundreds of thousands of those cases, and now they know the best practices, and they can imbue that into the process as that translation is happening. And so that key step from translating the business process into the technical requirements. That's where this new, I guess, improvement can be inserted.
Brent Sanders 21:21
That's great. That's really interesting. So moving down the line to you've implemented about in automations, working and running? Do you guys typically manage that? Or is that something where, you know, there's you hand it back to a company's IT department? How do you navigate sort of that post launch phase,
Jackson Ostler 21:40
We manage the maintenance of the platform, maintenance of the bot and any ongoing questions that would arise, as the customer uses that bot on a daily basis. And, and that is all baked into kind of the customer service model that we currently have today is baked into our pricing. So on average, our customers pay us, I think the average right now is about 700 a month for the licensing. And then like I just mentioned, all customer service and ongoing maintenance is baked into that number.
Brent Sanders 22:09
Great, great. So it seems like a really low risk. And, you know, I should mention, we spoke with a gentleman who, who, you know, runs a very large automation program on Europe. And it was a similar model where he, you know, they sort of had a company similar to yours, I and in fact, I think they were on UiPath. But still it was similar in the sense that, you know, the risk was external to their company, because if you think about, you know, all these different parts of their business, managing the creation of bots, and then handing it to a central. I mean, this is a sort of Center of Excellence problem that people are talking about building internally. And it's, there's a ton of work that goes into it. So it the business case for Hey, can we just outsource this, can we just have someone else manage the bot on a per bought basis. And if the savings are there, then it's kind of a no brainer. So it seems like a really good place to play. If you're going to be doing, you know, any sort of, as a company a great place to to look at if you're going to be doing any sort of automation and you're worried about Okay, how are we going to support this from an IT perspective?
Jackson Ostler 23:18
Yeah, speaking about support, we have seen like the way that our platform enables a developer to build a bot is so streamlined and effective, that we have customers that we signed up in early 2019. That never call never email the bot runs in works exactly like it was architected and engineered to work. And so we hang our hat on the fact that when we push an implementation live and go through a week or two of testing, this thing's going to work and it's going to run.
Dave Aditya 23:49
Yeah, this is what we discovered over time was this is an uncommon thing in the industry. Usually bots are very brittle, and fragile. And the reason that is the case on from a technology standpoint is because we're dealing with UI, right? So anytime some web page changes their, you know, button on their page, or anytime there's a forum update, or the software updates or whatever, sometimes even the process changes, leading to some sort of breakage. We discovered by building the platform for a developer centric approach, we don't necessarily have to depend on the UI elements as much. What I mean by that is on when we're building the bot, one of our secret source is we take in the HTML tags of the UI elements on a browser, for example, right? And so those tags typically are unlikely to change. What's likely to change is the position on the browser, the location of different, you know, screen elements, but the ID for the unique identifier of that element is very, you know, it's very low, probably that will change.
Mark Percival 24:51
And so it's not, it's not because of hyper intelligent AI.
Jackson Ostler 24:57
No, we're not embedding Some secret AI. Yeah, that's it.
Mark Percival 25:02
don't understand at all. It's all self healing AI today.
Dave Aditya 25:06
Yeah. Yeah, there's not some magic thing happening there. It's somewhat simplistic, but yet beautiful. So the reason Jackson brought it up is because we didn't know that, you know, the brittleness of the bot is a factor in the, in the buying decision of the customer. And we've almost I wouldn't say we have eliminated it, but we brought it down to such low probability that we have the confidence to say, we know we can bake in our maintenance cost into the license, because we know it's going to be so unlikely for it to break. And now it does break every now and then. And sometimes the breakage is often driven by the change of customers process or systems. And at that point, you know, it's very easy conversation to have saying, Hey, you know what, you change this thing. And then we've also made it easier for them to automatically update the bottom when those changes happen to be provided a portal to them. And in that portal, they can add new rules modify existing rules. So on the customer success side, we take a lot of pride in the fact that we build bots for success, and we make sure they don't break. And we're in it for the long run with them. So we don't just kind of ship it out and be done with it.
Jackson Ostler 26:12
And that's an important point I want to double down on. It might sound scary to an end customer who is not a software developer that, you know, we are a platform for engineers to build robots. But the interface that we offer the end user, which 90% of the time isn't accountant, is very intuitive and easy to like Dave said, add rules, alter the bot in alter the bots, business requirements that doesn't require them to pick up the phone and call a software engineer who knows JavaScript.
Dave Aditya 26:44
Yeah, that's great.
Brent Sanders 26:47
Let's talk more about breakage. I mean, cuz that's a thing that everybody runs into in the RPA. Space mean, things, as you mentioned, inherently are brittle. You know, regardless of platform you're working against, you know, at least one third party, right or another system. And sometimes you're working against multiple systems. I'm curious, like, any tips that you have for our listeners around, whether they're on your platform or otherwise, around, you know, making a process more bulletproof or planning. I mean, I know, you know, one thing that you hear about is having a business continuity plan, right is in the event that for some reason, you can't get this automation back up and running. And it's critical, you know, you can fall back to some piece of paper that says, Okay, this is how you have to do it manually. So I'm curious what your thoughts are around, you know, how do you protect yourself, you know, again, whether even if you're using, you're already on another platform, any any tips or thoughts you guys have?
Dave Aditya 27:46
Yeah, no, that's a, that's a good point to bring up. So essentially, the way we kind of do the blueprinting of the process is, say, map out the pieces in the that are fungible, what I mean by that is, if there's a logic involved in the processing, look up the invoice number in this location, or find the corresponding GL code for this account, those things can evolve and change over time. So put them in one bucket, and then put the things that are going to be steadfast and very, very unlikely to change into a different bucket. And then when you connect the two, the way you want to architect the bot is to say, these things that are going to change or possibly likely going to change often, let's make that into some sort of a database structure or database table where the user, the business user has the ability to go and update and modify things easily. Even if it's just an Excel file, right? If they can just go and update the mapping logic in an Excel file, and the bot is now referencing the Excel file, you've kind of abstracted away the point of failure into something that can be updated easily. So I think with that, he says you can effectively not eliminate but minimize a lot of potential breakage.
Mark Percival 29:01
Yeah, no, that's a great, great point, a great piece of feedback. You know, when you look at running a suite of automation, so in your case, you use have a multitude of clients multitude of automations. You know, if you were let's say you were a company that were doing this internally at your organization, any tips that you might have for developers that, you know, I guess I should rephrase, you know, we spoke with a gentleman that has a pretty large suite, they run the city of Copenhagen's automation platform and one activity that they were doing is re basically re integrating all of their reusing all their internal libraries. So for example, if they wrote a bot on day one, their very first automation, the latest bot that they're that shipped yesterday in the let's say, three years in advance, they're sharing that same code and ensuring that the legacy bots are staying up to date. I mean, we found that to be a really interesting way to kind of manage but as you guys have this platform, you're running all these automations. Any tips for? How do you keep all of your automations sort of in good health?
Jackson Ostler 30:12
This is gonna sound very essential and basic, but I am going to say it, it's important that when the bot is being built, the person building the bot needs to have if they're not already the end user, they need to speak to the end user and have in depth conversations with the person currently doing the manual process, and talk through edge cases and explore really the nuances of how the process is currently done manually. So then when the bot is being built, the builder has an idea and a deep relationship with that process.
Dave Aditya 30:48
Yeah, understanding the scenarios and possibilities of what can happen in the future when the bot is running. And, you know, there's not a human to encounter this, you know, this new situation, I think it's critical. And on top of that, you want to develop bots in a way it this is it this is a long standing software engineering principle, right, in a way that it's reverse. I guess what I mean by that is it works to the future state, even though things are changing and evolving over time. So on our platform, the way we handle it is, every time we make an update to the platform, obviously, the update has to go to all the testing phases, varying to make sure that it's not breaking an existing bot. And the other thing we try to do is we try to abstract away each bot into its own ecosystem of frameworks that it's working on. So that even if you know your platform has evolved to a next level of next generation, the old generation of bots are running like nothing has changed. I mean, that's kind of the best advice I can give in terms of developing these bots is if you pick a system or pick a state of machine, just try to on the software engineers side, people use Docker quite a bit, which which helps a lot containerize The, the environment in which the bot is running, so that as long as the environment stays the same, the bots gonna keep working the same way.
Jackson Ostler 32:10
And the mistake we made in our early days was after we had a bot go live with the customer, we assumed that it would just work right out of the gate. And we did not emphasize testing as much as we do today. And so I think it's very important that when a bot is, quote, unquote, done, there is going to be a week or two weeks of testing edge cases running the process hand in hand with the builder and the end user and making sure that this thing works.
Dave Aditya 32:36
Yeah, we almost enforced testing as part of our contract. Now we have a language in our contract that states that after the bot is delivered, we would require the customer or the end user to go to a week or 10 days of testing period with us alongside of some training to handle you know, the outliers or the exceptions.
Brent Sanders 32:55
I think we hear this on a lot. We hear this on a lot of occasions where you know, there's just a different set of expectations around going live in RPA. Just because it's so hard to have sort of environmental parody and so many other like web and you know, other types of development, you can just spin up another system have another database, and you have an exact replica of your environment. I mean, so once in RPA, you realize that really, it's it can be impossible to have that parody, and therefore you're somewhat guessing when you're going live. And I think setting that expectation is great. I mean, I think some people, they call it hypercare, we're going to be in the hypercare stage for a month. And that's from live to about 30 days after or two weeks, whatever it is. And it just doesn't seem like a unique aspect of the industry. It's it's you just have to have that expectation in mind have to communicate, like, Hey, this is gonna work. But then we're gonna run across all the exceptions, because we weren't exposed to them in those testing phases.
Dave Aditya 33:57
Because on the development side, it's impossible to recreate the environment, exactly what it's going to look like on the client side, right for for multitudes of reason, we can try to do a lot of encapsulation and Docker, we can try to create the same, you know, state of the machines and the same versions of the software applications being used, but it's just not feasible to do it. And so that's that's the reason why this industry is somewhat different. Because you cannot recreate situation which the live production bot is running. While you're testing developing it.
Jackson Ostler 34:26
When you're building a website or when you're building a project management software. There are no edge cases or scenarios that could ever exist that would break your software. I mean, maybe there are a few but in the world of robotic process automation, there are so many things that can happen in the wild west that, like Dave said, are not anticipated in the development environment. And so it is back to the concept of you know, building bots that are resilient in that last it's so important that the builders have the bot, and the platform that they're building them on, have thought through and considered, you know what the real world is going to be. And moreover, the concept of robotic Process Automation has really transformed recently into an idea of a digital worker, like we're building. We're writing code and building a bot that replaces a process done manually by a human being. And that is a difficult mountain to climb.
Brent Sanders 35:31
Sure, sure. I mean, ideally, it's small pieces that you're chipping away cuz that, uh, and obviously, it should be stuff that not a good use of a person's time, right? I mean, but one of the things that I kind of come back to it was curious how you guys are thinking about it is, how do you guys think about reporting? Because I think, you know, you mentioned, you know, working with Deloitte and I think of all the consultants that I know, that have, you know, either lead an implementation or refer to an implementation of automation or doing digital transformation. A big piece is, is understanding how is that bot doing? What are the KPIs? I mean, how, how are you thinking about reporting back your savings long term? And how do you guys think about delivering insight back to the business once an automation is in flight?
Dave Aditya 36:25
Yeah. To be honest, we haven't done a lot of ongoing reporting on Dubai, right? We've done some health stats and stuff like that, usually, the ROI calculation or the metrics that determine whether or not a bot even needs to be built, just happen up front. And we say, Okay, here's the person, XYZ hours are being spent on you know, doing this process, and how, you know, upon automation, what is it freed them up to do, and then usually, it's the end client kind of determine the ROI. And after that, there's not much ongoing reporting on the time savings, per se, but there's a lot of logging and, you know, external communication done to the client in the sense of like, Hey, you know, the bots spent four hours and 15 minutes doing the reconciliation process you gave us, or out of the 10,000 transactions for today, you know, 9647 were done by the bots, the remaining were done by the humans, you know, so that kind of reporting kind of helps as a constant reminder of the customer, why they're doing the bot in the first place. And the other piece that we found that, that we didn't expect at the beginning was a big, a big factor that influences the choice to go and automate something, especially because we're focused on the accounting and finance side, is to just just make the employee happier, right? So if this person, if this accountant is sitting in front of the screen and doing four hours of reconciliation, just kind of looking at two different numbers and making sure they match up, that is a very mundane, boring, and mind numbing job. And nobody wants to do it, even if they're getting paid to do it. Right. So the person who gets freed up from that task now just has a higher happiness quotient and higher, you know, value to the company because they're feeling more motivated and whatever else they're working on, because it's not as adult.
Brent Sanders 38:15
And yeah, I mean, it sounds similar to you know, you pulling Jackson away from dental school. I mean, you could have been staring at teeth.
Jackson Ostler 38:21
Oh, my gosh, yeah, I I think my lucky stars every day that it was 10 days before dental school, I'd already paid my first round to dues school, I'd already been paying rent out in Indiana. My wife and I were 10 days away from getting in the moving truck that we had already paid for. And he calls me up and says, Hey, I got this idea. And I was crazy enough. We were both I think 26 years old at the time, and I said, Alright, man, it was harder convincing my wife but yeah, he definitely.
Mark Percival 38:50
But this could have been you Brent.
Brent Sanders 38:52
Yeah, it could have been me. Yeah. I never I never really had the science background for it, though.
Dave Aditya 38:59
If I think about that, as he named his daughter, Indy, they just have I think is eight months.
Jackson Ostler 39:05
Yeah, a few months old. And my wife chose the name Indy to kind of represent. You know, she A she really likes the name and B it was you know, we're supposed to be living in Indianapolis right now, you know, when right, our daughter was born. And so that's, that's kind of a funny thing.
Brent Sanders 39:22
That's even great.
Jackson Ostler 39:23
Before you change topics, let me go back to kind of bot health or communicating an ROI to the customer. One of our engineers, our very first employee, Zack has been asking us for how many months now, Dave, that we do want to build that internally so that our clients can have more visibility into the health of the bot the ROI that they're getting how many, you know, hours the bot is saving. So that is definitely on our project roadmap.
Brent Sanders 39:55
Good to hear. Yeah, I know the consultants will be happy about that. But uh, You know, Mark, I want to hand it to you. Do you have any?
Mark Percival 40:02
Yeah, I think you guys, you guys have seen a ton of different I mean, obviously, you've worked with a lot of different companies and organizations, one thing we hear about, and obviously, with your organization and with the implementer, as the implementer, you kind of have this, this role of making sure there's bot success. But the other side of this is the organization you're going into, and how they're going to be successful with it. What are kind of the hallmarks of the orgs that you work with? Where you know, from the beginning, like, this is a well run org, that's gonna be really set up for success with RPA? Or the flip side, which is, what are the signs that this is, you know, probably not gonna be that great of an implementation?
Jackson Ostler 40:36
Yeah, that's an interesting question. So first, we know during the sales cycle, what the, how the client is going to be, once the bots are built, and they go live based off their level of detail as we scoped the bots, based on their, you know, even their level of detail to the contract that we send them. So we get a feel for if this organization and the people that we're working with really care about getting results. And we really stress with our sales team, we want to work with people that are authentic, that are good to work with that set proper expectations. Now to the second part of the question, we had some clients early on that we could tell, we're going to be just the end user. You know, how, how needy are they? How much are they going to be picking up the phone and calling us and we did a poor job early on of training our customers something which we definitely remedied. But so early on, when we didn't really train our customers very well. It made for some interesting conversations when they anticipated that the bot had broke, but really, they just didn't know how to use it.
Dave Aditya 41:47
Yeah, and this, this is more of a cultural thing. I think what we noticed was there some customers early on to be signed up, where the end user of the bot had to begrudgingly sign up to use the bot. Now, whether they felt this, you know, diminish their value in the company, whether they felt like this was kind of a threat to their job, whatever the reason might be, it came down from leadership saying, you know, you have to use a bot. And so they were now really against the idea to begin with that over time, they there to a point where they don't want to go back to their manual state of affairs, but at the beginning was kind of a tension that needed to be broken. And so that was more of a cultural thing we learned about, you know, organizations. Now, the key success in the organization will obviously come from the leadership. If the CFO in our case, mostly, it's the CFO that's driving the transformation, has made a good case to the end user of the bot, as to why they need it. It usually works out really well. And if in most cases will receive lately as the end user is now excited, as opposed to being scared about it, because now they're thinking, Okay, this means I can go home at 5pm, I can see my you know, wife and kids, or the month enclosed doesn't have to, you know, be done at 1am in the morning is going to be done by a robot, I just need to oversee things. So once they kind of capture that imagination of what their life is going to look like post the bot implementation, they become the biggest advocates.
Jackson Ostler 43:15
We've also seen a differentiation of clients those on day one who already you know, are familiar with the concept of digital transformation, and they want to drive that in their organization. Those clients are a breeze to work with, because our goals are aligned, the clients who we meet that we introduce the concept of RPA. To them, we introduce the concept of kind of a take your business from 1900. It's now 2020. Let's you know, let's stop doing things with pen and paper. There's definitely an evolution that happens during the sales cycle and the bot building where we are sometimes persuading them, this is the best thing for your business, because you're saving XYZ your employees are happier. So we've definitely seen both.
Brent Sanders 43:59
That's great. Yeah, that's good to hear. You know, I just want to be mindful of the time. We're just about out. I would love to leave it to you guys, if you want to leave our audience with any final thoughts or anything that you guys are thinking about.
Jackson Ostler 44:15
RPA is something that if you look at the big players who pioneered the industry, you know, they've been around for a decade, but it really in 2015 or 16 started to pick up speed, but it is my opinion that we are still RPA is still in its infancy.
Dave Aditya 44:36
Yeah, we have taken a huge bet both not on our personal lives, but also on the future of the industry, that it is an inevitable transformation. Now it started with the enterprise companies, but it's going to be, you know, exploding in the mid market companies and we really hope to make it happen ourselves. Because this is one of those things just kind of like the invention of bicycle you know major transport it easier than it became a computer. Now you're not, you know, making records and pen and paper, this is an almost an inevitable transformation in how the work is going to be done in any organization. Most of the manual, repetitive mundane tasks are going to get automated, whether you want to call it RPA or not, that's just going to happen. And when that happens, the companies that do get ahead of the curve will see a huge advantage on the cost and the efficiencies in the back end. And they'll have you know, they'll have some competitive edge in the marketplace.
Jackson Ostler 45:31
And the last thought that we would want to leave you with is that it's fun. And it's awesome. And in building our own platform, we had to spin up our own Center of Excellence, I learned that term, just even recently, maybe 10 months ago, that that's what it's called. But we built and continue to add software engineers, project managers, customer success, sales people to our organization. And really, at the end of the day, business is and someone's job should fulfill them. And that is our mission here at planet data to create a company in a culture that is fulfilling and satisfying. And we provide meaningful work for people at planet data. And by the way, we are hiring for almost every position. But second, we want our end users, our customers to have more meaning after they use a bot. We want them to be more fulfilled and happy and Dave has stressed this, even to me from day one, we want to raise the happiness quotient of everyone that is with.
Brent Sanders 46:34
That's a good metric. I really like that. Wonderful. Thank you guys for coming to the podcast and talking to us about planet data and your stories. It's been great to hear so thanks very much.
Jackson Ostler 46:45
Thank you for having us on your formulated automation podcast.
