Kevin: 0:01

Frankly, we just asked them, what are things that you really like about your What are things that you absolutely hate and what are the things you're indifferent about? And then I'm going to take that information. I'm going to map it. I'll probably diagram it out, share that diagram with them, have them approve it, and I'll say, hey, based on this, we're going to show you XYZ in the software, and we're really going to try to hammer the things that they like in their old software. Here's how we do it.

Emilia: 0:27

Welcome back to planet Odoo. On this episode, we will look at how Odoo handles the sales and kick off process for our larger companies. Yes, Odoo is for small to medium sized business, but it also can be used by mid-market corporations as well. Businesses larger than 250 users? No problem. Complex business processes also not a problem. So how do I connect and work with Odoo if my company is looking for a new ERP and has many to choose from, and how do I decide if this software is the right fit for us when we have so many departments and moving parts? Well, sales engineer Kevin is here to let us in on the process from beginning to end. You may know him from his popular YouTube channel, which showcases demos and feature videos. The master of Odoo is here today only on Planet Odoo. Hi Kevin and welcome to planet Odoo from the Buffalo Studio.

Kevin: 1:20

Thanks for having me. Happy to be here.

Emilia: 1:23

So it's your first time on the podcast. Are you excited?

Kevin: 1:25

I'm very excited.

Emilia: 1:27

Um, so let's jump in and have you introduce yourself. Obviously. So some people have seen your YouTube channel, um, and customers seem to love it. It's what we hear the most about. Um, but I want to get to know you a little bit more. So tell us about your evolution at Odoo and how you got to Odoo.

Kevin: 1:42

Yeah, for sure. So, um, I joined the team as a BSA originally, so before that I I went to school for computer science at a retail company. Very unrelated, but I have a background in business and technology. Um, when I eventually sold that company, I wanted to do something that was both technology related as well as business related. Honestly, I didn't even know what Odoo was at the time. I didn't know what a BSA was. I just read the job description. I said, I have those skills, why don't I apply? Um, I moved here into Buffalo from New Jersey, something that doesn't typically happen for our environment. But I decided to take the leap of faith and it was a great outcome. I started as a BSA, worked for a few months. I got promoted to a team lead fairly quickly, I would say based on necessity for a team lead, as well as just my past experience that allowed me to excel in the role I did. I was a team lead for about a year and then I became a mid market sales engineer. So that was after time of speaking with our director here and noticing that the mid market team needed another piece of the puzzle just to help them with the product demonstrations and to really dive deeply into the product that is more uniquely suited for someone that comes from a business systems analyst role.

Emilia: 3:03

Okay. And what qualifies a mid market, um, you know, opportunity or company for

Kevin: 3:09

Yeah. So for us it really depends. The easiest cut off would say 250 employees or more. But there are some caveats to that. There are smaller companies that are on a high growth trajectory, where we think it makes sense for them to be introduced to our mid market team or companies that have a fairly complex workflow, heavy developments or integrations that our Quick Start team might not want to work with. And those will come to our mid market team because they're just a little bit more complex and they have a large or a longer sales cycle rather.

Emilia: 3:44

Okay. And so if you qualify as a mid market company, what can you expect as far

Kevin: 3:50

Yeah. So we have teams right. We have one in Buffalo. We have one in all offices. And that's going to be generally a presale team that consists of either a sales engineer or a BSA or a pre-sale BSA rather, which is a business systems analyst. Um, they're going to be very product focused. And then you'll have, of course, your account manager or business analyst that's going to be your sales person, pretty much. And that sales person will be your main point of contact. And then you'll have periodically your sales engineer or pre-sale BSA on the call to help with answering questions and providing a demonstration to the customers.

Emilia: 4:27

So how did the MMC team come about in all of the offices, and when did Odoo

Kevin: 4:34

Yeah, so I think we've always had some sort of MMC team spread across the But the pieces to the puzzle were not just weren't there yet as well, as our product was still maturing to the to the point where we really needed to focus on that mid market. I would say in the last few years, especially since I started here, we were on, uh, version 14 of the software and that's when it really took off. And the software was. Really mature enough to fit these mid-market companies. Sure, there were like one offs here and there where mid-market companies would use Odoo and customize it heavily. But at that point, a few years ago, we started doing MMC in the San Francisco office, and then we started early on in the Buffalo office. When I came into the picture was about a year and a half or two years ago, where we've seen the need for an additional piece of the puzzle that can actually focus on the product and has, you know, a big knowledge base of the project or the product and can really answer those in-depth questions.

