Tips For CLM Vendor Selection - Lara Trope

Made with speech-to-text software, so a few words may be off.

0:00You're listening to the Contract Heroes Podcast, your one-stop shop for all things contract management. And now here are your hosts, Marc and Pepe. In today's episode, we're gonna be speaking with Lara Trope of InnoLaw, and, and during our conversation, it's going to revolve around how to, uh, evaluate vendors, going through that first step of the process. You know, there's so many different types of CLM tools in the market. There's so many different vendors out there. How do you narrow down your search? Lara, before we get into our, our conversation and, uh, what we're gonna be chatting about, we'd love to learn a little bit more about your background and how you, you kind of settled into this, uh, quote unquote, legal tech space. Sure. Thanks for having me today. I've always been a fan, um, of Contract Heroes. So really, um, I've had a bit of a serendipitous career through various legal fields. I started off in big law doing mergers and acquisitions for a couple of years, moved over to in-house for a multinational, and, uh, realized how woefully lacking operational and process thinking were in my training.

1:10And so was there for a couple of years before moving back to a big law firm where I did knowledge management, and at that stage it was combined with what they were calling innovation. It was the early days. And after that, joined a legal tech startup to see, um, you know, how fast we could actually make progress, which was somewhat slower inside law firms. And, uh, while working there, came across Lucy Bassli, who many people know is a, uh, quite a significant influence in the CLM space and all things legal ops. And so, uh, managed to connect with her, and really loved what she was doing, and have been working with her for about a year now. And, uh, working with her do, uh, a whole lot of legal operations advisory work, but with a deep specialization in all things CLM, people, process, and technology. That's awesome. And yeah, we had Lucy, uh, a couple months ago in, in one of our interviews, but this time we want to focus into something before you start talking about implementation, which is, like, looking or searching for a CLM tool.

2:18You know, uh, it can be overwhelming. There are, like, I can say may- may- maybe hundreds now, right, like, out in the market. And especially when in-house teams are, are, are looking or, or starting that search, they have no idea what they're looking for, right? It's, it's not very common that they have, like, all their processes and everything well designed. So, uh, Lara, w- I would like to start this, this chat on, uh, what are some tips that you, uh, for folks that are starting with this journey for looking for a new CLM t- tool? Right. I think, I mean, that's a really important question because that's usually the stage at which we are brought in, where people have realized that they want something, but there are so many options out there that it can feel completely overwhelming, especially if you're unprepared for them.

3:07And so we like our favorite analogy, which is likening trying to find these tools to a relationship where you're in the dating phase, sometimes the speed dating phase, where all these candidates are, you know, putting themselves to you, and you're going through demo after shiny demo, and the more you see, the more you want. And then you sort of have to take stock of all these wonderful dates you've been on and, you know, do a sensible evaluation, work, work towards customizing what you want to see next. Do you want to go on another date with them? Do you want more from them? Does it feel good? And then obviously as that progresses, you might wanna take those relationships to the next level, past the demos to proof of concept stages or pilot stages. And obviously, those are all, like, trying, can we live together? Does this relationship work?

3:57Do we want to commit to each other more significantly before you ultimately make that long-term commitment or the marriage, as we say, for that, with that one vendor that really, you know, fits with what you want. So we, you know, we see a lot of that, just trying to make sense of the, the demo speed dating craziness out there without the right preparation to help you make sense of it. So, you know, if, uh, if we have any one tip for starting, it would be just really, uh, get some people, process, and documentation in place to try and gather your thoughts and your priorities so that you actually have a more focused set of questions and, uh, criteria for evaluation before you even launch the, uh, the speed dating process. Yeah, we came from a project where someone had done 10 demos in two weeks and really wasn't sure what they had gotten out of it because they just weren't properly prepared, and so that's a lot of wasted time for valuable, you know, for people who've got day jobs. Right. Now, and especially when they have no idea on names for softwares, I mean, there are a lot of research companies such as Gartner or PCWorld.

