Name: Bootcamp Module 4: Drafting Contracts to Buy Digital Products
Uploaded: 2025-08-14T17:31:21.355Z
Duration: 1 h 30 min 8 s
Description: Bootcamp Module 4: Drafting Contracts to Buy Digital Products

Transcript for "Bootcamp Module 4: Drafting Contracts to Buy Digital Products": Hi, everyone. Welcome. Welcome. I know people are filtering in now and, excited to get this session started. So we'll be going live in a few minutes. That's or we are live, I guess, I should say. But welcome to drafting contracts to buy digital products. I wanna give everybody a chance to lot to filter into the room so I won't kick us off yet. I'll do that in a sec. Just to get my screen all set up. K. Well, with that, let's officially kick off. My name is Laura Frederick, from How to Contract, and this is a webinar on draft contracts by digital products. This is module four of a five part series that Agiloft producing and helping, everybody learn about contracts and, especially for digital products. The other three sessions have been fantastic. We covered so many great vendor contract issues. We started with kind of supply chain disruption with module one, where we got into things like tariffs and logistics problems and a lot of other things that throw off the supply chain cycle. Module two focused on pricing and credit terms, so such important provisions. Module three focused on manufactured goods and all the details that we need to know about that. So today, we're gonna talk about digital products, and then the next one in September is gonna be on drafting contracts to buy services with deliverables, which is a special kind of services and and brings its own complications. So I'm so thrilled. Grateful to Agiloft for sponsoring this series for free for everybody. And the great thing is all the past modules are available to you at at any time. You can go to the Agiloft site. You'll see the webinars available, and you can watch any of the past webinars and download the slide decks, which is awesome. So these are great, programs. You don't that's not just available for one week or one day. You can watch them, in the weeks ahead. So I wanna kick off by introducing my amazing panelists. I'm gonna start with Hebe Doneski. Hey, Hebe. How are you? Happy to be here, Laura. Thanks. Thanks. It's great to have you. So if you or can you tell us a little bit about your or, actually, let me I'm sorry. Let me introduce, Sapna first before we do introductions. So we've also got Sapna. How are you, Sapna? I'm good. Good job on the last name. I I barely ever get it right. So good job. Thank you. Thank you. No. I'm so grateful for you to be here. And I'll just before I have the, them introduce themselves, I'll just say a little bit of my relationship with each of them, which is with Hebe. Hebe and I worked together when I had my solo practice, and she had a solo practice. And I could see firsthand how much she knew about SaaS and digital products. So we work together as solo practitioners back in '2 twenty twenty ish, 2021. And now, Hebe's moved on from that, but she's been a frequent speaker a lot of how to contract events, including Contracts Con. This, most recently, her character for Contracts Con was Abe Lincoln, which was awesome. And so but we also have Sap Mahboobani Mahboobani, who is a also an amazing SaaS and digital products lawyer. She had a column with ContractNerd on SaaS issues for a while. So both of these, lawyers are just fantastic resources and are gonna be sharing with us all their insights. So let me start with you, Hebe. If you wanna give us a a quick introduction to you and your background and and, where you are now. Sure. So I've been, drafting contracts to buy digital products or SaaS as we now call most of these products, since since it was born. We called it all kinds of things like hosting and outsourcing, and finally, we landed on SaaS. I, as Laura mentioned, previously had a private practice, and I'm now the general counsel of Symmetry Software, which is a, payroll tax software vendor, and we sell both SaaS and, still on premise products for customers who want to, host their own products. Very cool. How about you, Sapna? Give us a tell us about you. Hi. So, originally, I was an IT consultant, so I've not only been, negotiating digital contracts. At one point, I actually worked in IT and was providing these services to our clients. So I've been, doing contracts for most of my legal career. But over the last three years, I've now supported some life's health business, so my practice has moved more towards regulatory counsel and product counsel, and I don't do contracts as much. But I have been doing them for fifteen years prior to that. And so I'm really excited to come here and actually talk about contracts because I don't don't get to talk about them as much as I used to. So I'm very excited to be here, Laura. Thank you for having me. Yeah. Thank you. And just so everybody knows, I'm not gonna dive into the AI aspects of digital contracts or, excuse me, digital products. It's such a big subject. There's so much for all of us to learn. So this training is focusing just on kind of the traditional SaaS and software digital products. So with that, I wanna kick off. So digital contracts, as people probably know, if you're already working with them, they have a lot of predictability now. Not when we first started, we were so many parts of SaaS contracts were new, but now we can see how they fail in relatively predictable ways. It's things around vague access and usage terms and unrealistic data provisions. The performance standards would be off, or we'd have inadequate exit planning. But that means because we know where they fail, we know where we can do a better job for our companies and clients by fixing those things in our contracts in advance. And so what we're gonna be talking today about is making these areas more precise, more, more clear and thorough so that we can better protect our client. I was just gonna say, I don't know, Hebe or Sapna, if you put yourself on mute for a minute, I can kinda hear some background noise. Perfect. Thank you. Okay. So here's our agenda. The first thing we're gonna cover is access rights and usage terms, then we're gonna get into performance standards and SLAs. Then we'll talk about data protection and privacy at a relatively high introductory level. Again, another subject that we could spend, hours, weeks on, and then exit planning and transition for digital products. The way this webinar is structured, I'll do a quick, five ish minute introduction to the subject that we're talking about, these four, subjects, and then I'll bring Hebe and Sapna in to share all their expertise from being in the field, working in the trenches on all of these kinds of issues. So you've met our wonderful panel. So we're gonna kick off with access rights and usage terms. Now these are really the foundation of your contract. This is the whole reason that you're doing this digital project product contract is to get access and use rights into that digital product. And I'm talking about subscription types of products, but we'll talk about that in a second. So you have to get the access and use rights correct. If you make them too narrow, you're not covering all the things you need the product for. But if you make them too vague or imprecise, you may end up basing a lot of additional fees because you didn't have that clarity upfront. The biggest thing you wanna start out with is make sure you're clear on the model. And, Hebe talked about the on prem, which is when which is the same as or it's, the shorthand for on premises. That's the traditional software that we would install on your desktop or typically on a server, and that was a different kind of, product that we were working with where the software was actually on our device. And that software license, typically, we have those on prem, and we're using it. But it could be a download from, a SaaS product. So, for example, we have a download of Adobe that we might have an app on our phone. That's gonna that's in a a device that requires a software license because we have it on our we've copied it there. But we also have things like the second panel, which is the SaaS subscription. These are products that we are just accessing and using over the Internet over the web, and we are able to use the platform and the functionality that's shared by the SaaS provider, through that remote access. And then the last one I I threw in there, which is these APIs. And the APIs are the code that enables us to use and access different kinds of platforms and systems on how they essentially talk together and share data together. And that's a whole other type of digital product. So I think this you know, pricing is always such a big part of these products because we're tying what we get with how much we have to pay. And I wanna go over the five core pricing strategies that I see with digital products. So one is per seat. You just pay for each person who's gonna have access and use to this digital product. Another way to do it is through usage, where you're tying the price to how much you're actually using. Now this can work well, but it also is makes it much harder to budget because you're not able to predict exactly what your usage is gonna be. Another way to do it is through price tiers, and these are things typically, a lot of these, SaaS platforms that we sign up, especially as individuals, they'll have different tiers for different kinds of features, different kinds of, programs they can you can access, different services they offer. So those are more of a tiered access strategy. You also can have for actual consumption. So if you're using storage or you're accessing the platform to just get particular features, it can measure the software. The software provider may measure the exact usage and then charge you based on that. And then finally, there's the enterprise pricing. That's a more general, license or access right, and that is allowing everybody at the company typically to use or access the program and the digital product. And these enterprise platforms, these can be very useful because you were able to put your whole company on a plan. You get your whole company all this access, but they're also very complex. And we have to be really, really careful about how we're measuring it. Because of the size and scale, mistakes can have very expensive ramifications very quickly. So one of the things you're asking yourself when you're figuring out what your what program you're gonna do when you're buying a digital product is how much do you need that continuous delivery. And vendor hosting is gonna focus on what kinds of features your product's gonna have. So, for example, we have downtime. And if downtime is a huge issue, you can't have downtime, this is a factor in deciding whether you're gonna pursue a SaaS program or an on prem program. How much reliability do you need for it to be there when you need it? Now another issue with some of the SaaS programs and the digital products that we're accessing online is often these are one standard, platform that's delivered to thousand, tens of thousands, hundreds of thousands of people, and the vendor, the provider can change that at any time. So if you have built on your end some functionality, some workflows that are dependent on the digital products makeup and operational flow, you could be in a lot of trouble if they suddenly make a change to that platform. Also, the APIs, this, again, are kind of the data conversations that our platforms are having. Those can be changed. And when that changes, suddenly you have an interruption to your data flow, which can totally throw off how your own product is working either internally. Or if you've incorporated this platform into your product, it could really throw things off there. And then finally, the pricing. You're really thinking about how you're gonna be managing all of that pricing as you go. I wanted to say a couple other big issues that you're watching for in these digital product contracts. One of them is how are you naming the users? So we have the convention of named users, meaning Bob is getting an account with this platform, and he has a dedicated account, and he can access it. And he's I'm gonna pay a a fee or a license fee or an access fee for that or subscription fee, I guess, I should say. Or you can have concurrent users where the platform is allowing people to use the, use a certain number of seats, but it doesn't require that it's only Bob have a dedicated account. It could be at my company, up to 10 people can use it at a time, whether it's Bob or somebody else. So that's one of the the ways that we approach pricing and a way to structure your digital product contract to make sure it's reflecting the kind of use you need. We're also looking at scope limitations. You really wanna pay attention in your digital product contract, what kind of restrictions you have. And these don't necessarily jump out at you. Sometimes they're just kind of hidden not necessarily hidden on purpose, but they blend into the background of the terms, and you may not notice them unless you're really paying attention. So things that will limit the way you can use the product. Sometimes these are internal use only products. If you are planning to use it to provide services to your customers or to integrate it in some way into the product that you sell, this is a big red flag and something you wanna talk about. Also, geographic limits. These are always kinda crazy when you talk about SaaS contracts because if I have a restriction to a particular country, but then I travel to Japan, let's say, for a meeting, am I now restricted from using it in that country? So you're you wanna pay attention, especially if you have a a workforce that travels outside of the the main country where you license it, how any kind of geographic restrictions work, just real critical, or the user type. Sometimes companies will give a full license, and charge this rate, or they'll give an admin license for free, or they'll have a few, testing, testing licenses that maybe aren't charged for. There's just lots of variations there. And then finally, paying attention to the audit rights that are tied to your usage. This is one of those things that's, I find pretty scary myself because having vendors come in and audit your use and audit how you're operating in this platform or on this program can expose a lot of your confidential information, a lot of your, details about how you're using the product, and and can create some problems. So for access and use, the I wanna sum up. These are the kind of the big picture issues that I wanted to highlight, which was thinking about making sure all your environments are covered, whether you're using it online, on prem, making sure the APIs are in there. You also wanna look at your user definitions and how you're counting them, this API issue that we talked or I talked about, making sure your pricing is clear clear, transparent, and potentially have some budget limits that you won't accidentally have a huge bill, at the end of some spike in usage, and that audit rates are clearly defined. So with that, I wanna go to our first question and discussion point with Hebe Doneski. And the first thing I wanna ask you about, Hebe, are the common mistakes you see companies make when they're negotiating access rights? And in particular, what kind of mistakes, or what advice would you give to avoid those kinds of mistakes? Yeah. Something I see a lot is a lack of clarity around how you've defined that usage metric or the the thing that you're counting to to to calculate the price or to calculate whether you've got overuse. I once had a situation where we were the consumer and we, the company I was working for at the time was reselling a product, and what we were paying for was defined as distributions. The challenge we had when the vendor came in to audit us was the contract didn't define what we meant by distribution. We interpreted it to mean when you have shipped a product to a customer, that on premise model where customer downloads something and is installing it on a piece of equipment that they own. We didn't think we should have to pay for distributions that were made when clients accessed that instance of the software that we had installed, and they were many it enabled us to deliver the same product to many, many customers with only one copy, basically. It was a big, painful audit, a big, painful fight, and the vendor could have pretty easily avoided that fight by defining what it meant by a distribution. And looking forward to understand that, hey. Companies are starting to host products, and customers don't need to install a copy of them. So that that's a big common mistake that I see because to a legal adviser, it feels like business issues a lot of time. In in fact, just earlier this week, I received a contract to review, and the order form said quantity, a thousand. Didn't say a thousand of what? So my first question to the vendor is, what are we getting a thousand of, please? And then we can go on to talk about the distinctions that Laura mentioned between named and concurrent users. Yeah. No. That those are fantastic. And I think that ability to define exactly what you're doing it and it really depends on that, knowing the product that you're buying. You have to invest the time into understanding the product you're buying and how your team's gonna be using it. So that's a great highlight or heads up about those issues. So I wanna move to Sapna and ask you about structuring this usage scope and its expansion rights and advice that you might have for companies that are figuring out how they wanna approach that, in particular from the customer side, like, what kinds of things they should be asking for is with this idea that it's not gonna be static, and they're gonna have to make sure that they're able to grow over time. Yeah. And that's exactly what I deal with a lot. Right? Especially with a company that is so big and so vast and geographically dispersed. We buy a product. We don't always really know exactly the extent of the use, record, and makeup it. So there are certain things we really wanna keep in mind. First, who are the users? Right? When we look. At the first purchase, we might think it's it's employees of a certain department. But really think ahead. Who else could be using it? Are they just gonna be employees? Do we have contractors who may need access to it? Is it another affiliate who's probably going to want to use this product in the near future? Which geographic location? We talked about geography. Are we only limited to Canada? Because I'm in Canada. Are we limited to Canada? Can can our Asian counterpart use it? So that's something we really need to keep in mind. And when we're defining who the user is, make it as broad as possible to to account for all of those future use cases. The other thing I've seen is certain products can be used for different business purposes. Right? Like so in the claims industry, we might we might, buy a product that's really used for claims processing with that in mind. But maybe in the future, we want to use it for application So do we want to limit that usage in our contract? Probably not. We probably wanna keep what we're using it for pretty broad. The other thing I've seen, and which is surprising these days, is sometimes there's no there's no mechanics for actually adding new licenses to the contract. So when you wanna add new licenses, you're going back and reopening the contract. And you know what happens. Right? First, there's this whole administrative overhead of renegotiating a contract, and then you have the vendor increasing their price because, well, it's not part of the contract. So that's something I think you really need to keep in mind. What is the mechanic for adding pricing? Are those prices negotiated for the term of the contract, or or do you have some vague terms saying that, you know, any increased usage is at the at the then current rate, which means you're now be be holding to their vendor to whatever rate they have at that time. So that's something you wanna keep in mind as well. Also, we talked about expansions, and I've seen that as we expand rapidly, sometimes we may purchase a lot more licenses than we actually need. So what is the mechanic to actually re reduce those licenses or reallocate those licenses? So that's something you wanna think about as well. And every time you have to add licenses, is this an ad vendor approval? You don't want that because if the vendor didn't like the price he negotiated, he just doesn't approve and you can't get those extra licenses. So keep that in mind as well. And now it this still happens surprisingly because I know everyone has already moved to the cloud, but there are still some models where we're seeing on prem, systems that are being, trans transferred to the cloud. So if you're buying something on prem, are these rights going to actually, transfer when the vendor moves on to the cloud, are you gonna have to renegotiate the same price? So that's again something you keep in mind. So those are just some of the things that I'm always thinking about when I'm when I'm negotiating these contracts, especially because we have, whenever we buy buy a software, I know there's gonna be scope creep. I know they're gonna wanna use it for other things and other situations. So, this is just you know, I keep this in mind, and I have a checklist of this is what I need to check for. Yeah. No. Fantastic. And, such a great list of all these issues, and and so many of those we've seen over the years happen all the time. So I appreciate that, checklist for us to think about for these issues. So with that, let's go to part two, which is performance standards and SLAs. And so SLAs are service level agreements. And these performance standards and service level agreements are really important because you're not purchasing access to a a SaaS product. You're not purchasing a license to, an on prem software just to have it. You're purchasing it to accomplish some task or perform some function. And making sure that the product actually does perform the function is gonna be critical to your success and also your budget. Because if it doesn't, you might need to replace it or get something else. You've already spent this with this vendor. These are particularly important in the SaaS world because, I've seen, at least, generally, the warranties given by SaaS vendors are a lot less than we used to see with, for example, on prem staff or on prem software contracts. The traditional model that we had for so many years had some really robust, warranties in there. But now we've moved to this much less warranty based contracting and much more about performance and what are the standards that we're trying to, the standards that the vendor is gonna hold up to in their performance, in the product's performance and ability to accomplish those tasks. So we're gonna be looking for a few things making sure to avoid. One is measurement criteria. When you have service levels, you have to make sure that you're not you're clear on what is being measured and how that's being measured. It kinda goes to some of the things Hebe Doneski was saying where you're buying a thousand of something. So great. But if you say, like, oh, we'll have 99% uptime. Well, what does uptime mean? You really wanna get into the the nitty gritty details of these terms to make sure that you're doing them properly. Also, aspirational statements. I'm always amazed by how many of those make it into these kinds of agreements. We will target a recovery of this much time. We will fit you know, we, will use reasonable efforts to try and make achieve this uptime level. Now some of these you have to live with, and and it really depends on leverage, price, what you're buying, the critical nature of the product, all those kinds of things. But you should go in aware when you are not getting firm commitments from your vendor. And then finally and this is what I was just saying. Like, reasonable efforts, we will maintain industry standards on uptime, you know, whatever that means. Because then if there ever is a dispute, you're gonna be fighting about what industry standards means and whether they did reasonable efforts as opposed to more of a black and white. Did they meet this, you know, ISO NIST standard ISO standard, NIST standard, whatever the standard is, have they met that in an objective way? You can test. But if it's just industry standard, we don't know which industry standard, what they're talking about. So these are all, issues of concern. So when you're drafting your SLA, there are a couple things you really wanna focus on. One is the specific metrics, like I was just saying, and these are some common ones, that you'll see on the screen. Another one is the measurement method. This is when you come into the, you know, the who, what, where world that we all learned long ago, but you wanna say, how is that metric measurement gonna be made? When is it gonna be made? And by whom? Those are really critical things that you wanna make sure in your SLA. You're gonna be looking at exclusions, particularly planned maintenance, which I always love these very broad. We may have unplanned planned maintenance, which is always my favorite. Like, these, oxymorons of allowing a lot of planned maintenance, but then also having some unexpected planned maintenance that would fit in the same bucket is one of the things that always drove me crazy. But you can also have force majeure. You but if you have force majeure and some of those kinds of, big events, think about how it should operate with the disaster recovery plan or other, you know, cybersecurity issues or breaches. You really wanna be thinking about the exclusions and whether they are appropriate for the software, for your use, for what you're paying, for your leverage. Make sure that you understand when it's not gonna apply and that that's working for your business function that you're cert you're and the business problem you're trying to solve with this product. The consequences, what's gonna happen? I see this, It's not done well a lot. It's the I often see a lot of problems with the consequences of failing a SLA standard. You wanna be super clear. Maybe it's some credits that you're gonna get some free months or users. Maybe it's termination rights. And often, we wanna make sure if it's a really egregious failure that we're not just getting credits, that we also may have the right to terminate. This can be on the hollow right if you're dependent on the platform, but it's something to think about and often can help in the negotiations if the vendor knows that you have that right, even if it's gonna be a hard one to exercise. And then finally, verification. This is always, to me, the biggest one, and in way is the hardest one because how are you as a customer gonna know that their uptime dropped below 99%? Is there, required post or required reporting? Is there, dashboard where you can check these things? Will the vendor automatically calculate and grant credits based on those numbers, or just do you as a customer have to request them? These are all things that you're gonna be thinking about with your SLAs. And some of the termination or terminology you'll see, things like uptime, that is really about the platform being up, which is great. But what if the key features that you need to use are not up? Are you defining uptime to include just the basic platforms working, or is it something more? So maybe the the term that you're looking for is availability of a particular features and for a certain percentage of time. Again, very, this could be really critical if you're using the software for or the platform for a particular function, and that's really the all that matters is that's up and available. But even then, it could be up and available, but working a 100 times slower than normal. That's when we come to these performance standards where we're saying not only is the system available or system up, not only is the feature we need available, but the feature we need is performing in accordance with the performance standards that we've defined. These are really critical business issues that you should be talking about with your teams, but you wanna make sure that they're being covered in your SLA. So here's my SLA checklist. Just looking at these metrics, make sure they're defined and measurable. You wanna be very clear on how you're measuring those things. You wanna have real consequences for failure, whether it's creditor or termination. Include some escalation processes so you can make sure that you are having those conversations when things start to go wrong. And, finally, this idea of monitoring verification rights and how you are finding out when there's problems. So with that, let's I wanna go to Hebe again. And, Hebe, I know you've been in this world for so long and done I would expect I don't know if saying a million SLAs would be an understatement or not or an overstatement, but I I have to believe it's up there. Can you share a little bit about your strategy and how you approach SLAs, particularly on the customer side, because this is all about vendor contracts and and from the customer perspective. And how are you making sure the vendors are accountable for, their performance, and what do you see people do wrong? Yeah. Well, for starters, I will say be realistic about your negotiating leverage with respect to these SLAs. If you're buying a multi tenant SaaS product, which means everybody gets the same thing, It also means everybody gets the same SLA. They might have a good, better, best that you can buy up to, but even if a vendor that is that fits that profile is willing to negotiate, you're not gonna get any different SLAs. I'm sorry. They're gonna treat everybody the same. Another good piece of advice I can give is in the due diligence process. A lot of vendors will let you see their historic, SLAs and make those transparent. And, you know, past performance is no guarantee of future results as we say in investing, but it's a good indicator, that of of what is to come when it when it comes to SLAs. That said, if you do have the ability to negotiate, if you're a big customer or it's a single tenant product, for example, that only you your company is accessing, Some of the things that I used to see in the past were, as Laura mentioned, credits. Those seem to be falling out of favor, I think, in part because they were relatively small amounts of money or relatively small amounts of free service, and they almost always required the customer to report the failure in order to claim the credit. What I'm seeing increasingly, again, if you have the leverage, is termination rights, and those those are what hurts. Churn hurts a SaaS vendor a lot. It's a metric that all of us measure. So if you're able if if you've got a product that you absolutely have to have up and running and you have to have key features up and running, or if it goes offline, you have to have a specific recovery time objective or RTO as as we say. Push push and see if you can get get a termination right either for an extended failure. Obviously, you're not gonna get the right to terminate if it's down for five minutes once, but an extended failure or multiple failures within a an agreed period of time. That would be a very effective, hammer to encourage a vendor to ensure that they need their service levels. Yeah. And I love that that multiple times over whatever period it is over, you know, a six month period or whatever it is. And we see that the we have the equivalent of that in kind of the goods world where we have epidemic failures or repeated failure. The same kind of failure repeats over and over. So I think all of these things you're saying are really about big picture functionality. Because at the end of the day, we don't want disputes. We don't want damages. We want the product to work as we need it to work when we need it to work. So, those are great points. So let me go to you, Sapna, with the next question, which is talking about measuring and enforcing performance when we're working with particularly complex technical dependencies and lots of points of failure. How do you approach these kind of SLAs and measurements when that's the situation? Oops. Oh, you gotta unmute. Happens at least once every day. So today when you have a digital system, it's a very complex system. Right? You have a hosting component. You have an application component. There's going to be integrations with other services. All of these are potential points of failure. And so when you're thinking about the service levels, you have to really think, does a service level matter mean anything to what I'm trying to do? So for here's an example of a payment system. Right? You could have a payment system that is up all the time, but every time I try to process a payment, it fails. So now I could have an uptime of a 100%, but what's the point if I can't get my payment to go through? So when you're thinking about SLAs, I'm probably not gonna focus so much on the uptime, but more on what is your error rate when it comes to processing a transaction, or how long does does it take to process a transaction? That's probably gonna be my focus more than the uptime. The uptime is still important, but that's the that's the metric I really care about more than, anything. You mentioned, SLA exclusions, and, you I I do like that you brought up the force majeure because that one drives me crazy as well. I mean, we have a force majeure clause. Why do we need to to exclude it from an SLA? But the other thing I'm seeing now is third party exclusion. So they, the vendor is not going to guarantee an SLA for something a third party does, and that's something you really need to be careful about because vendors have subcontractors, not third parties. And, really, the vendor should be taking responsibility for their subcontractors. So when I see these exclusions, I always pause and, you know, I I don't like that exclusion. At the very least, I want the vendor to take responsibility for their subcontractor. We've talked about remedies ad nauseam right now, and, and I agree with all of you. Right? Because service credits really mean nothing. And at at some point, I think vendors look at it as a cost of doing business. Well, I don't need the service credit. I'm gonna give my rent my customer a few $100. Doesn't really mean anything. But but if you see that there's a lot of service level, disruptions, have some sort of escalation part, have some governance around it. I would ask a root cause analysis. Why is this always happening? What are you doing to remediate it? I think those are those those remedies that actually matter to to me as a customer more than the $500 they're gonna give me at the end. And to point I I do like having a termination right, and I will always put a termination right in there. But, again, let's be realistic. Sometimes you really can't terminate. You need this vendor, and and we'll talk about how do you terminate a vendor effectively. But that's something I I would still put in there just in case I do need to, to terminate. The other thing I I would I I try to add into my contract is the right to modify or add new SLAs, especially in a very complex system where as you use the system more, you might realize that there there are other metrics you wanna measure. So I do try to put in a mechanism in my contracts where we are monitoring the SLAs, and we have the right to add or modify the SLAs as we expand the system or as we see things are improving or not improving. So just some of the things that I I I I look to. Those are, yeah, all fantastic and consistent with I what I've seen as well. It's really it's such an interesting world, especially over all the many years that we've been doing these deals and kind of the pre SaaS, pre cloud days where it was just such a different world. But at the same time, at the end of the day, what we want is the system to work, and to do what we needed to do in the way that the vendors promised. So this is fantastic. So let's jump into our next subject, which is about data protection and privacy. And I'm just gonna give a an overview of this because we all know I can't cover in five minutes everything there is to know about data protection and privacy. But let I did wanna touch on it, and I'm partly because I'm really excited to get to Hebee and and Sapna's input on that. But, really, we have to remember data is at the core central to so many digital products, especially now with these AI features. But it's this data presents the or creates value with the product because it's typically processing and generating a lot of data, but also so many risks. The there are operational risks. There's compliance risks, reputational harm. It's the data part of the contract or the product, the digital product, is really, an area we have to be paying attention to more than ever. So when you're thinking about the data parts of your contract, I recommend starting with some basic questions. We're gonna start with things like, what does the business think they're doing? And making sure that you understand from the beginning their intent, their perspective on what they're doing because often that may not match the product description or the order or other descriptions of what you're buying. You wanna think about what kind of access your vendor's gonna have in this deal, what kind of data they're gonna get, and what can they do with that data is gonna be really important. Again, looking at the contract, but also kinda what the business thinks they're gonna do and making sure that you're marrying all those things up. Mhmm. We're also looking if there's any PII. We're looking if they're selling the data and whether what does our privacy policy say and privacy notice say about what we're letting our vendors do with data. And then finally, you're gonna look at some of these things, like what privacy laws apply, what does the contract say about all these things that they can do, and, what kind of protection and remedies that you have if they don't do or do something they're not supposed to. So you're looking at your deal terms, and you're gonna focus in on some really big important topics. One is the vendor monetization risks. And this is because that data and I think I hear this. I I do a lot of programming on AI contracting, and that data is really becoming more valuable than ever. And what I'm hearing is that some of these companies, the data that they generate is worth more than the fees they're getting for the product. So that is creates an opportunity for that vendor to make money from the data, but also puts you at additional risk because that there's such a financial incentive for them to do so. This is why it's so critical that you're making sure you understand the data flows and that your contracts are restricting your vendor appropriately depending on the kind of deal and your leverage so that you are protecting that data and ensuring your compliance, and your own financial interests. You also wanna be thinking about that breach notification and response. This is a heavily regulated subject, in across the world and really something that all of our negotiations have to focus in on on these digital products. Again, this is where you bring your compliance people into the the story and make sure that your provisions are matching what the company needs to do from a breach notice and response perspective, and then making sure you're adjusting your contract. Data portability and export, this is gonna determine so much of your ability to maintain privacy and maintain your options. Because if you have one vendor who is not performing as they should, not just from a quality of per performance perspective, but also if they're managing the data in a way that it does not work for you for your compliance plans and your your business plans, being able to take that data that you've been processing with this vendor and take it to another platform and have that be portable is gonna be even more important than it's ever been before. And then finally, especially for the privacy privacy perspective, making sure you understand subprocessor management and how your vendor is handling the companies that process data behind the scenes, behind their product. And then finally, I just wanted to cover a couple of the other big concepts, which is one is ownership of that data, paying attention to that. There's a lot of issues calling it. I try to stay away from ownership of data because data is is less about IP ownership in the traditional sense and more about control and rights. But that issue of who has that, control and rights to the data, what their what they can do with it, things related to the vendor can only process things related to service delivery. So we're really trying to keep that vendor in a box so they don't go and do a whole bunch of things they shouldn't be doing. Looking at how the vendor's treating this derived and aggregated data, sometimes the vendors are looking to do a lot more with that. Now we have synthetic data where they're creating kind of mirror sets of data that aren't the original data, but have a lot of the same features, and that creates a lot of issues too. And then finally, looking at things that are called you know, I've seen it called different thing, observation data or the kind metadata, the kind of data that the system's collecting about your use is something else that you really wanna think about and think about how you can control. So data protection, again, very high level overview and and not too much time. But to give you a an idea of some of these key issues of ownership and processing limits, location transparency, being clear where your data's going. There's a lot of cross border issues that happen. Looking at the purpose for the data and the retention limits and then monetization and restrictions, breach response to guaranteed portability. So let's move to the questions for Hebe. Let me ask you, how and and, again, I don't I wanna kinda don't wanna dive too deep into this because we are, it's such a huge subject, and we really can't do it, to go into all the detail. But generally speaking, do you have advice for folks working on these contracts about how they're structuring and thinking about their data protection, especially with the regulations changing over time? Yeah. So full and fair disclosure, I am not a data privacy practitioner, and I have primarily worked with business to business companies. So I've had the luxury of not having to go deep into treatment of consumer data. If you are dealing in large quantities of consumer data, please get advice from a data privacy lawyer. But in terms of a sort of standard business to business data protection agreement, which is pretty typically accompanies all of our agreements right now if there's any data being exchanged. I I like to be general rather than specific, so I'm not gonna list out every data privacy law in The US because next month, there's gonna be another one. I like to include a provision that says if the part if new data protection laws that are adopted that apply to the parties, this agreement will be deemed to be amended so that each party will comply with those with those requirements so that we don't have to amend every time there's a a unique requirement. Another thing I'd like to touch on quickly, which Laura alluded to, is don't take too much comfort in ownership provisions because as Laura mentioned, you may not own data. There's not a lot of ownership rights in data, and particularly when you've got an AI agent that's not human interacting with data, its output is not IP at all. So, don't rely on provisions that say things like customer owns its data. Really get make sure you detail if it's important to you. Detail what the vendor can do with your data and what you and the vendor can do with the output. Yeah. Those are great great insights. Let me go to you, Sapna, for, about vendor data rights and the best way to balance kind of the vendor perspective and the customer perspective because you do have these two different interests at play and what customers can be doing. So, yeah, this is interesting. Right? Because you want the vendor to be innovative because, presumably, you'd be benefit benefiting from the innovation. But you also have to think about your confidentiality, your your regulatory obligations. So I think the first thing I'd want to understand is what exactly are they do they mean by when they say data? Are they talking about the data I've given them and input into the system and that has been output from the system? Are they talking about derived data, which is the whole thing itself? Are they talking about usage data? So really getting an understanding of what are they thinking about and what could the risk be for my company in those different, pieces of data. Rule of thumb is usually when it comes to customer data, so the data I'm inputting and the data that comes from the system, that's a no go. You can only use that to provide the services. We tend not to really want the, want the vendor to use that for anything else. But there are exceptions, but that's the the rule of thumb. Derived data is such a broad thing. Like, what do you mean by derived data? Anything any change in your data makes a derived data. So, usually, I like to play with them the aggregated and anonymized space. So they've aggregated their data with other data. So to a point where it's not identifiable, that's really important. You shouldn't be able to identify not just individuals because that's a breach of, privacy loss, but also the company that this data came from because that's where competitiveness or your competitive intelligence could be part of that data. So if we do allow use of derived data, those are, those are the guardrails we put in place. Also, they shouldn't be trying to reidentify the data because we all know there's no true anonymization with the right datasets. You can always reidentify individuals that could reidentify the company so that there's always a provision against reidentifying data. We may want them to use aggregate data for insights, like benchmarks, for example. Right? Like, we would benefit from benchmarks just as much as our competitors. So I I wouldn't restrict them from using aggregated data to do things like that. And I would ask for the benefit of it, like, share the benchmarks with me as long as you're not, you know, you're not you're not showing my confidential information or my competitive information. I'm good with that. I don't really see monetizing as much and, we try to stay away from vendors monetizing the data. But if it was a if it was to come and play, I'd really wanna understand what are they monetizing this for. Are they selling the data to advertisers? I'd probably be advise my clients not to go there. Will they be using this data, to build competitive products? Again, I'd advise my client not to go there. All in all, it is a tricky balance. You do want them to innovate, but you still have so many risks and regulations to keep abreast of. So, this is this is one area that I as as both of you have said, right, get a good privacy counsel, really understand what's happening with the data, get a good understanding of it, and tread carefully. But it it's getting harder these days because they really do wanna use that data. Exactly. Exactly. Okay. Great. Well, let's move on to our final, section, which is exit planning and transition. And, you know, even though when we go into these contracts, we go in with high hopes and expectations of super success, It doesn't always work that way. So I recommend whether it's digital product or otherwise that you're always thinking about that exit at the time and before you sign that contract. And those having clear exit strategies often is the difference between a successful product and a not successful product because you need to be able to know what you can do if things go sideways or be ready to make a move if you have other opportunities for a better fit for a product. So I I can't overstate at least from a somebody who did this lot of supply chain and vendor contracts my whole career that we're always thinking about, okay. What happens if this doesn't work? What's what are we gonna be able to do? Do we have a lot of plan b, plan c, plan d worked out? And these particularly on these three areas I'm gonna talk about, which is termination rights, transition planning, and data export. So with termination suspension rights, you wanna make sure that you can leave. Again, it might be a hollow right depending on the type of product. It might not be easy to leave. But even if it's not easy, you need to be ready to leave. Because if something happens with the vendor, let's say they go out of business or their product becomes illegal, or there's so many things that can happen that could interfere with your ability to use that product and rely on it, making sure that you have those plans in place. In termination and suspension, it's just one of them and one of the things that you can do to protect yourself for these eventualities, but they are an important one to know because sometimes you do get to that place where you need to do that. And so we're thinking about things like breach triggers and cure rights, what rights do you have to access the data and be able to get all that exported, which we'll talk about in a second, making sure you have continued use and access during a transition period, and potentially having some restoration time line so that you can restore your service if you need to. We're also looking at this transition planning, which I kind of alluded to when I said this idea of continuing access. So we wanna make sure that we're having this thoughtful phase down line or phased wind down of the product. We don't wanna just one day show up and the it's turned off. We haven't done any planning. We haven't done any prep for plan b, plan c as of that moment. Sometimes people do it before they buy a product, and then they get complacent and fail to keep that up with the changing landscape for that kind of product. So so important to keep up that regular transition planning always with an eye on what you can do to prepare. So the ways that we can do that are things like adjusting your notice period. How much time do you have to give them to let them know you're gonna be transitioning, and then how much time do you get to continue to use it during that transition? What kind of post support you term support do you need? And then also looking at whether there's any obligations for the vendor to keep supporting you through this period. They might give you access, but often you may need the vendor to do even more, whether it's help you resolve an issue or, you know, provide some other, support for your use of the product. Having that even during this transition period is is can be very critical. And then data export and migration rights. This is so critical. Again, we're talking about data as the core, value in a lot of cases, both your own data and your vendors, use of your data. But data's at the center, and we have to make sure that we have the ability to take our data elsewhere. If we're not gonna be using the same program, working with your your, IT team, working with your commercial group, figuring out what kind of data you need, what kind of formats you need, how are you gonna be able to extract it, including regular downloads and exports exports of that data so you don't just suddenly discover they're gone, and you are out of luck, being able to test it and, making sure that they can't hold you hostage. I've had this happen where they won't give us our data until we pay all these fees that we disputed and don't believe we owe. So you can really get stuck in that, have make sure you have the right to get that data regardless. So here's our quick checklist. I won't go through it. You'll have if you download the slides, you'll get access to this, but it's the things I just talked about because I wanna get to the questions. And I wanna start with you, Hebe Doneski. On when you're thinking about exit planning, what do you think is the most critical elements that you're gonna focus on and mistakes that people make when it comes to exit planning? I think just overlooking it in general is is still happens even though we've all probably seen a disaster when we've exited the vendor and things have gone horribly wrong. So what I would recommend you do, like, this afternoon after you get out of this program is use this segment of the deck to draft a a termination assistance clause that you drop into every every digital products agreement that you're purchasing. I love it when when customers do that because even though Symmetry Software doesn't, by large, retain any of our customers' data, which makes my job really easy from that perspective. I that clause gives me an opportunity to explain our stateless architecture. And that way, you've you've you don't have to worry about whether the vendor's transition assistance clause is adequate. You've you've gone through your checklist. You've decided how long you need. Maybe it's customized for different vendors. You've decided what formats you need the data in, and you can be really specific. I need it in Excel, CSV, or, you know, word. I I as when representing vendors, I'm always happy to be that specific. So that that if you take one action away from from this today, I would say go go away and draft your your transition assistance clause using Laura's slides as your checklist. Yeah. And it's it's just so critical, and and this doesn't even apply to just digital. It's really any service provider that we're dependent on. We really need to have these transition plans in place. So for Sapna, let me ask you about kind of this the challenge of this operational continuity and keeping flexible for these complex digital products and this idea of of transitioning away from a vendor. Do you have strategies that you like that you find work best as you're thinking about these issues? I think, it's really one of the big things is how do you exit? I mean, you've covered that. Right? Do you have clear exit rights? Because if you don't have clear exit rights, they're kind of stuck with this vendor whether you want to or not. And and while we have termination for breach and all, it's really nice to have a termination for convenience if you can get it. And I recognize we're not always gonna get it. But I've been in this long enough to know that plans change even when you are a 100% sure this is what you were going to do. Plans change. So if you can get a termination for convenience right, even if there's a little bit of a penalty clause, it might just be worth having that in there. The other thing that may not be as pertinent today, but I still see sometimes is, customizations that that vendor may have made for you. There are still situations that I'm I'm actually doing one now where that customization can actually be used with another vendor in the future if we if we choose to use them. So make sure you've got the right ownership in any of those customizations or configurations if you think that you're going to have to use them with somebody else. Source code escrow is kind of falling out of favor with SaaS. You don't have that much source code, but even, working in a in in finance, you'll see that there are many legacy systems and source code is still pretty much a thing and escrow is pretty much a thing. And the biggest mistake I see there is people will ask for escrow but not really know how to use the source code. They they don't test to make sure it's complete. They have no clue what to do with it, but they feel really happy that they have a source code escrow provision in the contract. So if you I I don't see that much value in the escrow provision, but if you're really fighting for it, make sure that you can actually use it or you know how to use it. The data portability is a big one. Right? And we've all spoken about it. And I feel, that's that's an interesting one because the format of the data is really, really important. And I was in a situation where we were terminating with the vendor. We asked the vendor for all the data back, and we got PDFs, like, pages and pages of PDFs with our data in it. And the contract had basically was was vague about it. So, yeah, we had our IT team set an input data from PDFs into the new system. Definitely not something you wanna deal with. Right? The transition assistance, again, we both talked about. We really, I do like to have a good buffer for transition. Pricing is usually something that we we negotiate, like, what what is the rate gonna be? Are you gonna offer it for free for so many hours? The big thing you need to make sure is that they're willing to cooperate with other vendors because they may not be thrilled about having to cooperate with the competition at this point, so make sure you have that that ability. And then also, while you're migrating, this is not a switch. Right? You can just turn it off and you move to the new system. There's gonna be a time where you're gonna be running both systems in parallel while you're migrating. So make sure you've got those rights to continue using the system for a while. I find that a lot of terminations will terminate the system on termination, and that's something that I've seen overlooked more than once. So that's, I'd advise keeping that, in mind as well. No. Those are all great points. And I'm going to, I know we're at the top of the hour, but I wanted to continue just with our wind up, and then we have some questions to ask. So I understand if people have to head out, but we'll just stay for a couple extra minutes. And, I wanted to take advantage of having these great ladies here and just any kind of final advice that you wanted to make sure you've covered during your remarks. And I'll start with you, Hebe. If you have any advice for people who are potentially newer to digital contracts and what, you would what what is your advice? I would say my biggest advice is don't be afraid to ask questions if you don't understand something, whether it's a question for the vendor about what a provision of a contract means or it's a question for your business people about how we're going to be using this tool or how does this contract provision relate to how we're using this tool. Don't nobody knows everything, and I'm always happy to explain what provisions of my contracts mean as a vendor. And maybe those questions will inform me that I haven't read my contract very well and I need to rewrite something. So be curious. Don't don't be afraid to ask. Great. Great point. And how about you, Sapna? Is there anything you wanted to cover? Yeah. I think you really need to understand what we we're using the digital system for and what the limits are. Right? I know I've been I've talked about flexibility and asking for the world, and it sounds like we wanted us for everything, but it's not realistic. No vendor is going to agree to every one of these provisions. So really understand what are the important provisions, what are the likely scenarios they're going to see a business in and concentrate on those. For example, source code escrow. Really do we need it? And I don't think so. But anyway, so, yeah, just be pragmatic when you're when you're negotiating with the vendors, especially these days where a lot of vendors are not going to really come to the table like Amazon and all. You're not going to get as much movement from them, so make sure you understand what's really important. Yeah. Those are great. Well, if you've got Hebe and Sapna, if you got some time, I'll just go through. We have a few questions to, answer. And, one the first question was, what are your strategies in mitigating price increases, especially when, volumes were reduced and potentially the impact changes impacting the pricing structure time zone factor discount? I don't know if either of you, have a experience with that kind of how you're managing as a customer that risk of the price increase with changes in your usage. I can take a first pass if you'd like. Yeah. That's right. You you will get the best, deal probably from most vendors if you're willing to commit to a longer term agreement. That can be scary when it's your first year of working with that vendor. But, typically, vendors will offer price protection if you're willing to agree to a two or a three or a five year agreement, as opposed to a one year or even a month to month agreement. Contractual price protection is worth asking for, but it's usually a pretty firm issue for a a company whether they're willing to give it or not. So don't, if because if a company tells you a vendor tells you we just don't do that, they're probably telling you. Anything to add, Tanya? No. I think you covered it. I think the longer the term you're willing to commit to, the better price they're gonna get. That's just the reality of it. Right? And, I know people really don't like that, which is why I always advise my company to, like, really do a good analysis of what you need. We do have banded pricing sometimes where, you know, your price decreases with volume. So you could use that as a a strategy to at least have some sort of, price certainty as you decrease, at least you know what your price is gonna be. But, again, I mean, it is up to the vendor to so, it's it's their prerogative. If they wanna increase prices, if you decrease volumes, especially if your contract doesn't cover that. Right? And that's why you need to be really clear in the contract as to what the mechanism is for increasing or decreasing. Yeah. For sure. Another question we got was best. What are the best practices for accessing the data archive and data security requirements, after the initial term is done? And I don't wanna get into specific circumstances of the question, but just generally speaking, is there a standard best practice for how long people should have access to the data that came with their contract? Is it you know? I don't know. Probably, it would see, like, thirty days or sixty days or something like that. Is that something that is you see enough that there is a standard? I think it depends on the application and how complex it's going to be for them to transition or ask the data. I mean, it it there's there's two things. So our contracts always have a provision where the the vendor will delete all the data on on termination of the contract. Right? And many vendors will actually wanna delete it because they don't want the liability of a security breach for that data. So you need to balance that risk with how long you're willing to for the vendor to keep the data so you can get it at some future point. I'd advise the business get it out as soon as possible and have them deleted. But I do advise I do understand sometimes things take longer and that's a negotiation point. But from a from the client point of view, I want that to be as short as possible. Yeah. And that's what I usually see as well. Although, keep in mind that retaining your data that carries a cost to the vendor because there's infrastructure that they need to store it. So you may find that a vendor is willing if for some reason you want a very long post termination retention period, vendor may be willing to agree to that if you're willing to pay for it. Wonderful. Okay. Great. Well, we're about done, but let me just first announce our final module for this vendor contracts boot camp series. And that's module five is on September 18. And we're gonna be talking about, contracts device services with deliverables. Really look forward to everybody there. You can go already, register for that. You can preregister, and we'll have more information about the details of that coming. But thank you so much to Hebe and Sapna for sharing all your insights and expertise with us, and thank you to everybody who showed up today and, enjoyed the program. And, again, you can rewatch on the Agiloft website and get access to the slides there as well. So thanks again to Hebe and Sapna. I really appreciate it. Thank you. Okay. Bye, everybody.