Emilia: 5:35

Right. So it is kind of our best people kind of pulled together to work on a would see, or a little more built out, excuse me than you would see for maybe a small to medium sized business, for sure.

Kevin: 5:48

And every larger company, especially let's even say 100 users plus they usually Um, they're not just, you know, running their business from a day to day, but they're looking at data, they're looking at optimizing, you know, their manufacturing process or looking at specific costing for their manufacturing process. And that's not something we're generally going to dive deep in, in the quick start or the direct sales environment we might for a particular customer. But when we have more decision makers in the mix for larger companies, they really want to see a built out plan before they make a decision. And the investment is much bigger for them. So it warrants a longer sales cycle with a bigger team to assist in that sales cycle.

Emilia: 6:31

Okay. And since this is kind of fairly new within the North American market, and count. What do you find are still some of the biggest challenges that your team faces when coming into an MMC project?

Kevin: 6:48

Yeah, there's definitely a lot of challenges. And I think these challenges are not necessarily unique to us, but unique to any mid market company or any company that's trying to target the mid market space. And it's basically basically the things that you would find obvious, right. There's more decision makers, there's a longer sales cycle, more things can go wrong. So when we talk about sales cycle it might take 6 to 12 months to sell a project. And that involves so many people on their end as well as our end. And you know, all these companies have moving parts. So someone might leave that will throw a wrench into the entire cycle of, of the sales process. But beyond that, I think our product is mature enough to handle these companies is just a matter of defining our process and getting people on board and getting them to recognize our brand. So our brand is not the biggest in North America. We're still growing and we're growing rapidly, but people are starting to see our billboards and they're starting to see our brand in their heads more often. We're going to trade shows. We're doing all these things to get that brand recognition. And once people get the name in their head and they see the product, they love it and we have no problem from that point on. It's just a matter of getting them involved in the process and then getting it to the finish line is always hard, no matter what sales process you're running.

Emilia: 8:04

Right, of course, especially with one that is so in-depth. So speaking of the sales process, that's kind of why I brought you in here today. I'm curious about the sales process and about how your team tackles an MMC process in particular. So I'd like to kind of walk through it, um, and go through the many steps so that those who may be interested in the software can kind of understand what they'd be walking into. Um, so initially, I want to know what are the most important things for a company to keep in mind when evaluating a new ERP when they are such a large company and there's so many moving parts?

Kevin: 8:39

Yeah, I'd say the number one thing that people need to, or companies rather need be a long process, is going to be a hard process, and it needs to be very well thought out from both ends. So it's not something and we especially don't do it. We don't just try to sell them the software, like we want to have a plan in place that's going to lead them to a successful implementation, but it really starts with them. They need to have a budget allocated. They need to understand that this is going to be a hard process that involves the entirety of their organization, and the more that people get the feedback from their lowest employees, right? Someone working on the manufacturing floor all the way up to the C-suite, and they really understand the core requirements that go into whatever their next solution is. Then they're going to have a much easier time evaluating the software's going forward. And I think one of the things that they you should really think about is what are. And everyone says this, right? What are your requirements versus your wants. But it's really important at this level because you can get the most complicated idea that you want. But what's practical and what do you want to start with? And how can we approach this problem in this sort of like first principles where I break down the problem? What do we actually want to solve? And then let's solve it. Because just getting a new system for the sake of getting a new system is not a good enough reason to spend the money or evaluate a process to evaluate and and have all these resources allocated to a project.

Emilia: 10:11

Right. It's going to rock everything for a little while. So it must be it must be worth it on both sides to come and to come prepared. Um, how often do companies of this size, um, to your knowledge, kind of switch systems?

Kevin: 10:24

I would say really depends. Um, there's companies I mean, at the mid market size, I would say probably ten plus years. You know, once you're on a system and you have kind of the people in place that know the system, it's really hard to change. So they most of the time there's a process that takes place internally. We have some cases where it's it's started from like one user who's really fed up with their system and wants to evaluate new software. But for the most part, I would say that probably around ten years if I had to guess, because when we were looking at legacy systems, they're still running DOS sometimes, uh, blue screens. And then any time that the tech stack gets too complicated and they start from a small company, you start using all these different softwares and then your 200 users and you realize everything's everywhere all at once. And we need to solve that problem.