5:04Maybe that would, that would be the Tinder on this analogy where you ... where you can see all these different techs, and then you can just click there and see all the description, what are the tools, so you can get just a sense, right, on what these tools can do. And if you like one of those, just swipe right, and then- And maybe schedule a demo, right? I think that's, that's the dream, right? We should definitely build that app, the swipe right from CLM tech app. Um, I think that that's right. So narrowing down the field is quite difficult without, like I said, the proper preparation. Now, there's different types of demos. As you know, before you step in the ring there, it's hard to know what you want sometimes without even a base level of information. So as always, it depends how much information you have in your arsenal already when you're coming in. Some people know nothing at all, and some people are pretty well-versed in these things.

6:00So that initial demo is often just a little taste of we call, like, a beauty pageant. All these contestants arrive, they show up for the judges, they show up all their talent. And then they're just hoping that they impress the judges enough to get to the next round, which is usually the more useful demo, which is a slightly more customized demo based on hopefully some of the readiness work that you've done. So some things you can say that you, you know you want. I mean, we'll, we'll unpack that in a minute. But really just, um, narrowing down this field requires that base level of homework to be done so you can either ask the right questions and evaluate what you're seeing and make that cross-comparable as well. Otherwise, you'll be lost in the dark for a while because as you know, each of these CLM vendors come from a place of specific strengths, wherever they grew out of, and will show you what they do best, and that makes it difficult to compare or ask the right questions if you aren't ready to have, you know, your priority questions addressed in each of those demos. Yeah. And I, I think, you know, it's also important and something that, you know, when we're talking to folks when they're first looking to, um, start evaluating solutions, is that you understand the different types of solutions that are out on, on the market. And, you know, it's something that we've talked about in a past episode where the...

7:19there's kind of a quadrant out there in, in the types of tools, right? Maybe you have some tools that are AI-heavy. You have other ones that are, are have light configuration. You can get them r- up and running fast and quick. There's another quadrant where they're, they're heavy configuration, right? It's a longer implementation. There's a lot of functionality. Um, but again, you know, I, I think when you're, you're looking at these tools and evaluating, evaluating them, you need to understand what type of tool the team wants, what's going to be important, what type of functionality you're looking for. You know, is it something that you can grow and scale with or, or is it something that you want to get a repository up and running? And maybe, you know, in two years you're okay with looking for another application. You just want something to, to really help with the now. I, I think those are a lot of the questions that folks need to ask themselves when they're beginning this journey. I think you're so right. I mean, I've mentioned obviously making sure you have done that homework of figuring out what your priority requirements are for your various stakeholders.

8:12Ideally, it may be a bit of a deep dive at this stage, but at least getting a, a handle on what those might be. But, you know, obviously there are other considerations such as budget, what tech stack you have, how to rightsize the solution for you. Going through these dem- these demos and seeing, you know, the full buffet of offerings obviously is gonna make you super hungry for all of it, but you may not need that. You may just need a small snack to start with and then grow, you know, grow with that. So, you know, just as you say, keeping your reality in check, managing those expectations about what you want versus what you need, what you can afford, and what fits within your organization are all big considerations as well. Um, like I said, that's why it depends where you're jumping, you're jumping off point. But definitely rightsizing that tech solution is a essential poi- part of all of this. Right. And, and yeah, and I think that kind of leads us into our next question here. You know, let, let's say that your organization has narrowed down the selection.

9:12A- and I think it's important to also note that e- even if you have a first meeting with an organization, that doesn't mean that you need to see a demo. I, I think that that first conversation could be pretty leading as to making sure and understanding that your, your needs align with what that organization or, or solution has to offer. So, so let's say you're, you're going out and, and you're looking at a handful of tools. You know, some, some just evaluate three, some wanna look at five, some even go as far as looking at 10 to have that first conversation with. What are some of those questions that you should be asking in the, the initial discovery call so that you're getting answers that you need as, as well as obviously the rep getting some information out of you? So I mean, like I said, there are various types of demos. There's the, the initial generic base level information gathering demo. Usually, that wouldn't necessarily have an explorational preparation call ahead of it. Usually, we're talking about these follow-up demos, although there is no reason for the well-prepared folk why your initial demo can't be a sort of custom demo.

