Video: Making the invisible visible: how contract data clarity drives an optimized operation | Duration: 3767s | Summary: Making the invisible visible: how contract data clarity drives an optimized operation | Chapters: Welcome and Introduction (0s), Understanding Contract Data (31.906000000000006s), Contract Data Insights (140.64600000000002s), Manual Data Extraction (703.386s), Data Delivery Methods (1722.4359000000002s), Automating Data Ownership (2202.226s), Integrating Contract Data (2670.476s), Operationalizing Legal Processes (3254.216s), Focused Productivity Strategies (3337.996s), Future of AI Analytics (3421.7960000000003s), Closing Thoughts on AI (3546.661s), Ensuring AI Accuracy (3618.0458s)
Transcript for "Making the invisible visible: how contract data clarity drives an optimized operation":
Thank you, thank you Jennifer. And no, no, I'm not co hosting with Simon, I do not share the stage, so I need my attention to flourish. I mean, hopefully, hopefully everyone, I'm the person you will hear speak the least today. We have a very esteemed panel of a lot of folks that, you know, have seen a lot, done a lot and I think that's why you're here as well. So without dragging this out any further, I just wanted to give you guys a quick overview. We're going to run this in three sections. We're to talk about finding the right contract data, know, what the heck is this stuff, what's important, what's not, how do we get at it and then we'll talk about operationalizing it in the next section. Hey, I have this huge database of tons of fields and columns and you know data sets, what do I do with it, you know, so now that I have it And then we'll spend the last section talking a bit about where we see the tech going, what you can expect to see in the future around your contract data, things to think about, things to plan for, fun stuff like that. So without further ado, let's jump into talking about contract data. Gents, I'll just kind of define the term so that, you know, we've got a lot of lawyers in the room. I'll do my, you know in quotes contract data to me and I'd love to hear if anyone else has a different take as well. It's just all the information sitting in our contracts right. Yes it's things like who the parties are, what the start dates and end dates are, it might be liability caps, it might be audit language so that we can be aware of when we are subject to audit or when we have the right to conduct an audit. It can be things like termination provisions around when can I end the relationship, stuff like that? It doesn't always make sense to everybody, right? I know, know, Sal, you and me, we've gone the attorney route in the past as well, you still today, but I'm a recovering attorney. So, you know, sometimes that language doesn't translate easy to everyone else if you just go, hey, look at this section. But that's data. And so taking that out is our first step, I think in the journey and the discussion here. So do you guys have a different take or anything to expound on when it comes to what contract data is? I would just add that, you know, again, AI is everything right now and legal seems like it's all over the place, but contract data for people and for machines is different on different days. Right? And so One of the things that I found striking is that the old days of figuring out classification and taxonomy, all these stuffs kind of got forgotten about a little bit because a human could review the document and figure it out. But if you lose that part of it in the first parts of setting up your systems, you get hurt on the back end when you start using the machines. Again, this stuff is interesting in both application and practice as you're a lawyer, but also in how you use it later, so I think that's another thing to think about. It's not just the words always, it's also the structure of the contract, it's the types of provisions you have in it and where they sit. It's a bunch of stuff that doesn't always seem obvious. That makes Yep, I totally agree with that. Think the point of structure and foundation of data cannot be overlooked, but and, you know, I think we'll and we'll probably get more into that in the details later in the conversation. But when I think about, I think, contract data and what truly moves, let's say, the needle for business outcomes, For me, I think the the the most impactful element really isn't a clause at all, somewhat of a hot take, but it's really the documentation of decisions and communications that happen throughout a negotiation. For example, like terms like pricing, renewals and obligations matter, of course. But what really drives, I think, you know, business values, having a reliable, audible record of, like why certain terms were chosen, Right? What risks were accepted? What concessions were maybe made and and what assumptions both, you know, sides were operating under. And, you know, when and when those decision points and communications are, like, automatically captured and stored and not buried in like email threads or lost in like side conversations. I think that really changes everything in a lot of ways. Yeah, no, no, it goes to Nigel, like what you were saying, but it goes to me almost, well, what data truly drives decisions, Like what we have on the slide, but also the legal language barrier in the sense of, you you think old school data extraction, it was find this type of clause, extract the full like body of the clause and then associated with the data labeling. This is the assignment clause and that's part of it but that's not the real answer it's like the data two point zero that we are looking for is can I assign this contract? Am I prohibited from assigning this contract unless you know we have a written agreement? Or can I assign this contract with caveats? You know there must be notice blah blah blah. So it's things like that that I think the rest of the business needs to see and understand not just this is what the contract says in a block of text. That's the data and there's the real data aka the answer and then the fun stuff we can do that for the entire organization, not just legal as well. I'd love hear, oh sorry Simon, yes. I was just saying, think a word we'll have to get used to at some point is normalization, right? So to your point, sometimes you pull out here's what the clause says and sometimes you have to take a true data chunk that can then get distributed across the organization, right? So you might have a field somewhere in your database that is, I don't know, just a yesno, right? Can it be assigned? Yesno. Or you might have one that says how many days do we have to pay this bill? And you bring in forty five. So you lose a certain amount of the nuance, but I think in order to drive the data from contracts through the rest of the organization, you're gonna have to summon out of normalization to take data chunks that can then get distributed into other systems and then that those other systems can use for their own processes. I love that, I love that. And Simon just talked about normalization as well. And I think that's before we move on to like the next slide and some fun questions as well. It's really that data overload. I think, and I love to get you guys' takes on it. I'll go to you first Sal, but you know, we live in an age now where there's abundance. Some would say, I would say an overabundance of data, if you will. You know, there's so much we can get out of it that, you know, perhaps there's too much and you kind of a maybe want to phase it, pick and choose what matters and not just overload or to use the term we've all heard before, boil the ocean. Right? And so, like, I'll go to you first now. You know, how how do we avoid this one pitfall? Because, you know, too much versus focusing on what's essential so that we don't get sidetracked, so we don't cause spirals if, you know, we're doing manual human QA and stuff like that as well. What do you think about this? Yeah, I think part of this is looking at your actual process within your organization before you go buy technology. That will drive a lot of good decision making. I feel like too often, your legal department gets to a certain size or somebody says, Hey, it's time to buy X piece of technology. And you go out and maybe you do an RFP or whatever it might be, and you get the technology and then you get stuck in this. There's all this data we can make decisions on, but you actually haven't spent any time to figure out what matters. That's your point, right? So I think starting with what matters to you and your organization is different for every organization, right? Some organizations live and die on, you know, a term or renewal or an ability to upgrade. Some organizations, that doesn't mean anything to them, right? And so I think the key question is, yes, there's an endless amount of data, but how does it apply back to your process? Again, post signature gets ignored a lot of the time in this evaluation, and I think that's the key data that you want to focus on. Sure, there's all kinds of terms that you're going to negotiate over and over that you want to protect the company. That's great. But at the end of the day, once the contract is signed, you have obligations that you have to follow through on. So being able to track those obligations, being able to understand what data matters for your organization is where you where I've always tried to get organizations to focus. Yeah, no, no, makes a lot of sense. And Nigel, I know you'll touch on this a little bit in a later slide as well. So without letting the cat out of the bag too much as well, I think, you know, how how do you think about, you know, data overload versus starting small insensitively? It's like, what can you advise the audience about how to proceed? Yeah, it's totally, especially I think global complex organizations, and this is where it becomes maybe more, you know, of an art than a science, it's finding that commonality across functions and, you know, translating that in contracts or in a system and, you know, from a data perspective. And it's like, how how how can you find that point of commonality in a way that speaks to everyone? I remember a mentor once told me that, you know, like your stakeholders don't care about your legal workflows. And I think, you know, someone who sits within the law department, right? Like that's that's like an important takeaway because like when you're in, when you're designing processes right around business priorities, of let's say legal convenience, you're transforming into a business enabler, but that's really hard to do from just a mindset perspective and, and really trying to sort of anchor everyone, I think, around, business outcomes and not, like, data fields is is is a is a good way to do that. Because if you start by asking everyone, for example, or, like, let's say every team, if you if you ask them sort of what data they want, you'll get 50 different answers and that's hard. And that's like, what do you do with that? But if you ask maybe like, what business decisions are you trying to make faster or like more reliably, then that conversation becomes, I think from my experience, much more simpler in a way. Nigel, that's brilliant, Lisa. I remember when I started messing with big data, which has slowly become AI, we always used to say, getting a great answer is easy, getting a great question is difficult. And I think to your point, don't start with what bits of data can we pull out, but rather start with what are we trying to make work better? And then derive the data you're going to pull out from that is a really good way for aiming it. I love this guys. I'll summarize this as we're here to solve problems with data, so figure out your problem. So for the audience as well, I think we all kind of gave you the attorney answer in a way in that what data is valuable? Well, it depends, right? And what you should focus on depends on your process, your workflow, but ultimately what problem you're actually trying to solve as well. So let's move on to some fun questions and then we're going to end the session with Nigel sharing a bit of a case study with us but I'm getting ahead of things. So Sal, I'll go to you first. You know when you think about contract data points, you think about one, what's what's the first like a metric that just pops into your mind that really meaningfully universally I should say kind of is valuable to an organization as if you're extracting data for the first time, look for this. Any thought on that? I know there's a lot of different options, but we only have So time to talk about a the metric, it's not specific to a contract. In my experience, right, so the number one thing a legal organization can improve on to make the business run faster is turnaround time. Understanding how to get that back in the hands of the business is a metric to evaluate. When you're thinking about a contract data point and you're thinking about how to do that, the reason I bring that up is that if you can tie specific contract points, whatever it might be, and put it back in the hands of the business, who is oftentimes the first one to touch a contract right before it gets to legal, you improve that time because you're reducing the amount of stuff that the lawyer or the legal team has to do. There's all kinds of stuff that legal teams get put on that is administrative, really. I usually start with thinking about it from the perspective of what's the outcome we're trying to achieve and whose hands can we get it into so that we can turn around contracts and get it back in the hands of the business so they can close the deal faster. Yep. No, that makes sense. Turnaround time is super important. Mean, it's in a way part of the cost of the contract as well. We always look at the dollar signs in the contract document, but there was a cost to get to that signed piece of paper as well. And that's something I know GCs, CFOs and COO's like to look at as well. Nigel, any data point that's kind of your top or in your top three that you always want to go looking for? Totally. I think one that's maybe, I would say like maybe underrated, if you will, is is counterparty identity. Right? Sort of, like, counterparty name, whether it's a customer, or supplier. I at a previous company I worked at, we we kind of, you know, it was interesting to see, I guess, how inconsistent our customer and supplier descriptions were like across the company. Right? What looked like a same customer distributor often, you know, existed in like five or six variations across, like, legacy systems and contract files. And then, you know, as, like, certain companies go through m and a activity, they get consolidated into others. But point being is is that concept that I think of of counterparty name standardization. It doesn't sound exciting, but, when you analyze it at scale, like, you know, what we realized at my previous company, it was driving, like, a lot of reporting inconsistencies, right, duplicate records and even sometimes conflicting commercial terms. And yeah. And then, you know, at first, it may seem like a minor cleanup issue, but, you know, once you kind of standardize that specific kind of data, I think the impact was huge. Suddenly, you know, we could see kind of our our true global exposure, if you will, with, like, a single third party identify, like, where different regions had maybe, you know, negotiated conflicting terms and even, like, spot patterns and pricing and, you know, other obligations that were not readily apparent like before. Think that's a really important point, Nigel. You know, sometimes it's the basics, right? And this is where, know, I'm not a lawyer, as it turns out, at least that wasn't obvious. But I have been working with this software stuff and, you know, I remember back to the master data trials of ERP, right, where IBM and International Business Machines appear to be two different companies. And this I think is an area where AI can help to solve some of those things where one person puts in IBM, one person puts in IBM, Inc. Getting a trustworthy set of those core pieces of information is so less, so much less likely to end up in the news and so much more important to the effective running of a system. That's a good one Simon and actually I know we like an Agiloft, we just launched obligation management as well and you work with a lot of our users. What are you seeing as far as what obligations out of contracts are typically rising to the top that people want to track the most? Well, think most of the folks who are really getting down and dirty with it are very much of Nigel's mindset. Let me get the core pieces, right? Let me make sure I've got my counterparty right. Let me make sure I have my, payment terms right, that sort of thing. And now what they're really doing is looking back to my own sort of self promotion earlier, they're looking for areas where there are things that they can normalize and push into other systems. Because in the final analysis, when you think about the concept of contract management, right, if you ask a stupid question like, was this a good contract for us or not, and will another one that looks like it be good for us, if we only look at it from a legal lens, really what can be bad about it? Well I guess we might get sued or we might have to do some suing, it might collapse, but what we don't really think about is the ongoing delivery of value. And so it's that ability to move key pieces of data into other systems to track value and then can report back, right? So you can look at a contract where you agreed to buy, I don't know, a thousand widgets a month from some company or other, they promised to deliver them within seventeen days, and you can actually go back and track whether they did that and whether when things went wrong they appropriately followed the terms of the contract. Now all of a sudden the concept of a good contract sitting inside of your CLM system becomes a whole lot more three-dimensional, because you're not only looking at did we end up in litigation, you're also looking at did we get the value we anticipated, did we deliver for the business, right? And that's where it gets really exciting. And so I don't think anybody's 100% there yet, because it's a relatively new concept, right, for a legal ops team of extract usable data that now runs through the rest of the system and reports back. But that's definitely where a lot of the focus is. Yeah, no, no, really great. And everyone in the audience as well, please make use of the Q and A function as well. If you have any burning questions for myself, Simon, Sal, Nigel, ask away. We're not having a dedicated Q and A section right at the end. So don't feel like you have to hold your questions. We'll try to address them live as we go along as well. We want to keep this conversational, although I know you can't unmute yourselves and talk to us us directly. So please make use of the chat as well. And Nigel, I'm going to cut over to you and your case study because I think we've really kind of already answered several of these questions that I had prepared for the panel. But before I kind of pass the buck to you, so to speak, to tell us our story, because I know you've been involved just right now, I think in a CLM implementation and you're living with the data extraction and the data management you have been for the past. I don't know how long has it been now that you've been having to deal with contract data on this project? Like a year, less? Yeah, more or less for this specific implementation. That's right. Before we start to share. I love it. So before I go to you everyone, at the end of the day to summarize, with contract data, we've told you it depends on what you want which I realize is again the lawyer answer but look at your process like what Sal and Nigel and Simon have all said in different ways to decide what really you should focus on. Obviously how you get that data out of your contracts is a combination of AI tools, your CLM system. I did want to say one thing before we move on from this. On the data collection side, you know, when you think about pre signature and post signature phases of your contract, the post sig stuff, typically I know we use AI to extract information, sometimes as a human in the loop component or we use ALSPs and that is great. But don't forget that that typically is focused on what's in the body of the contract. But there's data that you want to collect on the front end while the contract is being negotiated as well. That will not sit in the contract, but we do want to associate with the contract. And so you collect it as part of your workflow through an intake form or through the review process and then store that. That will give you a way more robust data set to work with than just pulling it out of the signed document alone will. So keep that in mind as well as you go on your own contract So data now I'm going to shut up Nigel, We'd love to hear from you. Tell us everything about what you found and experienced so far. Yeah, no, thank you, Navin. I think one relevant story to share, right, when we think about sort of contract data and, you know, finding the right data and, you know, implementing sort of a contract repository in the first instance, like, what does that really mean? And, you know, I think there's a lot of AI that's always thrown around. And I know everyone, you know, loves to talk about AI, but, you know, to use another, saying we can't really put the cart before the horse. Right? And I think it's it's for example, like, you know, where do you even start if you don't have a contract repository yet or have never implemented a CLM? Like, are you gonna jump straight to AI? You know, that's probably not. Like, you know, like, it's and then and that's kind of a, you know, big point I I kind of wanna drive here with this with this story. You know, we we as Navin mentioned, right, we we are in the part of sort of an enterprise, CLM implementation. And as part of that sort of implementation, right, we set out to migrate all of our legacy contracts into this new system. And before, I would say, considering, like, any third party AI tools, we actually tried sort of building a custom, like, extraction model in house to kind of accelerate that process of data extraction. And I would say, like like, right like many teams maybe or just people generally, we assumed AI would do most of the heavy lifting. So we fed our agreements into, that extraction model and expected clean structured data to fall out on the other side. Well, not exactly. Long story short, like, you know, I but that said, I I think it taught us a quick and and humbling lesson. And right just to be clear, right, the model was, producing outputs, but without the time to properly train it and put strong validation protocols in place, especially given, you know, how much our contracts vary across regions and business units, the accuracy just wasn't where it needed to be for migration. Right? And, like, I don't think anyone when you buy sort of new technology or new anything, you know, you don't wanna put bad data in. So it's to your benefit and the company's benefit to really take the time to understand, you know, what what do we really need. And it wasn't, right, again, a limitation of the technology itself. It was really a timing and maturity issue on our side, and I would say that was kind of our, you know, whoops moment. But in that sort of realization, I I think, we pivoted. Right? And then we pause sort of, let's say, the AI experiment for this specific phase and move to, like, a fully manual extraction approach for our critical contracts and, you know, finding what exactly would be deemed critical is, a whole another, I think, process in itself. Right? Because, like, initially, we were looking at our whole, like, legacy repository, which had, like, hundreds of thousands of documents. But then, like, do we really need all of that in, you know, our new system? Probably not. But, you know, honestly, looking back at this and, like, right, we're still kind of towards the end of that overall, you know, manual extraction process. But going, I would say, the old school was exactly what was needed, and and that's okay. Right? You know, like and I think that's that's important to especially as, you know, we are entering the era of, like, where AI is everything. Like, AI is is great, but, like, know, make sure, like, you know, it's it's not always the best starting point. And, you know, like, in so, like, as as we pivoted kind of, let's say, so that old school met method, it not only ensured that, you know, we were, like, then getting clean, reliable data for kind of this new enterprise repository we were building. But more importantly, like, the manual work of, like, touching contracts directly, extracting key fields ourselves, and, like, working with cross functional partners to pull data from different system also surfaced, I think, insights we, I would say, never would have found otherwise. Like, it really forced us to think critically about, you know, what data do we actually need and, you know, how we wanted them structured moving forward as, you know, points that were previously made and, you know, and what should be prioritized for migration and how different systems and processes would be affected once our new system went live. It's just that level of understanding, I think. Right? Because I I would say from a, you know, legal AI perspective, we're not a super mature organization, but that level of understanding would have been harder to get if we relied entirely on automation, if you will, on day one. So I think, yeah, the bigger takeaway is that AI isn't a magic button, but it won't solve everything immediately, especially when you don't have the time to train and validate a model properly or when maybe cost, regulatory requirements and, you know, policy constraints certainly was at play here as well also come into play. Sometimes, right, the smartest approach is to just start simple, you know, like build a clean, accurate foundation manually, which is what we've done here. And then layer in automation once you, you know, you really truly understand your data and trust it because that element of trust, right, that's, you know, that's really important to say the least. You know, it's it's not glamorous per se, but it's really what actually I think sets you up to scale responsibly in the long term. And and then and, you know, I think another sort of lesson throughout all of this, right, is is that, you know, your data extraction also has to be systematic and quality controlled. Right? It's not just dumping text into fields, really, to that point of trust, building a foundation, the the business and organization at large can trust. Yeah. And just open text fields. Right? That that's why I hate sort of when whenever I'm configuring, like, a drop down menu, I I would never almost never put in other option because with whenever you have another option that then, you know, allows for sort of free text input, I think the majority of cases do not need another option. Like, you should be able to find sort of, you know, a taxonomy or values that can sort of account for different nuances. But, you know, never say never, but show me a good case in which like another other value is needed. And I would love to see that. Oh yeah, you'd have to drag me to doing free text input Nigel. It's everyone always fat finger stuff. And then you have 15 different variations of Amazon or addresses for notices and stuff like that. This is a really great story, I love hearing it and I think the, you know, to use the term human in the loop, I think component is really important you know it's like a lot of people have bad experiences with AI where it's just hit the magic button look the other way and things will happen and it's it does require planning and a strong foundation and kind of being clear on what you want, what output you want as well. So thank you so much for sharing that. Again, guys, please feel free to drop if you have questions, if you're implementing CLM yourself and trying to figure out what data is important or how to go about it. Now is a great time to ask those questions and we'll try to answer them if we can as well. Let's move on to the next section to keep us on pace as well. You've got your data, you've got that massive spreadsheet of beautiful metrics, data points, all the answers you could ever want, now what? Yeah, so I think that's really a key component where a lot of this tends to break down in practice. We collected all this data, what do we do with this? And obviously you can take that data style, I'm going to come to you first, know, because we talked exactly about this in the pre session, right? But you know, do we deliver that data to the correct stakeholders? What are some of the most common easy ways? I guess Sal, let me just pass it to you because I'm tired of talking already. What are you seeing as far as what your clients are asking or what legal and other teams are asking for to be done with this data? As we were talking about, Priy, the number one thing people ask us for is dashboards because they are pretty easy to stand up and you get visualized information that anybody can access. And why? Well, there's lots of data that's kind of been hidden in contracts for a long time or forgotten about, and now with some of the AI tools and some of just old software development, you can build pretty nice visual representations of what's going on. That gives access to the business and your legal team to understand everything from how many contracts are in flight to renewal terms, to what the entities that you have on your list that you need to fix, whatever it might be. Dashboards are the number one thing people are asking us That makes sense. I mean, I've produced so many dashboards over the years and it's the most digestible way for your stakeholders to kind of see that data. Is that a space for complicated dashboards, right, where people get a graphical representation but they can drill down into the minutiae if they want to? Is that typically a demand for that cell? It depends on the business, right? Very lawyer answer. At the end of the day, think it goes back to end state. So I always preach this, like, what are you trying to achieve? What do you want out of this? And you know, it can be easy as we've all talked about to get into the fancy bells and whistles. I want all these things instead of just thinking about what actually matters to the business. And that also saves you from a velocity perspective and a cost perspective and whatever you build and do. And so, yes, there are fancy detailed dashboards. When you go into them, you can get drop downs, you can dig into the contracts and it'll send you the contract you want, all kinds of really nice stuff. But at the end of the day, you just really want to focus on what matters to your organization and put it in a way that's easy to understand for everybody. That's the other key thing that we do with dashboards is it's not legal focused. We're not focused on legal taxonomy or terminology or the things that legal cares about per se. Some of it's short, but a lot of it is so that somebody in the sales team or the C suite or whoever it might be can easily open up the dashboard and just see the information that's important to them. I like it, I like it. And Nigel, from a delivery standpoint, like now that you have, when you have data, how do you kind of deliver that to your different stakeholders? I know we've talked about dashboards, but do you deal with things like tagging, alerts, any automated notifications and stuff like that? Yes, yes, totally. I think that's a big part too, is is those kind of notifications and, you know, automated notifications according to certain, obligations. I think one part on sort of dashboarding and and, you know, kind of thinking here or, you know, what you made me think about, Sal, is, like, I also think it's easy and just, like, in gathering sort of, you know, how we want this data to be sort of received by our, you know, internal stakeholders is it's easy, I think, to over dashboard too, and it's like a fine balance too of, like, you know, finding the right dashboards and not saying yes to everything. And that's kind of, you know, things I've experienced in the past and, you know, always seem to experience, you know, as as a legal operations professional and and and really need to, I think, force sort of that cross functional alignment in a certain way. But, yeah, that's that's doesn't really answer your question. I don't think, no, but, yeah, I think for this is really top of mind for me. But, whenever whenever I think dashboards, I'm I'm always thinking like, wow. Like, I've been in instances where I've seen over dashboarded systems, and and and I always, you know, try to sort of, you know, prevent that by really trying to, you know, ascertain from sort of that cross functional collaboration what might make the most sense, whether that's a dashboard or, some sort of auto renewal notification or any notification. That's an interesting point because part of this you bring up is that legal has a history of wanting to own all parts of a contract, and they don't want to release information so that they can't lose things, and so you get in this back and forth where the cross functional is the key thing here. That's what you said, so giving both sides, every owner of this stack the option to see information. Now, you want to make sure you tell a story in a way that is helpful, and 100% that was what I was getting at, you can over dashboard for sure, but I think the reason people are asking for it is it's a little bit easier now, you can connect data in ways that you couldn't before, and I think more modern legal departments are starting to think through how do we relieve some of this administrative burden so we can get back to being strategic in what we're working on. Sal, you segued really perfectly into the ownership aspect of the data, Because I think it's pretty common that legal kind of owns the data extraction stage in some shape or form, you know, through the contract review process and then, you know, the post signature process as well is typically what I see. I mean, it can vary. But then now that you have the data and I know I shame on me because I talked about ownership when I wrote these notes, but really it's who's accountable to action the data once it exists. So the great example that I've done far too many times is the standard. Here's a list of vendors that are going to expire in the next thirty days sixty days, ninety days and we send automated emails to different people in procurement or finance. And then of course they still need to be responsible to then take that step to negotiate a renewal, send a cancellation, things like that. And so technology can be really useful for that piece. But before I go to either of you Simon, I think it's worth kind of talking about this as well. Do we also have ways to kind of in a structured or programmatic way just assign users to specific owners to specific data points automatically? When you send it? Yeah, do actually and that's a really interesting question. Obviously you mentioned a moment ago, I did, one of us did, that we just released some new stuff on obligations management, does this automatic extraction of very specific information. Much like what Nigel was saying earlier, lot of people in the early instances are saying I want to take charge of this, I want to actively decide who's getting a task, who's getting a notification, what I'm tracking. But within the system we also have two ways that you could automate that. And I like automation not just automation safe, but because it takes out a step, right? If let's say Nigel's going in there and over ninety days you've gone in and you've assigned to the DOs, you've assigned actions, At some point you go, well crap, they always go to Bob. These, you know, the ones for this always go to Bob. I should set something up. So within our system you have a couple of choices. You can do it with a standard action, right? So it's just normal, what the wonks call deterministic, it's just a decision tree. Or you can apply PromptLab to it. PromptLab being a kind of build your own AI agent thingy. So you could pop in a thing there that says, okay, take a quick look through based on everything we know about this particular contract, you know, it to Bob if it's, you know, if it's appropriate to them in some way, shape or form. So you might say if it has some combination of characteristics. And the neat thing with PromptLab sort of self built AI action is you can have it run based on any number of events. So you could press a button, pressing a button is fine, but you will also have it run-in conjunction with your obligation extraction process, right? So you could say I am now comfortable that any time a certain set of characteristics are present in a given obligation, I know who we should get to. So every time you run it, also run this little action to a certain, it'll create a task and assign it to the right person. So you actually take a lot of steps out. And that actually, if you don't mind me, maybe sort of going sideways a little bit, it does actually speak to one of the questions that just came in from the audience, which was what are our thoughts about having AI create summaries to contract documents that are unique for the business stakeholder? And I'm grabbing it because I was talking about And PromptLab is a thing which does that. And by the way, I think it's brilliant. You know, what we know, and I think what both Nigel and Sal have been talking about here is getting the right information to the right person without hiding it winces or wherefores. I think it's a brilliant idea. Actually, all of our customers have access to a baseline summary creation action in there which you can then adjust. So very much worthwhile making sure that when different people go in to look at a contract and want to understand it, can give them little links. So you press the button and it will pop up a summary that is specific to the needs of that individual. I think it's a brilliant way of doing it. It. It does two things, right? It satisfies the need of the person who's reading it, and it frees up the time of the individual who otherwise would have to write up another summary for another person as another set of expectations. I think it's a really important and actually frankly, a really good use of AI, right? There are lots of terrible, terrible uses of AI. I'm not going to ask Sal and Nigel to list them because I'm not sure I'll enjoy that list, to be honest with you. But a really good use of it is a summary that is designed for the person who's going to read it, so they get what they need and they don't get on the phone and stop bothering. So yes, ultimately you can automate all of this stuff, you can use AI. I think it's important to say sometimes AI isn't the right way to go, right? Sometimes you really do just want a decision tree which is back of life, right? But if you want to use AI, it is something you can do today and I think it is important because we are essentially accelerating that contract process so that the focus for any deal is on the deal, not on where the contract is. I think the more that we can do that, the more that sales or procurement or engineering, whomever, are looking at the contracting team as the connective tissue who's getting things moved through in an appropriate way rather than the people they have to get through because we've got to get it signed up by legal, the better everybody's going to be. Yeah, no, no, think this is a great question from Henry and also I've successfully done, Sal, I know you play a lot with AI as well these days, but the AI agents, which kind of we've answered the final point on this slide as well to a certain extent but having that strong clean foundation of data enables you to let people self serve to ask questions you know and you have an AI agent that can you know, you can query fairly easily, show me all the contracts with vendor X or show me all the contracts that are going to expire. I mean, there's more to it than that. Show me all the contracts that are PII related language in it, you know, so you can make it very easy for a wider swath of stakeholders to just self serve as well. And the summaries part, also wanted to say executives really love it as well, if I worked with a COO once they just wanted to review every vendor contract that was over a 100 K spent. He didn't want to read through the entire contract. He just wanted a quick summary that was automated, tailored to him to just tell me the three things I want to know, which one of them was price. And then he would essentially rubber stamp it, right? So just getting that sped up the process really quickly, but I think when you deliver that you want to think about the user experience as well for your stakeholder how they access the agent because if you make it be too many steps then it's easier for them to just Slack you and ask you the question and that's what you want to avoid as well. So let's move along. We'll do one question and then I'd love to jump to you Sal for your case study as well. Let's talk a bit about integrations because I think this piece it's come up. I know Simon you touched on it a little bit. Sal and Nigel you did as well. But you know your CLM system your contract data is just one subset of your total enterprise data right. There are other systems, there are other platforms, are other sources of AI extracted or manually extracted data as well. So from your perspective, I think Sal, I'll go to you first because we're going to come back to you for the case study, but what are some practical first steps that you typically recommend to people thinking about, well, you've got your data, but you need to integrate it with your CRM solutions, your sourcing tools, your enterprise management platforms and things like that. Any thoughts to share? Yeah, just two. One is actually figure out what are the data you want. I feel like too often people come to me and say, you know, We want this CLM provider. And I'm like, Great. We also want it to connect to Salesforce. Oh, they don't connect to Salesforce. What are you doing? Right? And so it's like a classic question of like, Well, what do you actually want to do? Then And it actually goes back to something Nigel brought up on entity management. Connecting data, take Salesforce, HubSpot, whatever it is, back to contract. If you're entity, the names of all the contracts, the companies you have are all messed up all over the place. It becomes really, really complicated to cross match what's in Salesforce against what's in your ERP or wherever else it might sit. That's actually one of the practical first steps, is always figure out what are the normalization, as Simon talked about, across these systems, and it makes it just way easier to get all that data to connect. Yeah, I like that. Nigel Nigel, anything you want to add on No. To No. I fully agree with with, you know, Sally, your point on sort of, you know, using entity management as like an example. And to that end, just I'd say the most practical, probably, first step is is standardizing kind of your core data model before you integrate anything. Right? Because, like, integrations don't fix messy data. Like, they amplify it. So, you know, at a minimum, just start by aligning on, like, a small set of foundational fields that, like, every system, you know, can reliably consume, you know, whether that's counterparty name, contract value, whatever whatever it can be. And and realizing, right, those are also hard data points to capture. And then, you know, you can maybe be presented in the position where, like, you know, for using counterparty name, like, let's say your master data doesn't have sort of a clean data model, but, you know, you needed a counterparty name and a contract regardless, like, you know, how are you gonna reconcile that in the short term and just having a plan to sort of then deal with that reconciliation that will need to happen sort of in the long term is important. Yeah. Just I'd say standardized in the first instance, the core model and yeah. Now I'll close this particular question off with my 2¢ off. I'm going to steal from you a little bit Nigel, sometimes less is more and Excel download and upload can be just the trick, you know, because integrations obviously sometimes you have out of the box integrations, they're really easy to set up and sometimes what you need is a bit more complicated and it might require a custom purpose built integration. But if you can bypass all of that with just, you know, go into the system A, download my data and then upload it into system B or maybe with some very light hopefully excel driven cleanup for organization. That can be another great way to integrate your data. Yes with the manual step but it's fast in the sense that you can start doing it right now versus you know, trying to build an integration and QC it and test it and deal with updates and things like that. But it only works if depending on your use case, of course. If it's fairly straightforward and you're just copy pasting, it's usually easy enough to point at someone and say you're the copypaster at the end of every meeting. Yes, yes. Well Sal, I know before we jump into your case study so to speak, know, I think the final section guys is that the four of us want to talk about I think where we each see kind of the next five years going with contract data, data, things that maybe you should prepare for now or things that you potentially can and should be able to do in the future as well, even though you can't right now. So before we get into those questions and those talking points, in the time we have left. Sal, if you would take the next five minutes, share with us your case study about AI and contract data. Sure. So, I thought I would just tell a story about that's pretty consistent across my customers, which is how do you start and then operationalize this in a pretty simple way. You've heard Nigel and Simon talk about getting the foundation right, starting with the basics, and I think the key thing on that is time and maturity is important. You don't want to jump all the way to the full agentic AI doing everything if you haven't even figured out where your contracts you want to start with wherever you are is perfectly fine, and that's the starting point. For a lot of customers, they come to me and they've heard all the horror stories. I think it's important to start by evaluating the elephant in the room, so to speak. Gartner talks about 50% of CLM implementations daily. World Commerce and Contracting says that 9% of annual revenue is poor contract management. You talk about the chaos of contracts. I know lots of people on this webinar right now deal with this all the time, which is you can't find a contract that supposedly exists. It's in a repository somewhere and the chaos of trying to figure out where that is. And then you start to layer in this new world of AI and you're like, okay, well, what does that mean? Is it a solve? Is it not a solve? Nigel talked about that a little bit. But starting understanding that none of this is exactly perfect and it's going to take some time to work through it is important. Then thinking through the end state is where we always begin. And so how do you do that? Well, I always try to come at it from a first principles perspective and figure out what you need. So a customer comes to me and I ask them, what is the thing you're trying to achieve? And for a lot of my customers, it's actually just reducing the workload of legal so they can focus on what's strategic. Right? And a CLM is actually really helpful for that because especially with when you layer AI in the proper way, you can remove a lot of administrative questions that answering all these things that you get every day by using software in a really helpful manner, Right? And so we always start by thinking about that end state, but then we always talk about people, AI and business now. Right? And those are different things. What do people need? Right? So HR might want employment agreements, sales might want renewal terms. The AI, the formatting of your contracts, as we talked about, the data in it, how it processes it for proper output is also important, how you think about that. And then what does the business actually care about? What is important to the business? And so you have to think about those things when you start operationalizing your CLM and your AI and contract management so that you can get the best out of these tools and you can avoid being part of those horror stories of 50% failure rates. So personally, in my consulting, I always use this framework that I call life, which is leverage, incentive, friction, ego. And why do I use that? Well, too often, when people or organizations are doing this, they focus on one user instead of scale. And they focus on fixing one user's, one lawyer's day, instead of how are we going to scale this across the entire organization. So thinking about leverage is really important. The second thing is, if look at incentives, incentives drive a lot of what you do, both personal incentives and business incentives. So if you don't think about that in how you're setting out your process, you're gonna really struggle. Friction. Now, one side of it is a lot of people want to reduce all friction. Right? If you have too much friction, Nigel talked about intake forms. That's notorious in CLM. Right? Getting salespeople to fill out a 100 different things in their intake form and it just doesn't happen. So you want to reduce that friction, but what's interesting is that you all know the adoption cycle. And on one side you have innovators and on the other side you have laggards, but actually optimizing a little bit towards the laggards can be really beneficial to your business because you can work through the process of what matters and reduce risk because you don't want just salespeople being able to execute contracts everywhere, but you also want them to be able to move faster. So friction is an interesting one. And then ego. What do I talk about ego? Well, ego is important. Think about, you know, lawyers. Right? We love to joke around lawyers think they're the best at everything. Right? And oftentimes, if you come to them and you're saying we're reducing your work, we're taking things away from you, that ego gets involved, right? And so you have to think about how do you get the people involved in the process to buy in. And that's why I talk about this life framework because I think it really works well. And so what we did with our customer was we went through this entire process, we figured out what mattered, and the outcome from it was that by operationalizing all these parts and pieces, we got to reduce a lot of the administrative stack from legal. Instead of 200 emails a day about this renewal contract or that renewal contract, you could use a tool like PropLab, as Simon said. You can have salespeople be able to ask questions. What does that do? It's real hours, everybody. It's significant amounts of time on your plate, hundreds of hours a year that you no longer have to do answering basic questions. Right? And so for me, that's really important. So legal, thinking back to being strategic and benefiting the business in a proper way, and for the business, they got velocity. They got faster sales cycles. Finance got better information on terms. It made a huge difference. And so us, that's how we always go through this process from beginning to end to operationalize this in a way that's beneficial to everybody. No, I love that style. What really struck out to me was that, you know, when I'm doing my legal job, right, reviewing and redlining a contract, for example, I'm in my flow state and breaking that to go and answer simple questions that come in via chat or via email that an AI agent could handle for me, maybe not directly as an autonomous agent, but even as just a chat tool that is accessible to the sales team, is a huge time saver because it's not just the time that is saved that I would not have spent but it's also the time that would take me to ramp back up into a flow mode to get back to where I was before I was interrupted. So yes, yes, I am a big fan of that type of stuff as well. But thank you for sharing it and before I move on Nigel or Simon any observations or thoughts you want to share about SAL's kind of case study as well? Mean, I think what we've heard from both Sal and Nigel today is work out what you're going to do, don't boil the ocean, get something in place that achieves a goal that impacts the broader business, don't try and boil the ocean. I have fantastic advice from both of these guys today. Excellent, excellent. Well, let's talk a bit about the future in the last, I guess two minutes that we've had, we have now on this session as well. One of the things that we are seeing now is kind of more predictive analytics for AI, Where you think about supply chain management shipping where they're using AI to predict bottlenecks and predict where there might be, know, let's call it traffic jams, so to speak, and then recommending human intervention or taking steps and things like that. It feels a bit a bit big brother ish, but are we what do you guys think? I guess, Sal, let me go back to you since you were just talking about this as well, but what are you seeing the future of these kind of AI predictive analytics for using contract data and stuff like that? Yeah, mean I think this world of so there's big AI, right? We don't have to get into the whole AI thing, but there's subsets within this AI sphere, right? We've seen a lot of degenerative AI stuff, but the predictive modeling is really taking data and understanding and getting insights from it, And this goes back to the post obligation stuff a lot, which is, you know, I'm seeing a lot of use cases where they're getting insights into other organizations that might want their product. They're seeing where they might be able to negotiate to get better terms. They're starting to see things like, okay, well, if we track, if we improve velocity on X, Y, Z signature or post obligation, we actually generate significant more revenue. It's giving them insights that they just couldn't before. I also think the other interesting thing that I'm starting to see is this whole idea of agents talking to agents, structured contracts that see other structured contracts. Again, guardrails and autonomy, you're reducing that first read for a lawyer or a legal team. I think it's an interesting place of where a lot of this is going. Yeah. No. No. Definitely. And I know we're out of time, so I'll close with I think with AI predictive analytics, you know, you can also be thinking about in the future as you track stuff analytics around your rev gen contracts, you know, what contracts are more likely to close in this quarter based on trends from your data in the past and what's actually in that contract, know, and same thing for vendors Well, so I think that that is a huge piece that there's a lot of speculation on. And I think it's very, very possible. And that's exactly what we'll see in the future as well. Then there's simpler stuff like just reallocating resources based on reviews and stuff like that. So with that, thank you. If you want to learn more about what we do to solve it at Agiloft as well, please use a QR code and chat with us. But also thank you Nigel, Sal, Simon for joining us today. Please, you know, everyone follow Nigel and Sal on LinkedIn if you have questions you want to ask them. I know their preferred time is to get messages at about three a. M. Eastern Standard Time. Oh, too. Oh, how can one be assured that AI is accurate? Oh, the answer is you can't. But I think what it is, is that it's just like with humans, Will it be 100% accurate? Not always. How you can assure that at least is look at the actual documents that you're applying AI to get the best output. If you have, you know, handwritten text and poor scans, then that quality will translate to your AI output. So I think that's the first step. The other step is actually going back to what Nigel mentioned. What you want really is controlled output and specific answers and you have to plan and build for that and train for that as well. And I know that's a very short answer to a very elaborate question, but AI has also advanced a lot compared to six, seven years ago when I was using it for AI extraction for, you know, M and A due diligence. Yeah. But now let me let let me add one other short pithy thing to that. Ask yourself, how can you be sure you get a 100% accuracy? Ask yourself if you're asking a question that lends itself to 100% accuracy. So if you ask a question like, does this contract, I don't know, include a force majeure phrase, you can be pretty damn sure you're going to get 100% accuracy. If you ask it, is this a risky contract? I don't like your odds, right? So remember it's a closed system, so the more closed your question, the likelihood is you're going to get 100% accuracy. That is very deep. I love it. Thank you, Simon. Well, let's close on that because I can't top that. So these are your panelists. Thank you for joining us and live long and prosper. Make it so number one. Bye everyone. Thank you. Thank you guys.