Emilia: 11:16

It's not sustainable at that point. It's not. Yeah. Um, okay. Great. So let's jump into the process here. Um, I know a little bit about the sales process when it comes to small to medium sized businesses, because I have had people on the podcast who have kind of talked me through that. Um, so I kind of want to be able to talk about the differences here, um, and get into the nitty gritty. So, um, the pre-sales process. So we would call that, you know, qualification, that initial conversation, um, what are kind of the main takeaways of that? And, um, what do you kind of go into the qualification looking for at this level? Yeah.

Kevin: 11:48

So the qualification stage is mainly handled by our, the sales reps that are Um, sometimes I'm on the call, sometimes I'm not. But generally what we want to get out of them is just the basic sales information and understand the direction that they want to go into. Right. Understand if they have a budget allocated, understand who the decision makers are. If this is something that they already discussed internally or not, are they just evaluating the software and then really understanding the team, I think is extremely important. Who's on the other end of the phone and what kind of resources do they have available? Are they a very technical team, or do they not really have developers on hand that can really help with, you know, are they going to go on prem with our software? They're going to go into the cloud. Do they want to manage that? Do we want to manage that and getting some of those, uh, things out of the way early are actually important because it will tell us how we progress through the cycle. Do we show you a very out of the box, keep the cost, um, as, as, as low as possible in terms of the implementation? Or do we give you all the bells and whistles you're looking for? Because you're very mature in your processes and you understand what you're getting yourself into.

Emilia: 12:55

And then, you know, our implementation methodology is generally to do as much Then kind of like customization and maybe even more minimal developments. Is that still the case at this level?

Kevin: 13:07

I'd say that yes and no. There's two different avenues. And as I was just previously mentioning on the last question, right, there's things that you want to evaluate in that first initial call, as well as the subsequent calls where you kind of get into you get to understand the customer and understand their pain points as well as, you know, where they shine as a as a company and where they might struggle. And you want to kind of push the product in a way where you know it's going to be successful. So for my job, the only thing that, you know, mainly the main thing that I care about is a successful implementation. I don't care about the rest. So if I don't think the project can be successful, I need to steer it in the way it's going to be successful. So if you have a company that doesn't have a lot of technical knowledge, you know, whatever the company type might be, we want to go as out of the box as possible because I know they they're not thinking about the technical debt. They're not thinking about all it's going to cost to maintain the system long terme or all the changes they might need to make. Let's say somebody leaves and they have all of this knowledge about the system in their head, all those custom developments, they're going to be hard to train. But if you just out of the box, you can go look at the documentation, you can YouTube it, you can go on ChatGPT and figure out how the process is supposed to work at any time.

Emilia: 14:19

And you want to make sure that you're telling them up front in the long terme That way, there's no issue in the long tum of them saying like, wow, it works so great. And now suddenly it doesn't, right? If they're looking at a ten year commitment, it is kind of on us to make sure that they are aware of what that commitment looks like.

Kevin: 14:37

Exactly. And I would say the biggest one of the biggest factors for people And that usually comes from technical debt. And I mean, even from going to trade shows and talking with clients, one thing that we realized is that a lot of these are people are on legacy systems, and that's the last thing I want them to do with Odoo. I don't want them to sign up on version 17 of the software and stay there for ten years, because in ten years, we're going to be so far ahead on version 27 or whatever the case might be, and they're going to be comparing version 17 of our software with 2020, you know, 2030 version of another software. And that's the last thing we want.

Emilia: 15:15

Understood. Okay. Um, so then as far as kind of looking over the project scope, um, so now you're speaking with the customer. They're kind of. Giving you the ins and outs at a very topical level. Um, and you're evaluating the scope of the project. Um, is there any time when we just say this isn't going to work? Does that ever come about?

Kevin: 15:34

That definitely comes about. Um, there's probably quite a few times that I can remember that we declined projects, whether it's just not a right good fit for our software, their team's not right in order to work together. Um, we will decline projects that we don't think can be successful. So, I mean, we don't want to put in resources on our end when we don't see the vision for the project or if it's just, you know, out of the scope of work. Right? If they're talking about, um, creating some AI software that integrates and they want us to do these things that we're just we don't have the resources to do, and it just doesn't make sense. And it's not our priority right now at least. Um, we'll definitely decline the, the project. But I would say the vast majority of customers will fit into our Odoo ecosystem. Okay.

Emilia: 16:19