10:12And so the kind of things that you'll, you'll wanna do, and there's a fine balance to be, to be had here actually, just a disclaimer, that you want to be able to be fully prepared internally, but also not lead the witness kind of. You wanna give the vendor just enough so that you can objectively evaluate what they're showing you and not arm them so heavily that they're really going to give you exactly what you just asked for and like, you know, start customizing their demo to the point that you really can't see anything else out of that. Our favorite demos, of course, are the ones where there is absolute, um, transparency about this is what we do well, and this is actually where we are limited. And those are the kind of questions you should definitely ask, but we like to prepare for these demos or prepare our customers for these demos in sort of three buckets of, you know, people preparation and process preparation, as well as document preparation. So before you even get to the vendor questions, just actually being able to have your priority requirements again in front of you and providing them with guidance on what really is core to you, what you really don't want to see, and really just making sure that you get the most valuable bang for your buck during those demos and of course, making sure the right people from your organization show up for them as well.

11:19Right. And I think one of the main challenges, especially for people doing demos, is that most of the times they are very tech guys, right? And they focus a lot on the features of the platform, which is not necessarily what they're looking for. So I think one of the most important things that you touch the pain points. What are you looking for? Are you looking for an automation for approval workflows? Are you only looking for a central repository of documents? Maybe you don't need like the biggest or more flexible CLM in the market. Maybe you only need SharePoint, right? Exactly. And put some metadata there and that's it, right? So what steps can you make to make sure the demos are actually built around these pain points and, um, processes? And, and I understand, right? Because like maybe this could be something on the second demo, right?

12:11Maybe the first one is just like showing them a very standard process from the request to the signature, posting it through, you know, blah, blah. But like what, what would be some of these tips so, so those demos can be built around those pain points? Sure. So again, we go back to doing your homework before you give the vendor the guidance. So you, again, once, you know, you want to be clear on what exactly it is that you are focusing on, you'll be, uh, it would be helpful to provide a vendor version of that, give them some written guidance to refer to as well. You also wanna create scorecards off the back of that for yourself, and then plan a call with your vendor to say, you know, "These are the things we're focusing on, and these are how we are going to be evaluating these demos. These are our expectations. This is what our-- what we're hoping to get out of this." And again, really focusing on not taking us down rabbit holes we've not asked for. Even if that's what you do well, please show us, you know, how you can address these priority requirements. And keeping in context what a demo is and is not.

13:12So we, having spoken to some of our vendor counterparts, they find that there's some customers who arrive with detailed use cases, for example, and they want that demo to show how you are going to cater for this specific use case, and that's not what a demo is. It's really a slightly customized, if you've asked for it, customer-specific demo. But it can only show you a high-level overview of those features and functions. It's never going to be able to replicate, for example, a proof of concept or a pilot situation. So you wanna go in there with a realistic expectation of what you're asking them to show you. "These are my priority requirements." Keep it quite narrow as well. Again, you may want everything, but really, what do you need as a priority, and what can you realistically expect in an hour or hour and a half demo with the vendor? So really, what you wanna keep in context is what you're asking them, what-- how much they can realistically show you in this generic environment, and provide that opportunity for a Q&A session.

14:11And then, you know, you progress that relationship to things like proof of concept and pilots as well. And really don't set them up for failure either, or insist they take you down rabbit holes that won't be able to satisfy you, because really a demo is just a high-level overview of what they can do. Right. Then I will say that doing your homework also means talking to main stakeholders, because it's not just for the legal team. That's one of the main mistakes, right? It's like you have to think about who are going to be the requesters. Maybe if you wanna do a self-service CLM so procurement can send NDAs. Like, what hell would you send the approval to a legal department when you have a very stam- standard template, right? So that's another of the things, because I've seen in some of the companies that the people that are looking for, especially this introduction, right, like, like, like the first date, is usually with the IT department. And if the IT department doesn't understand what's a CLM-- Or maybe they understand, right? Maybe they just think about contracts, right? But they don't know the process. Who is asking for those contracts?

15:16What are the processes? Who is gon- what do you need to, uh, monitor? Uh, maybe reporting some of the most basic ones, right? So I think, uh, that's one of, of, of an, an, an additional tip that, uh, people looking for, for a CLM needs to do. Like, just talk to the stakeholder. It, it's usually legal, procurement, and sales. Maybe there's another one, depending on the company. But if you talk with these guys, you're gonna get, like, a lot of information on what's going on because, you know, like sales team, they think like the legal de- department is like, uh, uh, it's going to delay the, the close of the negotiation, so they find a way to send the contract for review on Friday afternoon for, for Monday. So these kind of things, like what those problems that you need to think about, right? And maybe the commercial teams are going to give you some of those pain points or bottlenecks that are going on, on the negot- Sure...

