On this episode of the podcast we speak with Sagi Eliyahu the CEO of Tonkean.
Interview with Sagi Eliyahu from Tonkean
SPEAKERS
Mark Percival, Brent Sanders, Sagi Eliyahu
Brent Sanders 00:06
So today we have Sagi Eliyahu, with us from Tonkean the CEO of Tonkean. Sagi, why don't you just kind of give us a brief rundown of your background? What got you into automation? What got you into this space?
Sagi Eliyahu 00:18
Yeah, Hey, man, thank you for having me. It's a pleasure to be here. Yeah, I started Tonkean probably like, five years ago now. And before Tonkean, and I was with a public company, I was VP Engineering, I joined them from an acquisition they made. So I had the opportunity to grow a team there from about, you know, a handful of people to over 150 people. So got, you know, got the first year of scaling operations, scaling a team, being part of the executive staff of our public company, a lot of insights into how the company works. But also on the other side of it. I, you know, software guy, I've been writing code since I was 10 years old, and had experience both in startups in public companies, but also, in the army, I spent four years in the intelligence unit in the Israeli army in Israel is where I'm originally from. So I had a lot of experience in both software, and in managing teams and I felt, especially as the team grows in the MD in my department group, that we actually are misusing software, when it comes to work. That's how I felt. And we're not actually leveraging it to its full potential. So. So that's a big enough problem to try. And, you know, go tackle.
Brent Sanders 01:47
Yeah, yeah. So can you expand on that, like, what were you seeing? You know, the sort of human computer interaction? Where did you see that going wrong?
Sagi Eliyahu 01:57
So the funny part is that, if you think about how we use software today, in enterprise, or, you know, what they what they call digital transformation, right, this was really bringing things we used to do on paper, writing on documents, spreadsheets, and just bringing them into the digital world, if you will, right. So most of our, if not all of the enterprise applications that we use our applications of writing and reading information into a database, I always laugh that there is zero difference between a CRM and a task management tool, where they're like, they're just writing data into a database and, and have UI on top of it. And so when I, you know, with that in mind, your thing, just focus on what's, you know, what's the big deal, if we have a department, in my case, it was engineering, that needs to work with sales, on big accounts, you know, just connect data, and it will be fine. You know, I just passed the data along, and it didn't work, it didn't solve the problem connecting the CRM, for example, with the task manager system, because a lot of the work was still be, you know, was done in sync meetings every week, and emails, and that my team spent 30% working with the salespeople, but it was nowhere this this walk as if, you know, as if I had zero presentation in the digital world. And so that kind of struck me with sort of the first understanding, which is, business processes are actually both people. They're not about data. And software is about data, and not enough about people. And so that to me, meant we are missing an opportunity on how software can work better for us. And why I mean by that is, you know, coordinating people and working across different processes, orchestrate, orchestrating, you know, a process end to end, and moving away from the limitation of data and more to how work is actually being done by people and designing for that. So hopefully, that makes a little bit more sense.
Brent Sanders 04:22
Yeah, I mean, that's something that we've been having a lot of conversations with leaders in space. And that tends to be the higher level sort of abstraction that is more important to talk about it, which is the people which makes up most businesses, you generally have people I mean, not. If you look at if you were to start a business right now, knowing what you know about automation, you know, you would probably organize it in a way where you leverage technology in a way to augment people to be sort of a force multiplier. But that tends to be the topic when you really think about technology that technology is not a catalyst, it's the, you know, the process of the people and how they work together. So that's great to hear that sort of echoed in what you're talking about. So maybe you could tell us a little bit more about your platform like, what was the, the genesis of it? How did you get it started? It sounds like you've been working on it for five years. Like, how did that get started?
Sagi Eliyahu 05:22
So, you know, when, when had this realization that, you know, people are the center of business processes versus data, right? The second follow up realization was, how do I solve this? Right? How can I, you know, I can I can write code I can, I have 120, or at that point over 200 people under me that can write code, right, maybe we can, maybe we can hack something together and make it work better. And so we tried, we try to hack things around, we try to, we build internal tools. And I realized that that sort of led me to the second realization, which is that business processes are extremely personal and unique. And which is, is, is a high level way to say that, you know, if both detect two companies that have the same five different tools, and both of them are selling to, you know, b2b, they're still gonna have a very different manifestation of common processes, right. So the way they implement product, or they handoff between sales and customer success, or whatever it is, so all of those internal processes, that have a name that you can recognize, the way that they actually manifest within the different companies is actually very unique. And so when, when that came to mind, I realized that maybe the biggest opportunity here is not only to allow software to be used to, you know, automate, or, like you said, embed and empower more people to do their their job better, but actually allowing a bit bigger segment of individuals to be able to build and create that type of software. So that's kind of where we realized it's not about automation, it's about the ability to create solutions, with no code to orchestrate operations. So Tonkin is basically what we call the operating system for business operations. And in a more practical way, it's a no code platform that allows operation teams to create solutions that are custom to their processes, to automate the exact mix you talked about of people, processes, and systems. The important point, though, is enabling and empowering folks that are in the business unit that are the operations team, sales ops, legal Ops, finance, Ops, HR Ops, and so on, to actually own the business logic and own their process and create those type of software solutions that are not necessarily an application. They're not necessarily bringing to life, yet another, you know, user interface that you need to teach everyone. They're not necessarily just connecting data around. But they're actually establishing an end to end workflow that can interact with different systems, can interact with people can provide, can handle information, but can also chase after information, and are allowed to sort of automate and create efficiency within a process without forcing change on everyone that is involved. So long story short, making the pie of who can leverage technology within the company making that pie bigger, enabling more people to actually leverage that capabilities, even if they're not developers, or coders, I felt is an incredibly important point to make the case of changing enterprise software.
Brent Sanders 09:11
Sure, yeah. So it sounds like, as we ask each of our guests on this podcast, everybody has to be asked about citizen developers. It sounds like this platform is almost a paradigm shift in the sense that, you know, this isn't about IT departments and finance departments or operations departments working together. It's almost like a self-serve in that it's low code or no code, and that you can basically use your tool to support operations. Is that right?
Sagi Eliyahu 09:44
Yeah, definitely a paradigm shift. I think that the, I think the official definition of citizen developer you know, correct me if I'm wrong is but is that you know, people that are not developers by occupation. You know, can go and develop things. Right. Right. And, you know, I think that concept is, maybe something in the future will happen. But I actually think that there's a much more important step before that, which is not to say, everyone can be everyone they can build or everyone should build, it's more important to say, let's expand on the people that can build with the people that want to build, right. So there is a layer, right now, within organizations, again, this operation team and this just wasn't exist 10 years ago, you know, 10 years ago, you had sales ops, and DevOps. And that was basically it. Today, you have legal ops and finance Ops, and so on, and so on. And, and those individuals are sitting within the business unit, and they understand the process, that's super important. They understand what the business needs, they understand the different tools that they have. And they keep on thinking about how can I improve this? How can I create velocity, and do more? So first of all, it shows you the focus that companies try to put on that right on, on the importance of that type of efficiency gains, growing by efficiency, and not only growing by, you know, headcount, and in more investing in resources, but actually yielding more of existing was. So I think that's super interesting, in general, but then when you think about, what do they actually have in their toolset, it is boils down to you either buy a package, you know, SAS application, that, you know, might, you know, help you do 80% of what you need, and maybe more, maybe less, but when you think about, you know, the fact we talked about horses are super individual, you might end up with four different application to solve your one process, right, because each application is very much built into handling a certain task, or a certain, you know, combination of tasks. While at the same time, the alternative that will allow you the most flexibility in the most sort of tailor made approach is always just, you know, you can always write, you know, build a custom solution, right, build custom code. They don't have that skill set, nor maybe they don't even want to have that skill set of actually, you know, writing code. And so I think that's kind of where the local no code grew so nicely in the last call it three years is where, you know, more companies realizing both on the engineering side that owns the code today. And in the end, let's call it the business side that doesn't know how to code, the potential of what it means if more people can actually build things faster. And I'll just finish with saying that, there's actually a huge difference in my mind between low code and no code, low code is still coding is just less of, you need to build less things from scratch. So it will allow someone that can code to code faster. And that has a lot of value. But it is very different than full, no code, or true no code, which is to say, you don't need to know how to code at all, in order to build things more of like a Lego, you know, composable blocks, sure you can, that you can put together.
Brent Sanders 13:39
Yeah, I would add on that, you know, so both Mark and I come from the software engineering backgrounds, and through my journey with the newer generation of an AI, we use things like web flow is a great example of a, you somewhere skirting the line between low code and no code, you can build a website with, you know, very, and again, I'm going to a simplistic term outside of the realm of automation. But the one thing that strikes me it because we do use, we both Mark and I could build websites, we could write code, the thing that strikes me about what you're saying, and using workflows and example is, you know, putting together something that you've done a million times before, but it's slightly different this time. And also recognizing that every line of code is liability, you know, it's something that needs to be tested. And then as it lives on, you need to make sure that that's something that's going to continue to work. And so as you build something small, that's maybe several 100 lines of code, you have a lot of liability that stacks up so that that's the one thing that strikes me about the product. And about the category in general that seems really positive is as you mentioned, you have somebody who could be running a department running the operations, to get them to put down their process into maybe a digital format and then Have that process run and be supported with some platform, it all sounds great. And the minute you start, as you mentioned, floating the idea of, oh, let's build something custom, the minute you start getting into infrastructure and all the pain points that go along with shipping a product, it will kill a lot of that potential for innovation. So that's, I think that's a part of this space, especially around automation, that that's really interesting. So I definitely, I think I see the vision. And so I, you know, could you walk me through maybe, like a simplistic example of how somebody would use Tonkean?
Sagi Eliyahu 15:36
Absolutely. By the way, I, I like the examples you gave with, with building the website, and maybe a moment on this for a second, because, sure, I think this touches on the potential in my mind of, is a great example of what happened when more people can do things that just used to be, you have to be skilled person or higher skilled person to do that, like building websites. And now you have a lot of, you know, very small shops, very individuals that can start a business by just, you know, creating online, online store, right, or creating up, you know, portfolio website for them for free, sometimes, right, or for like, very, very little effort, or money, but definitely a little effort, and they have the control. So, I just think that sometimes it's really hard to imagine what type of things would actually come from when you abstract. When you add obstruction there. It comes with good things, and challenges as well. But if you build it the right way, and you sort of like, align it with the, with a specific area of value, then I think the impact can be massive. So to your second question, over a specific use case, you know, we can build a lot of things with talking. Because at the end of the day, it's abstract, the ability to, to build, you know, headless processes, so processes that don't have that doesn't need to come with it, this can connect with any data. And it can work across any user interface and multiple data and multiple interfaces. So it can be very powerful, but we focused on the specific business processes, the things that are common to business processes that are human centric. So things like, you know, things that require approvals and things that require coordinating different people and, and working across different data sets, and that possess a different type of processes that are more asynchronous in nature, if you will, that are not as static and repeatable. They're more dynamic. Right? So some of the, you know, more incumbent automation platforms like RPA. And integration platforms are really focusing on the repeatability of data, right. So it's more transactional, and more, you know, moving things from A to B, or, you know, clicking few things on the screen, and everything is more dynamic, either breaks or, or you get, you need to code a lot of coding in order to handle it. Because we enable that sort of human centric, the use cases that we find ourselves the best are the ones that require handoff and human interaction. So a good example can be let's, let's say you have a problem with your contract turnaround time, right? You know, every company has the need to handle contracts, whether it's, you know, to hire people or to close sales deals, right? If it takes too long to handle contracts, let's say for sales, the common way that people used to do that is to go online and search for a contract management system. And if you don't have one, you know, maybe you do need one to handle, you know, your contract data better. But that doesn't actually necessarily mean that it will solve the turnaround time. Because if you bring a new system to, you know, for contracts, and you put a new UI on it, and maybe there's like a legal portal or something. Well, a lot of companies found that no one is using it, or not enough people are using it right? Because the salespeople will have a different sort of like what I call personal ROI, into that process. And for them to now remember or go to a new interface just to ask for an NDA makes no sense so that they'll continue to do what they always do, which is emailing legal@company.com, right and ask Hey, Can I get an NDA for, you know, for this prospect, or if we signed an NDA with this account in the past, and so on. So, you know, that's a great example of misusing technology for my mind is that, you know, we're, the legal team spends a lot of money and effort into bringing that contract when a system but they just move the bottleneck from one place to another. That's kind of where Tonkin comes in and can really transform the operation team. The platform allows them to easily create what we call modules, that basically a module that would listen to the legal at company comm email inbox, plus the legal portal that they maybe have, plus, maybe directly the CRM, and, you know, waiting for certain stage that the deal is in, and then can then orchestrate the business logic the day that makes sense for them. So if it's coming from an inbox, automatically identifying that this is an NDA request, and then if it's an NDA request, maybe just reply back and say, Oh, you can find the NDA here, we'll maybe automatically check within the CRM, whether we have an NDA, and if not automatically generated using the contract management system, right? And then bring it up. But more importantly, if we don't know if we're not sure, then escalating it to the legal team, and ask the legal team, maybe email them, maybe slack them, maybe Microsoft team, maybe even an SMS, and ask them, Hey, is that okay? Or not? Or, you know, what should I do with this? And as they reply, talking, we then continue the process, as if people were just part of that process, and part of that automation, versus breaking that and everything I just told you, is actually just drag and drop those composable components that the operation teams can build themselves, and own the maintenance of a tool, which is, you know, what you mentioned earlier, like, own the, and change that logic, and improve it as as, as the process improves, and adapt. So that's just a small example. And you can imagine there's endless amounts of processes in the organization that are human centric, and are really hard to otherwise automate, because it will require a lot of specific coding in order to sort of like, wire all of this together, in a sense, in a way that makes sense. And, and that's why the potential of this is, in divided customers already seeing it is huge.
Brent Sanders 22:41
Yeah, I think the interesting part of what you just said is pretty much the opposite of what we hear from a lot of the incumbent RPA platforms, which is step one, identify a process step two, identify if we can change the process or optimize it to fit into automation, right. And so what I'm hearing, the main difference is that, in the business processes, just let things happen the way that they're happening. And some would argue that, and I'm not saying this in a bad way, but the reality is, is that most businesses are sloppy, right? It's like it's a messy business, we make it work the best way we can, and, you know, looking at a salesperson that doesn't, they don't really care, if you change the process, they're gonna do it the way they need to do it, because they are, they're focused on closing the deal, or their priorities are elsewhere. So I think that is a very interesting way of going about it, where it's like, hey, let's just accept how these things are happening. And then build a tech almost around like, around that. And we know it's gonna happen in a human centric way. So human centric, is an interesting differentiator. I mean, so that's, that's really, that's really cool.
Sagi Eliyahu 23:52
Yeah, and that's exactly right. You know, I'm not saying you should keep a bet process, right. But I am saying that humans are the, arguably the most adaptive creatures that exist, right? Like we can adapt to anything. And so for me, if something works, obviously, something is probably broken along the way, if you want if you're trying to fix it, but it doesn't mean that everything is broken, right. Whereas you look at the process or as you look at an area that you want to make it better and use technology for it. The everything that you have today is some form of rip and replace some form of you either need to change it to fit to automation, or you need to change. If you bring in your SaaS application, then you need to force people to change their behavior and use that obligation. It's a form of that me in order to improve is you know this one, or like this, like I say, 10% 20% of the process. I need to redo the entire process in some way or in one out and and what we are saying is basically, there's a Darwinistic way of doing things, if you will, people find the way to it will best fit their personal ROI and the things that they're in charge of. And we shouldn't disregard that. And instead, we should. This is a concept we came up with, which is a people first process design, we should understand, what are people do that? And how are they doing things today? And do we not like that, because that it's not optimized for what they should do? Or maybe we don't like it because it doesn't fit. The other things that we're trying to do, because of the other things, limitations, right. And we're talking, we're basically providing the toolset to create a bridge, and to create that sort of, like extra layer of orchestration.
Brent Sanders 26:00
Yeah, that's a really interesting way of going about this, that I think differentiates from a lot of the, you know, again, this is a platform that I wouldn't say is, you know, it's it's not a, use our platform and write your own bots, it's more so it sounds like, you almost want to represent a business process and, you know, support it in a way. So, with that, like, I always think, kind of changing the topic a little bit. But, you know, I always think of automation RPA as the whole category in a way to start to incorporate artificial intelligence machine learning into the business process, right, it's like, it's a great gateway to start to leverage those tools. And there's a lot of competition around this, there's a lot of companies that feel the pressure to be able to, you know, compete with one another. And on that playing field of, hey, we're, you know, we're leveraging machine learning. And it's, it's hard to say, for a lot of companies like what does that actually mean? And how does that play out? And what advantage does that actually give you? So on that note, you know, is there a way that you think about that category of automation in incorporating sort of smarter technologies into the platform?
Sagi Eliyahu 27:19
Absolutely, I think, I think smarter. You know, I like that, you know, people said the word at the end there to smarter technology. And I think AI or machine learning is a lot of time for, like, nice to use. Right. And, and like, just being used as a broader way to say, Oh, you know, this is, this is smarter. I definitely think that there's a growing need into smart technology. Like, I think that is very true. But I think there's two places where this manifests. One is in the ability to perform, quote, harder tasks, right. So tasks that, you know, are just harder or sometimes impossible to do with before the, you know, machine learning algorithms and so on, whether it be OCR or NLP and so on. And so, you know, when you when you think about those actions, then what we found, I think, and what was with the market start to see is that if you can't actually put those technologies to use under it, or as part of, you know, an actual business workflow, then they, they stay where they are, which is just a state machine that, you know, you need to the station that you need to go and use manual anyway. So it's almost like, just having a model that can do things for you, is useless unless you can actually leverage it into real business scenarios, right. And so I think, absolutely, automation is an enabler for that. Because if you move things from being fully manual, and you started taking some parts of it into a more streamlined version of that process, then you can incorporate some of those tasks in a more streamlined fashion. But I would say that the biggest opportunity in my mind is actually not on the task level. I think the biggest opportunities actually, on the process level. So a lot of times the way we know, I like to talk about what we do in an assembly line comparison, so you can think about the enterprise today's as a factory floor before an assembly line, right. You had different tations of work, some of them, you know, just a table with people around it doing things manually, some of them fancy machines that you bought. And you can improve the machines over time. And, you know, a fancy AI model would basically be a machine at that point in, in one of those stations. When the assembly line was introduced, it didn't just change the way you do the tasks, it changed the way you operate as a whole, right. And it basically allows you to create efficiency and leverage technology, not only on the stations, but also streamline the entire end to end process and allow you to improve it over time, and create better handoffs between the two. So now, when you start to switch machines, and improve the way, you know, people do their job to the impact on the entire process is much more fluid and immediate. So for me, the first of all, that's kind of how we see ourselves, right is enabling sort of operations to create that assembly line. But second, we use smart technology that you mentioned, and even machine learning within our own way of handling that process, especially on fine handling exceptions and anomalies, and handling and chasing people, right? Because it's one thing to say that I connect, I connect different stations of work that some of them are human, some of them are machines, but if the human is the one that needs to actually do the transition, then it's not really automating anything, right? It's just what the person needs to do it. So handling that type of work, coordinating people, is actually something that in a smart way, that it's not annoying, that it's not just something that keeps bugging you forever. Is, is something that we found a lot of success with, involving smarter technology, if you will. And and and I find that incredibly inspiring of, you know, what happened when people can actually focus better, right, and that's, to me is the biggest opportunity with a eyes is to really be able to empower us to focus better on the thing on the skill set that that we as people has, that are very different than what it means to for a machine to complete a task.
Brent Sanders 32:35
Yeah, that's interesting. I mean, I think a lot of the aims of automation is, you know, broadly is like, let us let us focus on the things humans are good at let, let the machines work on the things that the machines are best at, and kind of land in between there in terms of, you know, what we spend our time doing, and I think it's funny, I talk about this a lot on the podcast, but in our own sort of consulting practice, we, we started out, you know, looking at automation opportunities, we come into a company and we'll say, you know, what, what is typically this person do? And then how much time do they spend on the tasks? And what are they paid? And oh, you know, you can say this headcount is sort of this traditional way of looking at automation, which is quite backwards, right? It's not actually how, when it comes to us working on something or delivering an automation, it ends up, not really not that it doesn't save anything, but it's like you actually are enabling something, or an environment that otherwise wouldn't have been possible. And so we talk about this a lot where it's, like, with automation, we wouldn't have even done a certain thing or gone down a certain path or been able to perform certain tasks, we would have just just skipped them or done something differently, done something manually, and the alternative, like, for example, for downloading 10,000 emails a day and, you know, going through them and finding something and then forwarding it on, like, it just wouldn't, we wouldn't have hired all those people to do it. We just said, Hey, this isn't feasible. There's no way to even do it. So it's kind of one of those ways of looking at automation of like, beforehand, like before you introduce either a platform like tonkean, or, you know, if you were going to do a custom automation, otherwise, like an RPA platform, in general, like, it's hard to know the value you're going to get out of it in the beginning, sometimes. And so, I guess, like when you look at companies that might be either a good fit, or you're, you know, in the initial stages of working with somebody, like how do you explain the value? How do you? I don't want to say, you know, how do you sell somebody on the platform, but, you know, how do you look at understanding if your platform is going to deliver ROI, or if it's going to be a good fit for somebody like what's a good way of qualifying if talking to the right platform for you?
Sagi Eliyahu 34:56
It's a good question. And the interesting thing, parties, you really it comes down to like the alternatives, right? Like, if you don't like, if you don't have Tonkin, what does it mean? Now you, right, have you're super accurate of saying, and when you introduce something new, then that muscle doesn't necessarily exist yet. Right? You know, the most common thing we've hearing from customers is that, as they start with talking within two, three months, all of a sudden, they're, you know, three or four times using for more workflows, like the number of workflows they're using for talking to people within few months. Right. And, and when, when this started to happen, and we were starting to dig in, and sort of repeat itself, people were saying, It's crazy. It's like, I bought this, you know, goggles, where now I can see, like, what about this? What about this, right? So, so you're right, it's harder, you know, when it comes to something completely new. So it comes down to the alternatives. And what we found, which is interesting, is, the most common alternative for stuff you can do with talking is actually custom build it, buy it, or corporate engineering. And so an easy way for us to come into an operation team is basically trying to understand what are some of the projects that are top priority that are either planned for it to build for you guys, or you didn't get budget for my tea, or, you know, party for my children or engineering, right to build. And those would be an easy and easy ROI and easy time to value. Because you can build them relatively fast, and much more within, you know, keep it within the team, right? So right, much less cost of, of maintenance, like 10, x less. So the real interesting part is that every every partner has those projects, and a lot of times, they're actually extremely important, and they would move the needle is just that, if you can buy something out of the box for it, then it's really costly to build, right, so there's a limit to how much you can do. And so, once you all of a sudden introduce that option, they always have like this number one arrogant thing in their mind, that then we can, you know, demo or show how easy it can be done with talking. And then right after that, they come back with five or 10 more, right. So it's really educating the art of possible. And the alternative usually is a project that requires code.
Brent Sanders 37:41
Yeah. And that means, that tends to be a whole other ball of wax, and depending on you know, your, your corporate structure, or I should say, your stage of company, you know, some some companies, that may be an easier conversation than others. But generally, that means stepping outside of your department and requesting time and resources that, you know, a lot of people that we talked to with it, that are trying to start with automation, it's make a really good use case, go to their boss, have a champion, find a sponsor, and then you have to go to it and essentially have somebody, you know, put a put their backlog aside, they and I won't go into all the you know, the rigmarole of what that looks like in a lot of companies, but it for more traditional kind of established businesses, that's, you know, everyone's got their their workloads full, they have a backlog of tasks to do. And it's hard to kind of, you have to persuade and have a champion to, to have them kind of reprioritize to build you something. And then I mean, I'm a big believer in, and I would say, as a software engineer, I was very skeptical of all the sort of low code, no code platforms for a long time and think like, oh, there's no way there. But once you use them, and I would hate to say I keep going back to web flow, because that's what I've used the most. And, as you know, the former spent a lot of time doing web development, understanding, like, Oh, this is what happens when you abstract your code out. And we, as engineers are always trying to do that, right? I want to be able to, you know, abstract this all the way out where I could just plug it into this and plug it into that. And we're finally seeing that and we're seeing that commercialized. So it sounds like you know, and I would admit, I have an option to download it, I signed up for a trial and tonkean I didn't give it as much time as I would like, but I was able to, you know, get some data coming in and just understand kind of how the platform can operate. And it was easy enough for me to spin up and get data and I connected our, our slack as an input. And, you know, I think that's an interesting way going back to, you know, the human centric piece of this is like the reality is most of our our operations are done over slack and email and so like it is It struck me that that was the way, you know, data versus like, you know, I'm sure you can, but I didn't see immediately the option to, like, try to connect our production database or something like, it's like, the reality is a lot of the day to day business can be going on through slack and email. And so anyways, coming back to the point around, you know, build or buy, I mean, it's, it tends to be a no brainer for most companies to, to buy, because especially with a product like tonkean, you can trial it, you can, you know, take it first. And obviously there is investment in building out your own specific operation. But, you know, it does seem like a much more attractive endeavor than building and then forget the, the carrying costs, like you build that platform, and then it's okay, well, what happens 234 years from now, when the creators are no longer around, or there was a misplaced documentation, or a chain of custody that goes wrong, and then somebody new comes into the role and says, Well, what is this thing? And why do we have it?
Sagi Eliyahu 41:01
Yeah, exactly. And I think, to simplify, you know, the previous answer, the projects that you think you cannot buy, and you have to build, those are the parts that we like to tackle first, right? Because those, because then maybe, you know, maybe we can surprise you. So that's a lot of times the way we, you know, we, we like you say we sell, or we sort of explain it to a new prospect, as it had a funny anecdote. One person at a big, very big company said to us that when they asked, you know, top consulting of like, what they need, in what they want to buy, because they don't have the resources to build it. They told them, you're looking for a purple unicorn, that thing doesn't exist. And, you know, needless to say, it's something you can easily build in Tonkin. So I think it's a lot of extending and abstracting away things that are extremely hard to do today. And for some places, they should continue to be hard. But for some other places, there's actually a time for data production to happen.
Brent Sanders 42:12
I should pause as I feel like I'm monopolizing all of those questions, I want to give you an opportunity to ask some questions.
Mark Percival 42:18
The classic child childcare issue on my end this time. Oh, fun. So yeah, I think playing with the actual product, I'd love to hear a bit more about because there's one area that I find fascinating is testing when it comes to automation. And you've got this idea of sort of test and deploy. I'd love to have you walk us through that and how that works. We're talking.
Sagi Eliyahu 42:39
Yeah, absolutely. I think you guys mentioned your software engineers by trading.
Mark Percival 42:46
Yes ...
Sagi Eliyahu 42:50
Exactly. Know, but the importance, you know, I think one thing that a lot of people that are not necessarily software engineers, or those who don't have the experience in it, don't realize that writing software is not only about coding, right? It's also about architecting the solution first, and then understanding the implication, and I think, Brent, you mentioned it earlier, of every line of code you write, right, like, understanding that there's an impact to what you do. And the funny part is, when you think about again, that's kind of where the local, the local is interesting. But when you think about enabling more people, to essentially, you know, build software, one of the most important thing is how do you instill in them best practices, that, you know, if you're a software engineer might take you years of experience to get to, and one of the obvious thing for us was, we have to, you know, if we believe in our product, not solving niche problems, or, you know, or small, what we call toys, we really care about in the way our customers are using us today. Especially by the way we are in healthcare and we have several healthcare customers in from the healthcare and pharmaceutical industry. And you can imagine that this year, with COVID, there was a lot of actually work behind the scenes around coffee that has been handled with talking, which is such an amazing thing for us to see. This is Mission Critical processes. These are not toys. Right? And at the same time you like an entire, you know, picture pitch for the companies. I'm going to enable people that cannot code to build those processes and automation and software. So there's a disconnect, right? How do you how do you allow more people to build software but make sure that this is not personal toys, this is something that can be handling heavy duty work, if they don't have the best prices, so a lot of the work that we do is some somewhat hard to even see Wouldn't you do a quick trial because it really is about that sort of like runtime enterprise level deployment. So we would have things inherent in the product like environments, that across the different parts of the product, there's the concept of build versus test and pre prod, and prod, and so on, obviously, the bigger they count is they can add more of those environments and so on. But really, that concept of you should, you should, you have to test things before you move on. And they're probably different data, stores in input and output that are different between environments, sort of abstracting that part away as well. And then the second, the second is the deployment concept of, you know, if you have one area of the business, that you're that you're improving, and you have, you know, five or 10, different workflows, they're, they're all actually part of the same cohesive business problem. And if you write code, and if you deploy any fad, like 10, different features, they're very different, but they're all helping the same thing, you know, that, you know, you'll deploy that branch together, right, it doesn't make sense to have like a different branch for each, or a different repository for each of those features, because they actually do work together eventually. So you want it to be under the same repository, and so on. So similarly, in Tonkin, we sort of, without the end user even necessarily understand the full aspect of it. We force people to sort of arrange their automation in a way that forces them a best practice of how to deploy and who needs to be involved when you deploy? And what does it mean to make changes to something that runs that already runs in production?
Mark Percival 46:49
Yeah, I mean, makes sense. I mean, that's the one area that I find kind of frightening about RPA, in general, with a lot of the services and the platforms is there isn't this push for best practices, especially around deployment, I mean, I think if you're coming from a software background, deployments are is kind of the scariest piece, right? It's where you're going to where things are going to go horribly wrong, if they're going to go wrong, and it's hard to predict. But at the same time, having some type of, you know, it's almost like you're dogfooding talking in there, right? There's kind of a built in BPM of, you know, looking at the looking at a product with the on the screen for deploy, you can kind of see, hey, there's this idea of somebody made a change that needs to be approved and needs to go through these steps. And we have that in software engineering, it kind of becomes table stakes, if you go into a moderate sized company with a decent software team. But obviously, if you're coming into this new, it's easy to kind of miss those best practices.
Sagi Eliyahu 47:41
Exactly, exactly. In even understand them, right, or under even, you know, new engineers, it's always like the joke. When you hire, you know, fresh out of college, you know, software engineering, it's always like, never testing in prod, right? Yeah. Like, does that sound like obvious things to anyone that spent, you know, a second actually building something real versus like a side project. And, and we tried to distill the instill those off the bat, like, another example is that we have a very clear separation of the data access layer, and the business logic, right? Something that they don't even in the product, don't call it that way. Because it will just confuse the business operation team. But if you think about it, from a software perspective, it's a very basic concept of, you know, separation of responsibilities, and creating reusability. So you know, so you can actually, if there's a problem, you can pinpoint the area in which the problem is in versus, you know, trying to debug for four hours to figure it out.
Mark Percival 48:50
Yeah, it's a, it's interesting, that's just, it's Yeah, it's interesting that that's become sort of the one area of RPA that I think is moving the, you know, slowly in some places quickly, and others that are moving towards these best practices that we've had for years, just they're kind of just we just take them for granted from software. You know, the MVP, not the MVP, the model view controller system models, the abstracting out the data and the logic. It doesn't yet exist in a lot of the automation space yet. So it's nice to see, you know, somebody's thinking about that.
Brent Sanders 49:22
Yeah, I would say I noticed that as an interesting feature, just kind of kicking around with the product was the ability to have sort of things going to production or, you know, changing gears, but it's a really hard step, especially for automation. I know of a lot of people that it really even if the people who I consider, you know, the highest level professionals in automation still struggle with going and changing things to production. So it's, it's hard. I mean, it's just the bottom line when you're working with business objects like this. It's not always easy. to replicate things with data as you guys were talking about, but, you know, with that being said, threat to use it, do you have any things that you wanted to mention anything you'd like to promote? Before we wrap up?
Sagi Eliyahu 50:13
I think I think we've covered a lot. I think the important point for me is the concept of enabling more people to do so we call those makers, right, there's folks that actually has that maker mindset, you know, of building things, but not necessarily have the knowledge and and, and, and experience with building software. So, you know, we're doing a lot of things around that as well. We have a community we started, which is adaptive Ops, operations community, that's the, you know, the URL, but it's basically a community that brings together operations, makers from across, you know, the different departments, you know, we have professionals from, from all walks of enterprise, right, whether it's sales, or legal, or finance, and so on, and bring them together to actually start sharing best practices across you know, it's amazing to me how advanced the community of developers are, with sharing knowledge and sharing best practices and learning from each other. And now, infinite in some areas, is that equivalent is within operations and how significant of an impact changes there can can do. That's going to lead me to that second point we actually did in December. We also sponsored our first what we call the Changemaker hackathon. So Changemaker 2020. And we'll do one this year as well, because it was so successful, what we did there, we basically brought together two sides that usually don't actually interact at all nonprofits on one hand, and specifically nonprofits that has operational challenges that can use help. And then makers across, you know, the spectrum, whether they are software developers, whether they're, you know, just operators in or business operations, folks from ever we had, you know, folks from top tech companies, all the way to like banks and, and others, so, brought them together, and actually for a week, they just work together and into trying to solve help the nonprofit solving their operational challenges, obviously, we, you know, we offered our software for free for that too. But we had other partners, Google Developers partner with us and air table and a couple others, and also, you know, allowing folks to use their tools. And that closing ceremony was, for me, it was just jaw dropping, I was I was amazed by how every nonprofit sort of presented things that the challenges they had, and in the solution that they came up with, and the impact that it had, some was using technology now for the first time in certain ways, some wasn't even related to technologies, literally just best practices of doing some things in operations. And it was an amazing, it's those finishing touches so many different people, and you approve their life, they can do more with it with the dollars they have, which is obviously very important for nonprofits, to impact even more, it was everything from, you know, helping, you know, kids in hard neighborhoods, and, you know, underserved communities and all the way to global initiatives around the world. So for me, that was extremely inspiring. A good sort of reminder of this is not just to kind of get more dollars in efficiency and optimization, it's, it's really about enabling technology to empower things that, you know, we care about. And we can achieve much more thanks to it. And that was always the role of technology, automation. And so for me, enabling more people to be able to build that. That is moving from like a linear improvement to, to really a potential Quantum Leap of, of what it can have the impact that it can make.
Brent Sanders 54:27
Yeah, it's great to see somebody, you know, incorporating the nonprofit sector, specifically and seeing positive outcomes. I feel like automation tends to get it on the surface level of pretty bad rap, you're just kind of automating people out of their jobs. And this is nice to see. Kind of the technology used for specifically good.
Sagi Eliyahu 54:49
Yeah, exactly. It's a complete misconception.
Brent Sanders 54:52
I agree. I agree. Sagi, thank you so much for joining us. I feel like we've covered a lot. We've covered a lot about the The platform so for folks out there, if they wanted to check out the platform, they just head to Tonkean.com. Is that right? Yeah. Yeah. So check out check out the platform and especially if you are, you know, folks that are looking to buy overbilled. I mean, I think as I mentioned that liability of code is a big leap to recover. And again, it's nice to be able to kind of spin something up, try it out, and, you know, almost just get your feet wet with a platform versus, you know, restructuring your entire company to work around automation. So, again, Sagi, thank you so much for joining us.
Sagi Eliyahu 55:36
Thank you guys. That was a pleasure.