Um, so then that moves us over to kind of the next call. Um, and that is where you may come in, um, now that they've spoken with their account manager, um, and now we're doing that high level understanding of the project and the sales engineer becomes involved. Um, and at this point, we're kind of trying to, um, understand the business processes. And this is where the kind of wants versus needs come in. Um, and maybe they're giving you a list of requirements or you're having more in-depth conversations. Um, how do you generally approach this kind of conversation? Yeah.

Kevin: 16:51

So generally it would go from that initial qualification call to a meeting where not really getting to the their core requirements. Okay. We're just going to discuss and build a process that would make sense in order for us to gather as much requirements as possible. Now there's kind of two avenues that this can go in. The first avenue is, hey, we haven't switched software's in ten years. 15 years. I don't really know what's out there. Can you give us a demo of just like, just general, so we can think about how we should approach the problem or the the project, and we'll do that. Otherwise they might say, you know, we're very familiar with software, we know what we want and we know what we're struggling with. And if that's the case, then we'll typically schedule several calls with different departments. So accounting, the manufacturing people, the inventory people, the services people, HR. And we'll have a separate call with each of them to understand exactly what they do on a day to day. It might be an end user or it might be the manager. We try to get several people on that call so we can really get to the root of their problems, and a lot of the times we'll do what is called a way of working meeting where they share their screen and they show us their process so they'll actually walk through, say we click this button, this gets generated, and we want to gather as much context as possible, because at the end of the day, when we do, our demonstration is going to be customized to fit what they do. And they're going to see how things map, how things are better and how things can change for the better.

Emilia: 18:21

Okay. Um, wow. So that can take many calls depending on how many kind of, um, decision makers or users you have to speak with.

Kevin: 18:28

Yeah, it can take I mean, it can take several months and it can take several I mean, it's happened as quick as a week where we have five meetings in one week with different people from a company. But oftentimes these people are busy, right. And we need to spread them out throughout like a couple of months process in order to really get them on the call, get them focused, have them have time to go talk to their team and say, you know, what are what are we really looking for here? And then bring that information back to.

Emilia: 18:56

Us, okay. And then on our end, you're now mapping this project. You're now sitting down and saying, um, these are the things that are most important. These are their main processes. And here is how we're going to put it into Odoo whether we're going to make it, you know, better or if we're going to duplicate it or whatnot. That's kind of what's happening on our end at that point. Exactly.

Kevin: 19:15

So we're gonna I mean, frankly, we just asked them, what are things that you hate, and what are the things you're indifferent about? And then I'm going to take that information. I'm going to map it. I'll probably diagram it out, share that diagram with them, have them approve it, and I'll say, hey, based on this, we're going to show you XYZ in the software, and we're really going to try to hammer the things that they like in their old software. Here's how we do it. It's very similar. Maybe because if it's if it's good, we probably do it just as good. And then here are the things where you're really lacking and you're struggling with, and here's how we can do it better. And then we'll do all the indifferent things as well, just to give them a complete understanding of the software.

Emilia: 19:56

Okay. And how it works. Yeah. Um, so then at that point we kind of move over to the show off stage, the demonstration stage. Um, is that something that you as a sales engineer are hosting alone? Is that a team effort? Um, and then how do you kind of walk into that initial demo?

Kevin: 20:12

Yeah. So the initial demo would typically be if we haven't done that overview two parts to the software. The most that you're going to get out of the software is the interconnectivity of Odoo in general. So we want to really showcase that by running through some generic flows, but kind of map to their environment, right? If they're a manufacturing company, if they're a services company, here's how you can create a sale order that generates a project or a manufacturing order, how the products move across the system, give them that that high level understanding of here's the value proposition of Odoo that interconnectivity. And then on the subsequent demos, we'll jump into a manufacturing specific demo where all I do is go through all of the settings of manufacturing and really show them exactly what they're looking for. And then, you know, if they have a specific report that they use on a daily basis or a small development that we're going to show pre-sale, we'll do that as well. So they can really envision what they're going to use. And I think that's a little bit unique to our process. I don't believe that, you know, other software companies really get that granular with what they're showing the customer, because at the end of the day, I want them to be happy with the decision they made and know that there's no doubt that they made the right decision. Right?

Emilia: 21:31

So they don't just get to see the solution played out in front of them, but they settings or changing of features. Yeah.

Kevin: 21:42