16:10on the org- organization, and maybe you, you can just bring that up into with your, with your CLM vendors. I, I agree. I mean, I think that all goes back to, you touched on obviously a big readiness thing that we're not gonna go back into, and that is getting the right people, the right stakeholders in the room. You wanna select carefully from a cross-section of likely stakeholders across the business. Even as early as demo participants, I don't think you probably need the full suite of stakeholders on a demo necessarily. Maybe the second, third one moving towards a more refined selection process. But you really want to be, uh, quite calculated about making sure that the right people are in the room because really, aside from anything else, it's going to make getting buy-in later on a little more difficult and probably cause you to repeat demos over again for the people who weren't in the room the first time. So it's a bit of a fine balance at such an early stage, which is why, like I said, there are a series of demos that usually happen. That initial one, and then, okay, we're taking this seriously.

17:07We refined it down to these two or three. We like these guys. We can record these demos. We're gonna customize them just a little bit, tailor them so that we're not wasting anyone's time, and really make sure that a good cross-section of stakeholders get access to them so that you're as efficient as possible and don't have to revisit these demos time and again. But it does always come back to people, getting the right people at the core of everything. Yeah. And I, I think it's interesting, too, just because of where-- I mean, typically for most of our conversations, right, these are legal led, I think, in both of our organizations. You know, where legal is in their maturity scale as far as using technology, I think that it can be difficult for them to get an understanding of how to evaluate different applications. And, you know, something that we see, I think, generally in, in the software industry we see is that, you know, if you're presenting to sales or you're presenting to marketing, those teams really understand how to buy software. They've gone through this process before. They've ripped and replaced different solutions.

18:07Most of the time when we're, we're working with folks, this is the first type of application that they're buying that's gonna help, help them with anything, right? They're, they're used to older technology that's been in place for a dozen years. So I think that, you know, it falls also on the vendor's shoulders or the partner's shoulders to be able to guide folks through this process and, and also, uh, be able to show them maybe some of the things that, that they- Weren't thinking about, or breaking up the demos into smaller demos to be able to, to enable, you know, the sales or procurement team to come in. Because even if they're not gonna be a part of the, the initial implementation, they might be a part of later phases. A- and I think that that's something that maybe folks aren't really thinking about because they're so focused on their current needs and, you know, even making it self-service. You know, if there's not a way to integrate with your CRM or your ERP or, or other applications that other departments are using, you know, it- it's probably going to cause a little bit of a strain down the road, and there's gonna be other evaluation processes because there are tools on the market that can do that.

19:10Absolutely. And that's why, although... You know, that's why capturing what you really want to ask in a easily documented and cross-comparable way that everybody can sort of compare those apples with apples is really at the core of what we're saying here. Just come a little prepared. We don't wanna pretend that you need the heaviest lift in the world for demos at this stage. Like I said, there are heavier lifts coming with POCs and pilots, and there is homework that came before this in terms of gathering those requirements. But, you know, just as you say, having-- keeping your eye on the prize of what exactly it is you want to know from each of them. And there are softer things out there, like put in your evaluation scorecard the people, you know? Well, how'd they feel? Were they good? The, the people behind the team, um, making sure, like I said, that all those key elements, whether they're understood or not necessarily by everybody on the call that are going to cover the cross-section of stakeholders are captured in there so that at least all the data can be captured in one way and compared whether or not you have to evaluate it in a series of demos or, or not for various teams. But I agree. I think just making sure that you consider all those things.

20:14People aren't always thinking about it, which is why that homework becomes super necessary, and documenting it is crucial because after all of that, and after everybody has touched it and seen it, if you cannot compare and evaluate what you've just seen, it's functionally useless. And that's why we often get called in to redo and refine and regather all that information and honestly revisit every single one of those demos again because nobody was well prepared for them. But yeah, you're totally right. Laura, this may be tricky, but, like, from all the demos that you have watched, is there one that you said, "Okay, I like this one"? Like they touched this, this, this, and this. Like maybe top three things that you gotta do on, on the demo. Maybe this is thinking about on the vendor side. Sure. So it's actually an easy question to answer for me, um, because we just love transparency. We love the acknowledgement of this is what we do well, this is what we actually are working on or within development or... You know, we just like that frankness and that honesty from vendors.

