Name: Bootcamp Module 5: Negotiating contracts to buy services with deliverables
Uploaded: 2025-09-18T17:18:13.530Z
Duration: 58 min 20 s
Description: Bootcamp Module 5: Negotiating contracts to buy services with deliverables

Transcript for "Bootcamp Module 5: Negotiating contracts to buy services with deliverables": Hi, everyone. Welcome to the webinar. We are here so excited to be sharing with you module five of the vendor contracts boot camp training series. Now this whole set of modules, we've gone one, two, three, four, five, and we're really focused on vendor contracts. And we're focused on helping people learn a lot of the fundamentals about how you do vendor contracts in the real world. So it's not focused on kind of academic process or back office functionality, but, really, what you need to do when you're you're talking about contracts and you're negotiating contracts, what kinds of issues do you need to know. And we've gone through a lot of different subjects over these five modules, but I'm very excited about today because I think it's it's one of the most interesting types of vendor contracts. And that is when you're negotiating contracts to buy services with deliverables. We're gonna talk about how that's a little bit different from some of the other types of vendor contracts, what things you need to know, what are the priorities, where should you spend your time. And I'm so thrilled, to be able to kick that off. First, I just wanna give a great thank you to Agiloft for sponsoring this series. I've had so much fun over the last six months putting these on, working with Agiloft, getting to know their team. They're really it's a fantastic organization, and I hear so many great things about their products. I know a lot of the Agiloft folks, and I know a lot of Agiloft users. So I really wanna give them a shout out of just for this contribution to the contracts community and supporting this, training and helping people get better at vendor contracts. So thank you to Adloft. So with that, I wanna introduce our speakers today. We have two amazing women that I've known really, I think, since I first started getting online, in the early days. They've both been contracts con speakers, my annual conference. So I'm thrilled that they're joining us today. And I'm gonna start with you, Michelle Fleming. It's blah. All of a sudden, I was like, wait. Michelle Fleming. I mean, blah. I know. I'm like, turn it over. So if you can tell us about yourself, tell the audience about what you do. Yeah. I'm Michelle Fleming. I am so excited to be here. The how to contract audience is always great, and I do a lot of contracts, that have both services and deliverables. So I think I've got, some some personal experience that is probably gonna be irrelevant, and I just really look forward to the conversation. And I think one of the things that's really cool about your experience is you work in a for a vendor that does a lot of services and deliverables. Is and if you wanna tell about your role there. Yeah. So I'm the only in house attorney, actually. So I do all kinds of contracts, but our main role is providing IT managed services, generally services, but they also have specific, deliverables that can be associated with those deliverables. Yeah. And and Michelle spoke about services at this year's contract Con, about master service agreements. So, I think of Michelle as one of my best experts on services. Another fantastic expert who has also spoken at Con events is Jennifer Chung. Hey, Jennifer. How are you? Hi, Laura. I have I think you understate, like, how long we've known each other. I have literally been obsessing and following you since, like, the first days of how to contract. I'm it it's so amazing that it's been, like, five years that we've known each other now. Back in the days of the pandemic, a lot of us went on LinkedIn and talked, and we found this community of people who are love to nerd out about contracts. So Jennifer was one of the early nerds in that community. So, yeah, I'd love to hear more, or share with the audience about your role and your work with vendor contracts. So I'm currently VP, counsel at Simon and Schuster, which is a book publishing company. My remit my formal remit here is to support international operations, logistics, audiobooks, and I've been doing a lot to support, our IT team and our, language app team. And so there's just been a lot of opportunities to work with third party vendors because there's a lot that we need to get done here that we don't have the in house capacity for, so we will have to go outside for it. And then over my career, I've worked in a variety of organizations that will engage a lot with vendors. And so, like, you know, just at the just to preface, like, my comments today, it's it's from my own experience, not, you know, on behalf of the company or anything like that. Absolutely. Absolutely. And I'm sure and the same for Michelle as well that we're all here, sharing our expertise. So with that, I'm gonna kick off the slide deck. And the way this webinar is formatted or or planned is it's broken into four parts. And so I treat each part as a mini segment, And I'll go through for each of the four parts and explain or provide some explanation of the the foundational things to know about the subject, the things that I think are most important for people to understand. And then we'll go to some questions, and ask Jennifer and Michelle. So let me kick off with the first part of the webinar. But before that, let me just kind of preface what we're talking about, which is when you're talking about physical goods and digital products, you're buying something that already exists for the most part. And so you can look at it. You can touch it if it's physical. You can evaluate it into a trial if it's, digital, but it typically is something that's mostly already in existence. Now when we're buying services with deliverables, those typically are gonna be more skill based services, and we're buying the services to create something from those services. And so this typically isn't something that's exist. It isn't something you can go look at and touch and feel and test. These are gonna be new things. So it feels like sometimes when you do them that you're just buying something and hoping for the best. And that's, of course, where the contracts come in. That we we hope that by creating really good contracts, really good statements of work, and services agreements that we're gonna do better than just hope for the best. We're actually gonna, set up an a framework and structure to achieve our goals. But that's hard because there are so many moving targets and moving pieces when it comes to services agreements. These are very human endeavors, very human projects. So we typically have a lot of variation. Sometimes the people don't perform as you'd expect. Sometimes those deliverables will change over time as they get created. You might have schedules get extended, and the general scope and and the work you want done can change. That's why this is such an interesting topic, at least to me. I you know, who wants to work on stuff that's all boring and the same? So the agenda today and the four topics we're gonna cover are deliverables and scope, IP rights and work product, resources, meaning people or other resources and performance, and then risk and liability. Oops. Featured speakers. I skipped one too fast. We've already done the introductions, but very excited to have, the have these ladies with me today. So kickoff with part one, deliverables and scope definitions. The thing about that I think about when I'm talking about scope for and and the definition of deliverables and what you're asking people to perform is you really aren't hiring people to just spin their wheels. So if you hire someone for an hourly rate, you are asking them just to put in the time. Now I don't know about you, but I could sit here all day and kind of work at something and get zero done. I'm very good at that. So what we're trying to do with our services agreements with our SOWs is make sure that whatever they're spending their service time on is creating something that we actually need as the customers. We aren't just hiring them to put in hours in this category of of service contracts with deliverables. We're actually asking them to create an output. And that output is so critical for us. And trying to define that output and make sure that output matches our business problem, our the solution that we need to solve our business problem as customers, that's really the most important thing to think about. And I frame it that way, and I always want you to think of it that way, which is really when you're buying services with deliverables, you're buying an output solution, not just a report, not just a program. You're buying a program that's gonna solve this business problem. That's why you're spending the money that way. And so how do we define our deliverables? How are we defining that output from the services? And I think of these as the four main ways to do it. And I'm I'm not gonna read from the slide. I'll I'll just dive into each one. So the first one is what I would call the functional requirements. What is it that you're asking someone to do with the services? Again, this is even before we get to the output. The key here is not focus on just tasks. I see that with a lot of SOWs where people are really caught up in a list of activities. What I think is a better approach is when you take that focus on it on the tax, but you always are tying it back to that output that is self providing a solution that you're trying to solve. Why are you spending the money on this thing? Typically, it's to get this deliverable that's gonna solve this problem, accomplish this goal, address this risk, whatever that reason is. So the tasks have to be written in a way that ties it to creation of, deliverable that addresses that business need. So in this case, you know, the example I'm using is a marketing strategy. So they're going to identify customer segments. They're going to recommend channel strategies and provide measurable tactics. All of these are driving towards a deliverable that's gonna meet a goal for the business. So the second part is technical specifications. Exactly how do we want it built? And this focuses on how to build it because what we don't want them to do is to build things that aren't useful for, again, that end goal of the deliverable, me solving the problem. So if I'm hiring someone to do this marketing campaign and they spend their whole time focused on my website instead of trying to develop new leads for new customers, well, they may have performed a lot of tasks, and they may end up with a marketing report, but it's not gonna be the kinds of tasks that matter to me because it doesn't focus on the kinds of things that that I want to address. So talking about how you're going to perform those services and defining that in in your SOW is gonna be very important. We're also looking at acceptance criteria. These are so critical because at the end of the day, after performing these services, they're gonna have some output. And you wanna make sure that output is solving the problem that you're you hired them to solve. And the acceptance criteria is in a sense where you say, what is the solution that will meet your requirements? And having acceptance criteria laid out is so important. Now there's one issue that comes up a lot, which is this idea of objective criteria. Generally, best practice is to have very objective criteria. Make sure parties agree upfront. What is the solution the vendor's building, and what is the standard by which the customer is gonna use to say, yes, that we're gonna finish paying you for it. That meets our needs. We accept. Generally, that's great for avoiding conflict in the future, for, making sure everybody's on the same page. There's really nothing but upside generally. But I do wanna add one caveat since we're talking about procurement supply chain and what's best for customers is sometimes customers benefit from a more subjective test. That if I'm a customer, I love having no acceptance criteria, and it's if I like it, I will accept it. Now this doesn't work in a lot of situations because you have parties that have equal leverage. You have a risk of people creating things that aren't going to end up where you want it to be. But in some cases, being a vendor or being the customer, you wanna have a lot of flexibility to be able to say, you know what? I can't tell you whether this is an innovative artistic graphic design. I need to be able to you know, I can't give you an objective standard. I just need it to fit our brand or whatever it is. So just something to think about. Again, generally, objective is is gonna be better, but there are cases where you might want a more subjective version. And then in delivery format, agreeing upfront what is it exactly that they're going to deliver to you. Is it a report? Is it digital files? What's the format? All of those kinds of things can prevent headaches later and disputes later. So on top of being very clear about the deliverable, we have to be really clear about the scope because the risk of scope creep is real and exists all the time as I'm sure Jennifer and Michelle see on a regular basis. And scope creep is essentially, you start out with a description of a scope that says you're gonna do one, two, three. And over time, you realize, you know what? Three, we don't really need that much anywhere more. Let's change it to four. And then, you know, on two, I only wanna do half of that. Let's let's cross off this other part. And so there's a lot of changes that happen because this is, again, creating something new, and you figure it out as you go along, the things it would be better if it was a little different. So having thinking about scope creep and what you can do with your definitions of deliverables and your definition of scope early on to set you up for success and make sure that you are, in the best position to deal with some of these eventualities, like this need for ongoing change. And so I think of it as you really have to create a framework for a collaboration with the vendor and between the vendor and the customer so that you are, able to make sure you're thinking about that scope creep and creating systems so that you can address that as they go. So one is that initial detailed scope, making sure you have real clarity around what it's gonna say. Also, having a clear process for change is gonna be critical. And the change process, I there's really two things here. One is that who how you request it, and how you request a change, but also how you decide the impact of that change. Is it gonna increase the the, cost of the services? Are you gonna have to cover extra materials? Is it gonna add to the schedule? All those kinds of things we're thinking about on the front end, building in that framework and processes into your SOW or your statement of work so that you can address it as you go along. Being clear on who approves what. This is an easy bottleneck to solve where every problem has to go to one person, where what we really want are especially over bigger projects is having lots of different people who are able to make decisions and have authority to approve things or keep things moving along the way, not having to be completely dependent on one person for every decision. And then finally, documentation and version control. So in addition to building a framework around preventing scope creep and managing your scope, one of the best ways that you can manage these projects is with milestones in some form, to make sure that that's appropriate for your contract. You wanna have milestones that meet how you're performing the contracts, how you're structuring it. And the reason the milestones are so important is it forces the parties to come together and check in at some point be before you get to the end of the project. Because if you get to the end of the project and you haven't had those check ins, if you haven't had an opportunity where the vendor is saying here is milestone one, The customer is looking at milestone one. Oh, yeah. That's perfect. That's just what I wanted. Or you know what? That's not quite it. Let's re refocus and channel our efforts in a different way. Because if you don't do that with milestones, you get to the end, don't have what you want, and you the vendor has spent all this time and energy and paid you're paying for all those resources, and you're not getting what I mentioned in the beginning, which is why you hired them in the first place, which is typically a deliverable that solves a business problem. So use milestones to make sure you're staying on track. It allows you to have, I mean, things like the project breakdown and being clear about deliverables for each phase, making sure that payments are tied with milestones and deliverables, and then giving opportunities to redirect, and correct things that need to be fixed. So with that, I wanna turn to Michelle. And, Michelle, as I said, you're one of my favorite speakers on services, and I'd love to hear what you think about the most common mistakes you see companies making when they're defining services and scope. Yeah. So I love everything you said, and I was just kind of nodding along because I I have seen it all, and I totally agree. And one of the biggest things that I see is just having the services and the scope be very open ended without clear metrics for success. And I think the interesting thing is that I think sometimes it starts with the best of intentions because the vendor thinks, oh, the customer wants, you know, this task. They want us to do this task. They want us to do this feature. And so they just keep doing the work, but it it doesn't work out because at the end and it's especially a danger with a services contract that is time and materials based. At the end, you've spent all this money. Maybe you've gotten gone past and not to exceed, and you haven't met, the objective. And so it's a I think it's a mutual discussion, and it's really on the vendor to say, to tell the customer, you know, what what do you want and then figure out if that's realistic and a bit of a balancing act, you know, just not to change order the customer to death. You don't want that. But at the same time, you wanna be flexible. Right? And just a simple but a very impactful way I've seen to deal with this is, in your services agreements just to change. Sometimes I'll see services include and a simple but impactful changes to say services consist of, and that helps bound it a bit, but you also wanna be flexible. Right? Yeah. For sure. And and it's so trying to figure out exactly what is in the services, especially on those time and materials basis, basis contracts can be so tricky because it's essentially you know, from a customer's perspective, it can feel like a blank check. Like, okay. You're just gonna spend a million hours, and we'll see what we get in the end. And, essentially, that's, you know, law firms, and then legal is is essentially a time and materials contract. So all the risks that a lot of us who work in contracts know that can come with out providing a lot of direction outside counsel, we have these same kind of risks with our services contracts. So our next question, Jennifer, I wanna ask you, which is this and Michelle touched on this. This idea of project flexibility and having clear scope and tip it with something that the parties are creating together in a way. The vendor's doing the work, but the customer's approving. What what are the best ways that people have or that you've seen work to balance that need for flexibility and clarity? So it's just been my experience that too often you know, and I'm speaking from the position of being legal counsel to the internal clients who are often working closest with the vendors. Right? Like, it's not typically like, other than the law firm scenario, it's not really typically the in house counsel that's negotiating the scope, negotiating, like, when the deliverables need to come in, what the objective, criterias are. And so a lot of this discussion, should assume that the client is familiar enough with what the vendor is able to do, capable of doing, and who the people are. Because, ultimately, this really is about the people relationship and the services. Just, like, briefly, like, the way I think about this as an analogy is I'm hiring a runner to run one mile. That that's that's the project. Right? But we for those of us who are runners, I'm not, but those of us who might be, you know, there's gonna be a difference between the way a marathon runner runs a mile versus an Olympic sprinter versus a very healthy and and energetic eight year old at the beginning of the day versus the end of the day. Right? And so if I hire an eight year old at the beginning of the day, you know, maybe the promise is that they can run the mile in one you know, in in eight hours. That eight hours is a very long time versus the sprinter who can do it in I don't know. What do sprints look like? Seven minutes? Right? Michelle's a runner. Yeah. Oh, so Michelle. So exactly. Right? So if I say Michelle, Michelle, I need you to run, you know, in ten minutes, you could be like, yeah. Totally doable. No problem. That's the scope. And you say to me, but don't tell me what kind of shoes to wear. Tell me the difference between a treadmill and the roadway, and what's the weather gonna look like. And what happens if I sprain my ankle the day before the project is about to start? And so if you kind of think about it in that way where you say, I'm hiring the team, the people, I am familiar enough with their capabilities, then the scoping becomes a little bit more, not easier, but clear. And I think I often see that disconnect where my internal team says, oh, yeah. We've got this, outside vendor that can do software development. They are experts in this. And then, like, as we look at the contract, it looks like they've given us the c team, not the not even the b team. They are probably six months delayed in even getting started on our project, but we need the first round of drafts, like, in in two weeks or whatever. And so it's that. It's clarifying with the internal team about whether they are familiar enough with the vendor, they know what they're getting, and what the outcome should look like. So I'm always willing to be very flexible on what the how it happens, but the when and the what ends up being probably the most critical, terms to make sure the internal team is clear on before we even get to the contract. Yeah. And I I love the way you were describing, like, what shoes should Michelle wear? Is she gonna ride on a treadmill or outside? Like, being able to have those discussions upfront will really help you make sure that everybody is kind of on the same page in terms of how this project's gonna work. Work. So let me move to and that was fantastic. I think really fleshed out some of the points that I started with and provided a lot of good context. We're gonna move to IP rights and work product, and this is you know, I'm an intellectual property nerd. I'm tech transactions trained, so this is where I'll the part I love. And I wanna take the opportunity to really talk about how we handle intellectual property and services contracts. And to do that, we have to talk about who owns stuff. Like, what are the default rules when you hire a company to build something for you, whether it's a creative work or computer code or whatever it is. And we're not gonna talk about all the Gen AI issues that come with it. Those are quite complicated, and we'll save that for another day. So we're just talking about traditional intellectual property. Somebody's creating, let's say, a creative work. When the basic default rule, if you're not an IP person or intellectual property person, is whoever creates something or invents something is the owner. That's the default rule. So if you hire a vendor to create something, the default rule, unless you follow some processes I'm gonna talk about in a second, the default rule is the vendor owns it, whatever they create. And if you, as part of the contribution to the project, create something, then you own that. So we have to go in knowing that's the default and make sure that our contracts are taking steps to change that default if we need to. If the vendor should own it, great. You know, you're not as worried about that. But if you need rights to it or you should own it, then we wanna make sure our contract is documenting that precisely. So there are two exceptions to having the vendor who performs the services for you own that output or whatever creative works they create. And one is a concept called work made for hire, and that's from the Copyright Act. And then but for both patents and copyrights as well as other, you know, trademarks and trade secrets, which we won't really get into today because those aren't as relevant to this this subject. But for patents and copyrights, assignment also works really well. So let's go through work made for hire first. There's two types of work made for hire. Some people don't think of the employee creations as work made for hire, but under the copyright act, it is. There are two types. So we're not gonna talk about employee creations. Those are default the owned by the employer. But if we talk about commissioned works and people say, oh, I'll just add a work made for hire provision in my services agreement. That's fine. No big deal. With them, we're fine. We own everything. Well, you might or you might not. And there's a couple things you're looking for. One is you have to make sure there's actually an agreement that specifically talks about that ownership that is specifically asking them to perform tasks to create something. You don't have to be super precise. You're gonna create the slide deck. You're gonna write this specific code, but you have to have a contract in writing that is commissioning them to do the work. So that's one of the biggest requirements. You don't just hire a vendor and say, oh, we own it because it's work paid for hire, but you don't have it in the con you don't have a contract or lots of other facts that can play in. But the third one is what I see a lot of people not understand, which is not all things can be work made for hire. Not all, creative works under copyright rules can be work made for hire. There are nine categories that it has to be one of those categories in order for it to be work made for hire. You I only have a few of the categories here because I I didn't wanna put all the tiny print. But just know just because you think something's work made for hire, just because you have the sense of, oh, as long as I put it in the contract and it says work made for hire, then we're gonna own it. You may not even be able to own it under the copyright. Work made for hire may not work by just saying it's work made for hire. So that is a mistake I see a lot of people make. They rely on work made for hire like it's the be all, end all of making sure you have ownership of IP, but it's not. And it's not it doesn't apply to inventions. There's a lot of limitations on it. So my advice, and I'll say it in a second, but it's really focused on the assignment part of things. I always have work made for hire as the first step because when it's work made for hire, the employer, the customer is the first owner of that and has certain better rights because of that. So you work made for hire is best, but I always say it's work made for hire. But to the extent it's not, we hereby assign or we hereby license, so we address our rights that way. Another thing with our services agreement is dealing with what people call either preexisting IP, background IP. There's lots of different ways you can frame it, and that's basically your own stuff. You come to the relationship with some of your own intellectual property, whether it's existing code, your creative works. Maybe it's some frameworks or templates you use to create something. Those are intellectual property. Somebody created these works, and we have to think about how those creative works fit into the bigger piece of services and deliverables. So, typically, when we come to these relationships, we each have some intellectual property rights in some works, and we usually keep those. We're not typically assigning all of our IP as part of a all of our background or preexisting IP as part of a services contract. The harder part is dealing with what rights who's gonna own everything that's getting created. And this, the answer to this is very dependent on the nature of the vendor, the nature of the work, how much is being paid, what are the what are the parties coming together to do. If I'm hiring you to custom create some artwork, well, I may need to own that. And I because I wanna be able to sell it or incorporate in my product, and I want more control. Or if I'm hiring you to do artwork, maybe I just need a license because the only thing I'm gonna do is show it in an advertising campaign for a couple weeks, then I'll probably never use it again. So I don't really care if I own it or not. We're thinking about how much we care, how much we need to own. It's a common mistake, I think, as people put way too much emphasis on ownership of IP rights when licensing those IP rights is often good enough. And that's very much the case when we're talking about services agreements with deliverables. If you are not hiring someone to create IP for you, you're just getting a report, and may you don't need all the systems and programs and, you know, chat bots or whatever they're using to create the report. You don't need to own all that. You just need to have the report, be able to use the report as you want. So you're focusing more on those rights rather than on ownership. No easy no quick, answer here. There's not one right way to do it and one wrong way. This is also an area where you really wanna be careful. If you don't have that expertise in contract or in intellectual property, make sure you're working with somebody who does because these things are really easy to mess up. And that's why you're I I'll keep coming back to this idea that I started with, which is you are hiring services to accomplish a goal, and you are hiring services to create an output that's gonna solve a problem. And if you focus on what rights need to happen, who needs rights to do different things to achieve that goal, That helps provide guidance on some of these kinds of issues. So one thing you're thinking about is what if the vendor is improving my my core software program? They come in, and they're making all these changes to it. Who's gonna own that? Who's gonna have rights to use it? Do you want your vendor to be able to take those improvements even if they don't own them and use them to benefit competitors? So you're thinking about those kinds of things. Also, be aware of this concept of a grant pack license. This is a concept where I build something. Let's say I'm the vendor. I build something for you, the customer, and our contract says, you, the customer, own it from the moment of creation. Well, the challenge is I can't use that intellectual property because now the customer owns it unless I've been given a right to do so. Because whoever owns a copyright has the right to authorize other people to use things. So it's really critical that we make sure we include grant back licenses, which is basically when somebody else is getting ownership in something along the way that you wanna make sure you're giving that person the right to keep using that intellectual property during the contract to perform the the work and finish it out. So this and then also this idea of licensed IP in different ways. If you they have rights, if they have ownership, how can they use it? So I'll go through quickly some of these mistakes I see. One is this concept of overreliance on work work made for hire. Always include assignment as a backup. Never ever just say work made for hire. I never I don't think I have a contract ever that's just had that. It always has assignment two. Be careful about vague ownerships. Parties will discuss, will determine later, all those kinds of things. You wanna watch and try and get indemnities and warranties about your in house property. If it's a really important part of it or there's a risk there, you wanna get those. And then make sure that you're addressing how you're dealing with third party licensed content, meaning content that is either licensed by the vendor for the benefit of you as part of the deliverable or that the vendor has, and it may be this incorporating into the deliverable, or open source software and making sure that you're not ending up in violation of those, terms of use or terms of service for those open source programs. Okay. So that's my IP, section. And with that, I wanna turn to Michelle and ask you about the kinds of IP ownership issues that you see come up most often in your services agreements. Yeah. So one of the biggest issues I see is that, customers might think because they're paying for something that they automatically own it, but they're not taking into account that the vendor might be, providing commercially generally available configurations or services that they provide to, other clients. And from the client perspective, you really want if the vendor is providing you something that is unique to your business or unique to your operations, then that should be owned by you. Right? Because that gives you a competitive advantage or at a minimum you want, a license to continue using that. And then I really loved what you're saying just about the the work for hire because one of the biggest issues that I've seen comes back to not understanding those I think it's like is it nine or six categories or things in the work for hire? Not knowing what those are, and it really comes up especially in software services contracts because software is not one of those categories that's assigned under a work for hire provision. So I I really I completely agree. I was modeling along with what you were saying about including that, assignment language, in there and just being mindful of it. Yeah. And it's that decision of whether you need to own or license is something a lot of folks get confused by. Or, you know, I think if you don't understand some of the economics of the deal, they can just have an instinctive thing. They just wanna own everything. But, often, what I do is I will give up ownership to get better terms elsewhere in my contract as long as I have really solid licensing terms and make sure my license covers everything I need. Because one other thing that people should know is if your counterparty declares people think, well, I need to own it for security or you know, so they can't go away. But if under bankruptcy code in The US, we continue to have that license post bankruptcy. We're not gonna lose that later on unless there's some kind of restriction or we breach the license. So licenses are very powerful and give us the rights often that we need without having ownership. So that's at least a negotiation strategy I like to use, especially with people who don't appreciate how useful and and how it's often enough just to have those licenses. So, Jennifer, let me ask you about misunderstandings. And I talked about a few of them about IP and work products and deliverables. What do you see out there on those? I I think it's treating IP as, like, a one size bucket that it's gonna show up all by itself in, like, a really perfectly crafted IP term and that you might actually find bits and pieces of the implications of an IP assignment or license in other places. And I think I agree that it is definitely one of those areas that if you don't have comfort and fluency in, it is worth a little extra attention to. And so I might even see it literally come up in, can we use each other's trademarks for marketing purposes. And I'm not sure if that's always gonna be okay because you might not want people to know that you're using this outside vendor. Like, that could actually be part of your business strategy that you don't want people to know that. The other issue where another place where it comes up that I've seen is how you set up your definitions around affiliates, owners, and, like, the the the the sort of the cohort of organizations that can actually use that license or the IP that's involved. If it's an existential product you're creating through this vendor, you might want to make sure that all the underlying licenses can be assignable or transferable without a lot of hoops, especially if you're in an organization where there's a high likelihood of some kind of an exit, some kind of spin off, some kind of a merger. You wanna make this part as easy as possible. Look. If if you haven't been thinking about it, it's fine, but there's a lot of very highly paid m and a lawyers out there who will fix this for you. But it is, like, one of those things that you can really add value upfront to think about, in negotiating the IP components to your agreements. Absolutely. Very true. Okay. So let's move on to part three. This is a little bit of a shorter section, because I wanna make sure we have time for the end, which is resources and performance and making sure we have, this handled. Because at the end of the day, service quality really does depend on people. And you're looking at the specific people who are performing the services. You're looking at their skill levels. You're looking at this competing interest by the vendor for their best people, and maybe they wanna have them on a different project, not on your project, and also thinking about what happens when those people leave and they bring all that knowledge that they use or developed with them. So when we're looking at services, agreements with deliverables, we're thinking about, do we wanna try and lock in some of the key personnel? Is there anybody who is critical to the project that we wanna make sure is named in the the SOW where we actually impose some kinds of requirements like minimum time commitments or transition periods, or if they leave that we get somebody at least as good and put some of those parameters in our SOW. We also are looking at how the vendor is managing their third party providers because that's another variable for the service quality. If they're heavily dependent on contractors and they're not sourcing those contracts or managing those contractors properly, that can have a negative impact on the quality. And then we're also focusing on structured progress monitoring. By that, I mean, having a framework, making sure you don't just kind of casually once in a while, like, hey. How's Bob doing? You're really thinking about it, systematically so that you're checking in. And, you know, an example is really heading on the project, a weekly report, a monthly report, a quarterly report, and making sure that you have a framework for knowing when there's problems and you're able to address those. So I wanna get to you, Michelle, on this one is what's your what's your best approach? Because I know you deal heavily with performance and quality of the personnel in the tasks that they do. What's your, best strategy for that? Yeah. I've seen, a tier structure approach to it. Right? Because if you have, for example, a a person who is an assigned account representative, so the client might have gotten to know that person, even interviewed that person, knows their skills and qualifications. And that's kind of a key person, right, overseeing the project. So for that person, you might not want them assigned to other accounts, in which case the pricing is probably gonna take that into account. Or you just want that person, to be the only person managing your account. And then the next tier I sometimes see is where you have roles, which have specific skills and qualifications assigned to it, but not necessarily a name. So you've got some flexibility there, to reassign different personnel. And then the other category is just, general personnel where so long as they're, you know, performing in a professional manner that the vendor has the right to, reassign and performance manage those as they need. And I think the customer doesn't want too much control over, the the different personnel that are assigned to the services because you wanna be sure that the services are not disruptive. For example, you know, people people leave, people get promoted, people change departments. And so you do wanna give the vendor the right to, you know, manage the personnel, as they need and continue to provide you services in a way that's, continuity continuous. Is that what you're saying? Continuous. Continuous. Continuous. Continuous. I need more coffee. Continuous. I've got some peppermint tea here, but continuous, while still, you know, maintaining that, those key personnel. So that's, that's an approach I've seen. Yeah. I I like that a lot. And so, Jennifer, what do you see as for performance monitoring? Because to me, this is almost one of the hardest things when it comes to these services contracts is how we have those milestones, but then we really should be checking in and monitoring all along the way. What kinds of things do you see work for for doing that? This is definitely one of those areas where it's very easy to over contract. And when you over contract performance monitoring, all you're doing is adding extra burden, probably even on the legal department because it's gonna be so easy for the client to come back and say, is there a breach? Like, do we need to do something? It's probably a better practice depending on the service, depending on the vendor, depending on, like, the team you're getting. In addition to making sure you know who the personnel are is to have some framework for timing. Right? So if you know that, I don't know, the output has to be, a a 60 page document. Maybe you want to see an early draft at some midway point because then you know that you're gonna get that 60 page document, hopefully, eventually, but to track based on what the output is supposed to look like. But to have something quantitative, time, you know, time specific, I think that that's probably the the easiest way to frame it out without more details about, like, what the service is going to be. Yeah. And even having the conversations upfront of how are we gonna be monitoring this. And but I totally agree with you on the over contracting as being a danger, creating too much detail, too much process, and relationship management. People think it's a good thing. But in if in the real world, it's it's often not, and it's just creating extra work for people so they can't actually do the tasks that they that we're paying them to do. They're spending so much time on the administrative stuff. So let's jump into our last topic, which is really, you know, the one a lot of us care about the most and are really focused on, which is the risks and liabilities of these relationships. And these kinds of service contracts can create a lot of different kinds of risk. So one is just business damages. If you have someone who is performing services and they do things or don't do things, and then liability results, whether it's messing up a system or, you know, damaging somebody's reputation or whatever it can be. There because these are humans, because humans make mistakes and don't always act, in the best way, these things can happen. So we have to be worried about the kind of business damages. We're also worried about IP infringement, and that's a big risk when it's not our own employees who are doing the work. I mean, it's a risk even with our own employees, but the risk goes up significantly when these services are being provided by people that aren't under our control. We're also thinking about damages caused by the vendor. So if they're driving the car while performing the services on your behalf, if their people are on your site and end up hurting somebody else, or there's just so many different variations. So people focus a lot on the IP infringement indemnity, but we also have to be thinking about other kinds of claims that could be brought against us because of something our vendor did. And then finally, the big one these days is is about data security and making sure that those services providers have sufficient, frameworks and security protocols in place that you are not adding extra risk by engaging them. So I wanna go through these four main areas for risk and liability and talk about the two things relating to them. One is and I'll for each of these, I wanna just start with what customers want because we're focused on vendor contracts here and what we, as supply chain, are thinking about. So if you are a customer and you're buying from a a buying services with deliverables from a vendor, in your ideal world, in your best scenario, you have a vendor who's gonna cover all damages that they are directly causing. You're gonna have really generous caps so that you're gonna be able to recover that those damages, and you're gonna have carve outs only for the really, really bad stuff that they might do. Or, the really, really bad stuff might be, excluded from your own, behavior or only related to that behavior. But the reality is that's not what most people end up with. So I think what we typically see where it comes out is things like caps at fees paid or fees paid over the twelve months. Really depends on the nature of the contract, but we typically see limits of liability somewhere in there if you can get it. Some vendors like to do, caps tied to individual statements of work. That typically creates a smaller limit of liability for the vendor than if you have it all statements of works being performed. You can also use a time period to measure it. There's lots of different ways, but you wanna be typically, where companies end up is having something tied to that. You also don't get you might have these carve outs, but they might just be limited, the vendor carve outs for gross negligence and wealth misconduct, and both parties are waiving consequential damages. So that's kind of the standard, services agreement limited liability. So then we get to indemnification. And indemnification, what customers want ideally is our vendors responsible for everything that they cause no matter what. And they're gonna step up and defend those claims because we didn't do it. It's the vendor's fault. They caused this third party claim. They're the ones who be should be stepping up to defend it. If they give me IP and it's infringing, they should be the one, in defending that as well and in in paying any damages I have to pay, and they're gonna cover all the legal costs. So this is the best case scenario. I don't know about you too, but I don't know that I get this very often to get everything we want on these things. So where we often have to end up is indemnity, in some cases, is gonna be much narrower and limited to IP infringement and some acts, by the vendor, particularly the bad acts or and it depends on your leverage and how many acts you can get in, you know, whether it's just certain kinds of breaches, if it's any breach of the agreement, whether it's just certain kinds of behavior like gross negligence or is it any negligence? There's a lot of different ways that we this gets structured. Also looking at carve outs, vendors are gonna expect carve outs if the if the customer is contributing to the third party claim and has, is partly responsible for it, that vendor isn't gonna wanna step up and cover everything. For the lawyers in the group, this is that comparative, negligence kind of thing that we all learned in law school and and try to quickly forget. But it comes up here in sense of how much should the vendor cover if the customer was, involved in causing that third party damage. And then insurance requirements. And, again, customers, ideally, we want everything. We want have liability through insurance liability coverage through insurance that's really gonna protect us and make us whole. And we want access to all the vendor's policies, and we want guaranteed coverage for the whole thing. So if this is my dream contract, these are my dream provisions for insurance, but the reality is closer to industry standard numbers. I think that's where most service contracts end up. There's some variation depending on the type and the industry and the nature of the services and the size of the deal, but often people pick pick random numbers, like 1,000,000, 2,000,000, 5,000,000, whatever it's gonna be, as the the general liability minimum. Customers don't get access to all of the vendor's insurance policy benefits, but they might get access as an an initial insured on the general liability policy only or maybe a automobile liability or automobile policy, but they can't get everything. And then a certificate of insurance instead of a guarantee of always having this level of insurance. And, again, individual, relationships, it depends on all these things. So, there isn't any rule, but I think being realistic about what we want and the differ and the delta and the difference between what we want and what we're what's actually standard to get is really important so that we go into negotiations with the mindset not of give us everything, give us everything, give us everything, but more of a balancing based on appropriate risk allocation and economic interest in this transaction. And then finally, data security and confidentiality. You know, this is also changes in terms of the customers would love really strict standards and vendor liability for everything and immediate notification, but the reality is that we end up with just using industry standard security requirements, shared responsibility to a certain extent, and reasonable notification. So keeping very realistic. So let me ask you, Michelle, on these issues, what do you see in terms of this kind of risk allocation liability limits, in the contracts that you are working on or or that come across your desk? Yeah. So I see, both parties, both the customer and the vendor taking, like, very extreme positions. It seems like everybody takes the extreme position. Now if you're a customer and you're negotiating a vendor contract, you might see that the vendor is trying to do a mutual cap on liability. Like, I do it I do it myself. They might say, like, twelve months fees paid and payable. But contract obligations are not symmetrical. And I never say never, but almost never, the contract obligations are not symmetrical. So if you take a look at how you as the customer might breach a contract and what is the exposure associated with that, a lot of times your main obligation is to make a payment on time or respond to requests in a timely manner, versus the vendor. They might be in your system. They might be doing security work. And if there's a breach on the vendor end, that exposure is gonna be much, much higher, than that. So that's just some things that I see. Yeah. No. I I think that makes sense. And I and that extreme position, it's kind of a darn or damned if you do, damned if you don't situation. Because if you don't put it in as an extreme in your form or in your first draft and then you start negotiating, a lot of people wanna come to the middle. And if you start out fifty fifty, they're gonna push further to the end. So it's it's a really hard, balancing act to to do. Yeah. And if, just real quick, sir, if you're the customer and you're negotiating with the vendor, you might think, oh, you're the vendor. You should stand behind your services, stand behind your, product, but you need to realize that there's, third party actions that could happen that are outside the vendor's control. Just for example, like cybersecurity. Maybe the vendor has a security policy. It's in the contract. They met every single requirement, but there are some malicious third party actor and they got into the system. And so you need to take a look at that and realize if you're asking for a higher cap or no cap, then they might need to get something like catastrophic risk insurance and it will be priced accordingly. So I really think, like, you just need to do a deep dive until, you know, what are what are the real risks of the situation and the real potential breaches in the financial explosion. Realize it's not symmetrical. Yeah. Absolutely. And, Jennifer, so what, in terms of balancing these risks, what are the kind of strategies that you think work best, for all these issues? Yeah. Yeah. You gotta really think about what you're actually buying and what the team actually needs. And so something like, oh, a look back of twelve months to cap, you know, cap damages. If it's a free demo, that's not gonna be enough. So you've gotta really think about what's gonna happen, and maybe you just don't hand over existential PII, as part of the demo so that you don't have to even worry about that breach. And the other, thought that I have is look really carefully at how the reps and warrants are being negotiated. The reps and warrants are gonna tell you actually how risk averse or how risk focused you need to be with this particular vendor. If they're making if they're willing to make the appropriate reps and warrants, then you you might be okay letting go a little bit with some of these liability productions. Yeah. And and it's just so hard to speak generally about these things because it is so dependent on the specifics of the deal. And so with that, we are at the, let's see, end of the webinar and so excited. I'm so glad we covered all this great information. Thank you, Michelle and Jennifer, for being here and sharing your expertise. Thanks again to Agiloft. It's been a fantastic series. I really enjoyed it, and so grateful for their support. So and thanks to all of you for tuning in today. And I think Courtney said in the comments, you can, get access to the recording and the and the slide deck on the AgileF site, and enjoy. So thanks again, everybody. Have a great day. Thank you. Bye.