How easy. And on the other end, how hard, right. Because if it's a complex solution and it's going to take a lot to implement because, you know, we can showcase something rather quickly, but to get it right and to iterate through the process is going to be hard. And I want them to see that as well, because I want them to go into the implementation process with all the knowledge of what's easy, what's going to be hard, what are the resources they're going to need on their end, and what the process should look like. So there's no surprises.

Emilia: 22:09

Okay. Um, so then after, you know, that demo stage, or at least within it, what Obviously good and bad. You know, some people may want a little bit too much or not expect certain things. Um, what are some kind of mainstay expectations that they should have? Yeah.

Kevin: 22:28

So coming out of, let's say, the initial demonstration, they should have a high they do to be in the system. And then on the subsequent demonstrations where we dive into the manufacturing process or the inventory management process, what we want them to take out of that are all of the capabilities of Odoo in general. So, you know, what can we accomplish out of the box? And then we can fine tune the demonstrations, which is what often happens. I'll show you a manufacturing process. You'll see 80% of that was great. Here's a 10% or 20% rather that, you know, we need to tweak. Can you show me that? And that might not be I'm not going to be able to show you the full 20%, but I can show you 15% of that, you know, pretty quickly in a pre-sale process. Um, and then from there, you should have the understanding or the expectation that we can accomplish what you want and that we have enough information to map out that implementation plan, that will that will go into later on. Okay.

Emilia: 23:30

And what other resources within the company may you be pulling from during this Yeah.

Kevin: 23:36

Um, I talked to everyone. Right. So our business systems analyst I'll go to them often to ask questions. Have you seen a project that does this before? Have you worked on a in a similar workflow? I'll go to our developers and say, hey, here's where I'm falling short. I drew this process. I know what they do. I got here with the software. How do you think we can develop the software or customize the software to fit this, this extra part that is not, you know, general Odoo functionality and it's just not common in most companies. So I'll talk to as many people as I need to. I'll even, you know, message, you know, if we need context on a certain type of business that we might not have worked with before, right. I'm just one person. I'll go to the rest of the MMC team or we'll go to anyone. Let's say we're working with a company that does medical billing. And I need to understand a little bit more context for myself. You know, someone explained medical billing. So I'll go and talk to people that have maybe worked in the medical field before, see if Odoo can handle that, or what things I should consider and ask the client in order to get that process built out. Pre-sale.

Emilia: 24:44

Yeah, yeah, it takes a lot of us within our offices for sure, and it is nice just walk over and speak, speak with other people and to have so many offices with so many resources available.

Kevin: 24:58

To add to that. Right? I mean, it's great that we have offices all over the world because a lot of the companies we're working with have offices all over the world. So I get to ask, you know, what's different in Europe that I might need to consider for their subsidiary? That's in Europe.

Emilia: 25:12

Right. Um, so now that we've, you know, gone through that, that those however it apart down to hopefully. A very small percentage of not understanding. Um, this is the point where we are starting to have more conversations with the account manager as well. Um, and how do these next conversations generally go? Um, so we're talking implementation. We're talking pricing. Um, and we're talking kind of that long terme, uh, you know, outline.

Kevin: 25:43

Yeah. So this is typically the account managers, as you mentioned, their realm. They'll do a presentation about the Odoo pricing model, how we price things out. Um, you know, uniquely to us, our pricing is very transparent on our website. Anyone can view it. There's no special enterprise pricing. There's no really negotiation in terms of user pricing. It's it's just black and white. And we present it as such because I think it's fair and they get the most value out of that. Um, within that discussion there's the implementation pricing, which is a much more drawn out process because we have an internal process that we follow in order to come up with, uh, the implementation timeline. So we'll talk to them and say, hey, you know, what is your expectation of when this project should go live? What is your, you know, biggest needs in terms of applications that should happen first, right? I'll, I'll have my recommendation and say you should do this first. This is an easy win. We can get it up and running. You get some value out of the software. And they'll also have their idea of, you know, we have this legacy system that is end of life. January 2024. We want to make sure that we have a new accounting software in place at that point. Okay, great. So with that knowledge, I can say in order for us to, you know, based on the requirements we have, based on the developments, I need to allocate one, two, three, four resources to this project for this initial phase in order to get you where you want to be. So we kind of work backwards from what the customer wants, and sometimes they don't really have a, you know, a hard deadline. They want to see what we come up with. So if that's the case, then we'll put together an entire project plan and we'll present it alongside with the account manager.