21:18Those demos that really give you-- you walk away saying, "I know what you do well, I know what you say you can do and when you'll be able to do it, and maybe I wanna flag this hole that you don't cover with something else." But really just the vendors who play open cards and don't try talk you around in circles about what's possible and-- but really just show you what they can do well and how they can potentially cater for the things that you may need that they aren't working-- that, that, that aren't working quite as well at, at the moment. So obviously some people who demo have the gift of being, you know, very eloquent and simplifying things, and that's obviously a gift that we wish all of them had. But really just getting down to the nuts and bolts of what you do well and where are the limitations is something we always appreciate. And I do think that customers do too, because then they're able to also look at their tech stack and say, "You know what?

22:10If I really wanted a smart repository and you're saying this is what you do well, I need data analytics, and you all have strong AI capabilities or data extraction capabilities, but you're telling me your workflow is new, and workflow is secondary for me. Maybe I could work with you, and then we can grow into the workflow," or vice versa. So just really playing open cards and not saying that you do everything. The amount of demos we go to where they claim to be able to do everything well is an immediate turn-off, honestly, for us because we know that's simply not possible. Right. And I think this is very important, especially when they use sparkling words like AI, because a lot of people think that AI can do anything, but at the end... I mean, of course, there are a lot of, uh, tools that have more developed AI features, but it's not that easy, like just plug and play. Like you have to train it. Mm-hmm. It's not like if you upload a contract, then it will, like, extract all the terms and who signed it and, you know. Like this is something that, that you gotta spend a lot of time with data scientists.

23:10You gotta focus on the, on the things that you will need. And maybe this is not even useful if you're only going to have like couple-- may- maybe like 100 contracts. Like that's not enough like to justify this type of investment. So maybe focus on which are like the main pain points and maybe leave AI at the, at the end just to see like... That's like the cherry on the, on the ice cream, right? Because at the end- Absolutely... it's like it's a lot of processes. And, and I've seen that a lot of, of the time they, they call simple automations AI, which it's not. Exactly. And that's why we go back to knowing what's core for you, right-sizing that tech for you. Not what you want, but what you need, which al- also often goes hand in hand with how much you can actually handle. We've seen many teams sink under the weight of AI-extracted data that they don't know how to use. So it always goes back to really addressing the core, and then, you know, there's a whole conversation about phased approaches and how much you can handle and, you know, change management around this whole thing.

24:13But you are right, yes. Just keeping focused on that core, keeping it as a center. We call it the North Star, my priority requirements, so that when you start getting dragged down these holes, is it on my priority requirements list? And AI, I know, is just an example, but very rarely is it a core priority for teams. Sometimes you will need a level of automated data extraction, but only the, the teams that really know how to handle and use it well. Yeah, and all the vendors out there, and not all the vendors, but I think some of them do this in one way or another. And I, I think like you said, it's so important for whoever you're working with to be transparent on, uh, what the system can do well, what it maybe has some drawbacks on, what's in the roadmap. I, I think that's always a great question to ask is, you know, w- what's in the roadmap and continuing to ask about maybe some functionality that you've seen in other tools. I mean, something that we always ask folks when we're working with them is, you know, "Is there anything that we haven't shown you that you've seen in another tool?" Right?

25:08We maybe do it a little bit different, but if it's not something that we've discussed or, or walked you through, you know, that's information that we wanna know so that we can, one, show you how we can do it, or two, if we can't do it, give that feedback to the vendors that we work with so that, you know, it, it does get in the roadmap. And Lara, what about as far as like implementation? I- is there any questions that w- when you meet with, with customers that you should say, "Hey, you know, if you are implementing a, a solution, if the tool does have an implementation, what should they be asking around maybe the methodology, the process, the timelines?" But what about those types of questions? Wow, you opened the implementation can of worms with that. Okay, I feel like I need a stretch before I answer this question. So implementations are a whole, you know, leaping straight from demos, POCs, pilots into full-blown relationships. At the demo stage, as far as implementations go, I would keep the questioning pretty light.