Emilia: 27:23

When evaluating a project like this, is there at any point when you kind of because we obviously have quite a system of partners all over the globe who offer many different services as well as, um, the availability of being close to the customer in the first place. So is there at any point you may, um, work with a partner on this?

Kevin: 27:45

Yeah, for sure. We try to understand that really as early as possible, but you know, they might just have more expertise in a, in a specific, uh, industry. Or maybe they need to be Itar compliant or something like that. And we have partners that can easily, easily manage that. And at the end of the day, we want it to be as easy as possible for our customers. So either we'll pass it to our partner team or we'll tell them, hey, this is, you know, out of the realm of what we're comfortable doing, but we still believe it's a good Odoo project, just not an internal project. So we'll we'll message the partner team, and the partners or the partner team will figure out which partner makes sense to go to. Um, on top of that, there's definitely situations in other MMC teams as well as us in the future, where we'll partner with the partner team and have a joint venture where, hey, we can handle this bar very easily, and we think that it makes sense for us to handle. But this other part, you guys should take over that part because, you know, whatever the the, the scenario might entail that a partner is better suited for.

Emilia: 28:54

Right. Yeah. Our network of partners is, um, always a nice, um, option for our customers and something that is a seamless transition if, if those are looking for a partner and kind of want to, um, talk with us first and see what can be handled and what can't and then move over there. And I think that's the case for our entire sales department. Absolutely. A nice feature.

Kevin: 29:15

And customers are able to evaluate both. They can see what, what who they want to go with, and they can make their decision from that. Um, for for sure there's partners have industry knowledge. They work in the industry for 20 years. And that person might, you know, have direct knowledge of that, uh, of that business use case. And there's times where businesses need more than implementation of a software. They might need consultants that can actually help understand their requirements. And, you know, a larger process that that's not necessarily what we're focused on. And the partner team will really benefit from a project like that.

Emilia: 29:50

Okay. Um, so now that we've kind of moved through the initial implementation, implementation kind of take and what are some of the most common hiccups you might see at this level? Yeah.

Kevin: 30:06

Um, implementations really vary. I would say for the MMC process, you're probably looking at at least four months to get anything live, because there's not just a matter of getting a system up and running. You know, just to use you really have to map all the data from your existing system. Move it into Odoo. Test it. Figure out the kinks. Whatever needs to be adjusted. So you're probably looking at four months to go live with anything. But in general, implementations can take anywhere from six months to two years. Um, and it really depends on the complexity of the project and also depends on what the priorities are on the other end. There's so many variables that can take place. You know, you can have your Spock on the other end leave the company. And if that's the case, then we need to retrain a new person. We try to keep that single point of contact. So if someone leaves a company or if someone goes on vacation, things like that, those are all throw the timeline out of whack, and we need to make sure we kind of foresee that before while we're planning. But in general, I would say that the timeline varies significantly based on the number of resources we allocate to a project and the complexity of a project.

Emilia: 31:17

How many people would you say? Because you keep saying that initial point of contact. And in a company this large, how many people would you recommend be that point of contact? Be the one that you guys are speaking to regularly? Is that one person like in our small to medium size, um, area, or is that kind of a larger group of people? What do you think for for a successful project? Um, how many people would you be working with regularly?

Kevin: 31:42

Yeah, um, it really depends. I would say one is sometimes the case, one person, but it oftentimes can go up to probably three people. And when I say three people, I don't mean that we just interact with three people. I mean that those are the three people that are allocated on the other end to be responsible for the success of the project on their side. So you might have one person that understands manufacturing inventory, like maybe the controller or the controllers is like someone close to the controller, and then you'll have someone that understands the sales process and maybe someone that's more into the finances. Um, it really depends. But I would say, generally speaking, you want to you want to minimize that. So you have, you know, you're not overstepping in terms of communication, right? You have to talk to someone. And then you guys make a decision. Two people make a decision and then the other two people are not informed. And then the decision changes. So the smaller the team, the better in terms of who's speaking to who. But in terms of the communication to the company, there's definitely going to be some communication with the C-suite, whoever's responsible for writing checks. Right. Those people are not going to be involved in a day to day operations, but they want updates and we provide project updates weekly with, you know, the budget, the timeline, how things are going. And we'll send that out and they'll get updated. And the account manager will probably talk to them periodically to inform of any changes, hiccups, um, things that are going well, things that are not going well. And then you also want a small group of people to hold accountable, right. Because what if, I mean, this is in real life scenarios, you're going to have people who are slacking off or we didn't get something in time or our people didn't get something in time, or, you know, we didn't deliver something in time. These are all things that can happen during the life cycle of a project, and you want to minimize those failure points and understand who's responsible for what, right?

Emilia: 33:36

Because as much as we are held accountable on our end, we also hold the customer Um, and then of course, there's always the option for, uh, the a developer or a development team on their end to be involved. Um, now, is this something that you think makes a project more successful? If there's someone with that developer mindset or who works full time for the company, um, and has that knowledge, or is that something that we can take upon ourselves fully? Um, what do you kind of find at this level?

Kevin: 34:10

Yeah, I would definitely say it's a double edged sword. So it's one of those things where oftentimes I'll be on a call with a customer and they'll have developers on hand, and it makes things easier in the sense that they understand what's what we can do. Right. If you want to integrate with another software, it's not a problem. As long as they have an API, we have an API. We can develop it on our end to call their API or vice versa. It's pretty simple and it eliminates those types of questions like, yes, we can do it. It's a matter of, you know, what data needs to transfer hands. And then at the other end of things, you can have developers who want to take it upon themselves to develop specific applications. Not saying that that's not a possibility, but Odoo is a vast software and it takes a learning curve. You know, our developers probably, you know, they're in the software eight hours a day, their whole that's their only job. So I would be hard pressed to say that someone can just pick up the software and develop, you know, within the implementation timeline and not slow down the implementation. Right. With that being said.

Emilia: 35:10

Because we have our own processes in place.

Kevin: 35:12

Exactly. But with that being said, we do offer services where our developers can you know, the customer will submit their developments that they create to our dev team, will will approve it or will comment on it. And if it's approved, it goes into our production environment, into their production environment. But we really want to unless they're going on prem, we want to be responsible for the code base because, you know, with our, uh, with our offering, we offer free upgrades as long as if you have custom developments, there's a maintenance fee that goes along with custom developments. But we want to be fully responsible for that upgrade. And with that, if you're submitting your own developments, we need to make sure that they're well written, that we can maintain them and that we can guarantee you an easy upgrade from each version to version so that you stay on the latest version of the software.

Emilia: 36:05

Right. And and that's most attainable when we kind of take the lead there. Exactly. Or work obviously hand in hand with the development team on their end. Um, so, um, another question that came to my mind. Um, right when you. Speaking was, um, an ROI analysis. So you're talking about kind of doing this in stages, uh, making sure that everybody's on board every step of the way and showing them what is possible. Um, is that something that we offer at this level where they can kind of see what it could look like, obviously paid. Um, and then the conversation and negotiations continue from there.

Kevin: 36:39

Absolutely. So it's something that we do offer. We've done a few of them in our office here. Um, in other offices. It's definitely something that they push towards. It's really depends on the customer and what they're looking for. And at the end of the day, we really try to create a software or an environment that is as custom as possible. That obviously doesn't require hundreds of hours of development time in order to show them a proof of concept. But if they want, you know, down to the second, exactly how, how much everything is going to cost and all the little things that you can't really foresee without spending a lot of time with the customer. I'm talking about hundreds of hours. Then it really makes sense for you to get an ROI analysis. Or we call sometimes a pre-project analysis where we really break down to the nitty gritty, exactly what they need, and then we can map that out even better than we would be able to, uh, without that knowledge.

Emilia: 37:35

Okay. And is this something that you recommend?

Kevin: 37:38

Um, I would say it depends. Not many other software companies offer it in terms of the way that we offer it. So it could make things a little bit more challenging in the sense that if you're going to another software company and they're just saying, here's the price, and we're saying, well, you need a pre-project analysis, if we might run into a difficulty there where, you know, why do they have to pay to get the exact price right? But at the end of the day, it's all just an estimate. And we we clearly state that we try to estimate it as best as we can. Um, so if the company is risk averse and they want to make sure that they, they have the exact cost was still not guaranteed, then they can get a pre-project analysis. Otherwise, I think we do a very good job of estimating the projects. Um, the vast majority of our projects that we've sold at our location here have been on budget and think times that they've went off of budget oftentimes happen to happen with project scope, increase of project scope, things that were not discussed pre sale. And that's another thing you know we talked about earlier where you know what are the things to consider. Right. And the things to consider is if we don't have the knowledge up front that you want to do something that is impossible for us to estimate that. So we really need to clearly define and will offer a project scope at the end with our project analysis and implementation timeline of what's in scope and what's not, so that they can see this is what we discussed pre sale. This is what we're agreeing to in terms of how much that implementation will cost at an estimate basis.