26:05I have a, a strong preference for getting also your budgeting considerations all sorted out right at the beginning of this process, knowing really what you... It's all very well going through 12 demos for systems you either don't need or can't afford. So as part of that, there are questions that implementations really have a significant budgeting factor. So, you know, things that drive implementation considerations and costs include, well, what are you... First of all, do, does the vendor do their own implementation or outsource to third parties? How much comes out of the box in terms of integrations and, you know, how much is gonna be a custom configuration? For example, if you have a homegrown CRM system that needs a custom integration that isn't, for example, Salesforce out the box, you've got a whole lot of questions on your hands there. Again, how many workflows, if you're using workflows in an end-to-end, for example, CLM system, how many workflows are you ready to automate?

27:04I say ready specifically because everyone says, "We're going to automate all of our temp sets." So as far as implementations go, there are a number of questions and factors that you'll wanna wrap your hands around right up front. I do feel like we, you know, having a vendor who tends to do their own implementation or has a, you know, well-established relationship with implementation partners can give you clear answers on these things, and can give you also realistic parameters to consider on the timing and cost implementations as well, is something you'll really wanna consider up front. Obviously, once you're in the weeds, you'll know, you'll appreciate those nitty-gritty things that, you know, it depends, what do you want? Um, what are you asking me for? But we find that the things that really, um, throw our customers off are not realizing how much preparation is required for a successful implementation, being realistic that a phased approach is often best for implementation. You know, start small with one or two workflows. Even as far as repositories go, don't take 60,000 contracts you could manage from somewhere else and put them into a new system as well.

28:09You wanna do some housekeeping and things. So that readiness, factor in time and budget for that, for the actual tactical implementation, the physical thing happening itself. Be prepared to negotiate for what you want and what you're asking for and when you actually need it. Do you really need all this implementation support and custom configuration right now? Or do we wanna start with something small and see how we go? So there are a couple of factors in there, and I, I actually do find that wrapping your head around all of that and the cost and budget consideration right at the beginning, getting that project buy-in up front, helps you focus on some of those things pretty well. Yeah. No, I, I think that was a lot of great information. Hopefully, people are probably gonna have to go back and rewind that and, and listen to that and take some notes. Um, but it, it seems like, you know, the methodologies that you're talking about are definitely things that we try to tell folks and, and work with when we're implementing solutions. You know, go slow at the beginning. Make sure that your requirements are gathered. You know, we, we do something called an immersive design at the beginning of all of our, uh, implementations to make sure that everybody's on the same page.

29:09Uh, we wanna make sure, 'cause in the past we've had implementations where we get to halfway through and people finally understand really what the system is capable of, and they wanna change everything that we just implemented. So, you know- Yeah... I think it's, it's so important to make sure that you're on the same page with your vendor or the partner that's implementing the solution. And, and also making sure that the, you know, like you said, if, if a vendor is passing you off to someone else to do the implementation, that, one, they've done this before, and, and two, they can actually, um, talk and understand the language of whether it be the legal team, the procurement team, or the sales team to, to understand what processes that they're looking to, to put in place. So Lara, the final question here is, is gonna be around proof of concepts. And, uh, I know we could probably talk 40 minutes just about this, but at a very high level, what, what should folks be looking to, to get out of these when they're, they're speaking with vendors? I would say, right, maybe when you narrow it down to your, your top two, that's, that's when this is a good idea to, to get the, the ball rolling with this type of- Yeah, I think-... trial...

30:07as I said, let's be frank, you don't ne- necessarily need a proof of concept or a pilot. You need to understand what you can get out of them, and also that there is a commitment expected on both sides. So don't ask for one if no one's gonna sort of participate in it or you're not ready for it. Again, we can't emphasize readiness enough because there's a lot that goes into these things. So proof of concept obviously is a minimally configured sort of hands-on experience of the vendor's, usually their sandbox in- sandbox instance of their solution There's usually little to no configuration on the implementation process for, for these POCs. So that actually means there's some limitations that you can expect. So really it's just a more practical way of experiencing the system, and it's often helpful to test a few, again, core things in there. Go in with a targeted view of testing a few things and see how they look and feel, but acknowledging those limitations. I would say for a proof of concept, probably a maximum of two.