Emilia: 39:09

Okay. Um so yeah so there's a lot that is offered to our customers, um, every and money when it comes to a project of this scale, especially if they're not switching, um, very often. Um, so I guess my last question would be after, um, the project goes live, so to speak, they're in their system. They're beginning to use it. Um, what kind of support is then offered at that point and after that point? Yeah.

Kevin: 39:39

So generally speaking, in similar to our all of our other deals that we sell at or hotline that they can call. And that's just going to be for things that, you know, wrong behavior of the software. This is not working as I expected or I'm having trouble. I need to understand something. Or can you send me documentation on how to set something up? That is the free version. Oftentimes for these mid market deals, they'll actually still have access to their analysts or their consultants that we have on their team long after they're go live. So they might go live today and they might have their person on call or on standby for a couple of months afterwards until they make sure that everything's running smoothly. And of course, that's a paid service. But, you know, you get the benefits of having someone there always available for you. And obviously we can also go on site. So oftentimes for our go lives, um, in all projects, especially in mid market projects, we'll fly people out to go on site and to make sure that everything is running smoothly. Right.

Emilia: 40:44

Um, so you mentioned having those resources as far as, um, um, videos and stuff Um, whether that's from our functional support team or from yourself. Um, so that kind of brings me into the other resources available to our customers, um, that the company just provides, and that includes your YouTube channel. Um, so how did that YouTube channel come about? And do you, um, often refer people to it or to any of those other resources the company offers?

Kevin: 41:10

Yeah, all the time. So to talk about the YouTube channel for a second, the reason why I started the YouTube channel was when. And I was in implementation. There's definitely we have documentation for all the general flows as a company might go through, but there's a lot more to the software. It's fairly customizable, and I didn't see a lot of resources that show end to end. Here is everything that you can possibly do in this application all at one time or a specific workflow, right? You might configure your inventory routes a certain way for a particular company, and it would probably be impossible, or just not worth it for us to list out every scenario that you can possibly have inside of our documentation. So anytime I run across a unique scenario, or just a cool tidbit of the software that I think is worth showing, then I will document that and make a video. And people have taken a liking to it, because a lot of it is things that you would actually pay for, right? Like during your implementation process. How do we go live with accounting? Right. There's so many variables. How do we transfer our our accounting books over to Odoo. So that was probably one of my first videos. And showing this is the exact process you would take place and all the considerations that you would need in order to do that process. And I would say customers watch those videos while also other consultants, and we oftentimes will, uh, produce those. Well, I'll produce those and give them to all the other sales reps to give to their clients. And I just like to dive deep into, you know, what's really happening behind the scenes versus this is how you set it up. So like, for example, there might be an inventory where I want to explain the difference between how we allocate inventory and how the system handles it versus how another company might do it. And when you're coming from another company, you're stuck in that mindset of how they did it. So let me explain the process and thought process behind that.

Emilia: 43:05

Right. And I think a lot of people within the company, um, create videos. It is something we do quite often. Um, and it is the best way to kind of share information and as well our, our personal YouTube channel, Odoo YouTube channel, um, has tons of resources available as well. Um, if anyone is looking to kind of learn certain applications or functions online. Um, so my last question for you would be, um. You had a retail company at some point? Yes. Um, would you have used Odoo for your company?

Kevin: 43:35

I would have used Odoo had I known it existed at the time. So we had a tech stack and, you know, that was a inventory software, a POS software, an accounting software, and a website software. So we had four different things that we had. Luckily, I had some knowledge and programming knowledge, a lot of experience with softwares. So I programmed scripts to connect things that I needed to connect. And that's exactly the scenario that Odoo solves. So if I would have known about Odoo at the time, I would have definitely went down the path of using Odoo.

Emilia: 44:11

Great. Well, thank you so much for being here today and explaining that process And I'm sure you will be at a many trade show this year or next year, as well as his YouTube channel is still up and running, so if anyone would like to see his YouTube channel, it is Kevin Zachy on YouTube. And as well you could probably see him at a trade show if you are traveling around the US this year or next. So thank you so much. Thank you.