31:08I wouldn't like to think three, 'cause again, trying to free up enough of the right people to do the work and to test these things out and to keep it contained enough to get out the data you want to compare it and make decisions is difficult enough with two or even one. You don't... But I would, I would say two is probably the limit. A proof of concept will be shorter and so helpful to really just start kicking those tires practically, get some tech buy-in for what's practical in those implementations. But again, a light configuration to show you more with the limitations that come with a sandbox kind of site. And then obviously a pilot is a more custom configured implementation, almost a full implementation of the system. Plus they'll probably hold back some of the full configuration that might happen, but usually it forms the beginning of the long-term relationship. And that's why pilots are often also paid for which proof of concepts aren't. Because there's a heavy lift requested from the vendors. There's work to be done on both sides.

32:05So entering into a pilot shouldn't be done too lightly. And I would certainly say try your preferred vendor. See if that doesn't work out, perhaps move on. But I don't think doing two pilots at once is necessarily a effective use of everybody's time, and it's unlikely you're going to get everybody using that system effectively for the slightly longer duration than you would for a proof of concept. So really comes down to, again, taking that moment to consider not what do I want, what do I need, and what's the best way to get it? And sometimes there will be a-- also right sizing it again for your organization. Are you a small lean team that can ask questions, you know, really engage back and forth quite nimbly with the vendors and, you know, share screens and see what's happening. Maybe you don't need a full-blown pilot, maybe you do.

32:55But sometimes in a more enterprise organization with so many stakeholders and teams who really wanna feel that they're part of that process and really get in there and test things out across all stakeholder teams, things like pilots can be helpful. But again, that's a whole other discussion on how you make sure that you prepare for them properly, implement them the way you want, and test and measure in a sensible and efficient way so you can get the outcome that you want because it's a big investment of, you know, time, commitment and cost of course. Uh, so yeah, just knowing what you're hoping to get out of it at the beginning, that clarity is, is real gold. Yeah. No, I, I think that's great. And I, I think something else that we've found too is, is, you know, whether the POC is two weeks long or a month long, uh, making sure that you have weekly meetings with the, the vendor or whoever you're working with to continue to push that forward. Make sure that they're pushing on your team to, to get them in there and actually use the sandbox so that at the end of the 30 days, you know, you might have some team members who never even got in there, don't have any feedback, and just slows the entire process down because then you have to try and ask to get that extended and sometimes, you know, that's just not possible.

34:08So, you know, making sure that your team is actually getting in there, using it, getting their hands dirty, I, I think that's a big, a big another point in, in these types- Yeah... of evaluations. So, I mean, not to labor the point really, but there are like a couple of things that off the top of my head that I always go back to on why these system tests, these pilots or POCs sometimes fail. And usually the primary one is, again, lack of readiness, a badly defined scope, unrealistic timing because you haven't considered, you know, who's got what on their plate and what they can actually handle. That lack of stakeholder support. You just went in blind, you know, the two project owners decide this is a great idea, and that insufficient participant engagement and that failure to collect feedback as well, and that failure to monitor progress. And all that is wrapped up in obviously a change management effort and a constant communication to alleviate all of these things, as you say, to make sure that everybody has their role, it's clear, and is driving this to make sure that you get your desired outcomes.

35:09Just a little bit of good planning, good housekeeping, and some homework is generally the difference between success and failure, pretty much across the board in all aspects of CLM we find. Yeah. Yeah, I think we definitely can agree upon that. Well, Lara, this has been a, a great conversation. I, I know we could probably sit here forever and continue digging deeper, but I think we're gonna wrap it up here. So, so thanks so much for joining us. If, if folks wanna connect with you to have a conversation, uh, or learn more about Innolaw, where's the best place to do that? There's always good old LinkedIn. Can look me up on there or the Innolaw group website has information about the kind of support that we provide. So either of those things, um, will be a great place to connect. Awesome. Well, thanks so much for joining us and thanks to everybody that listened. We hope to have you back here soon for another episode of Contract Heroes.