A Master Service Agreement (MSA) is a standard contract in the subscription software industry. It lays a strong foundation for the relationship between provider and user and establishes a solid framework for other agreements. While the MSA typically ensures protections like confidentiality, clarity on each party’s responsibilities, and guidelines for dispute resolution, sometimes companies need more specific guarantees of service. This is where the Service Level Agreement comes into play.
While not every MSA is going to be accompanied by an SLA, there are good reasons to consider the latter when drafting a service contract. These set parameters for uptime and tech support as well as establish systems of credit that ensure customers are getting the service they need to keep things running smoothly. Keep reading to get answers to questions about when, where and why an SLA is necessary, and get the big picture on how to guarantee software providers and their customers have a good working relationship.
Questions in this Episode:
- Why SaaS companies like SLAs?
- How does the SLA deal with warranties?
- Is 99% a good service uptime?
- Where is the right to terminate?
- How does the SLA create flexibility for the sales team?
Why Tech Companies Use SLAs
Tealium is a software company that does tag management, helping clients manage tracking tags used in digital marketing. Online companies use tags, short snippets of code added to a URL, to collect data for analytics and marketing purposes. Tag management helps clients know the data about clicks on their websites, what pages are being visited, and where people spend most of their time.
Tealium uses an MSA with its clients to define the agreement and business terms and conditions. But like other real-time, critical-data tech companies, Tealium clients need to depend on quantifiable high levels of online service and uptime. Tealium uses SLAs as part of their MSA with their client to better define these service levels.
When to Add an SLA
Many companies have an MSA with no accompanying SLAs. But most tech companies, especially SaaS companies like Salesforce and Google Cloud, will automatically have SLAs as part of their agreements.
If the MSA does not cover critical areas and operations, you can help protect your client by proposing SLAs and tying them back to the existing MSA.
For example, your client’s tech guy might complain that the cool artificial intelligence software doesn’t work like they said it would, nor does it work all the time. If it is not sufficiently covered in the MSA, you can do so in an SLA.
And the warranties in the MSA might not sufficiently protect your client.
Warranties in the MSA
The Tealium MSA at Section 8 covers warranties, including direct claims and even the ability to cancel the contract.
But in this MSA, as in most, the warranty language is built more on generalities than specifics. For example, the Tealium MSA warranty states they will, perform services in a “professional and workmanlike manner in accordance with recognized industry standards” and provide their services “substantially in accordance with the Documentation.”
This is fairly standard warranty language and you would not expect anything more detailed. Warranties are not going to state the service will be perfect and they rarely get into specifics in the MSA.
That’s where the SLA comes in. The SLA will not guarantee perfection either, but it will typically guarantee the service will be working 80%, 90%, or 99.9% of the time.
And when the SLA describes service levels they can be referring to both the consistent performance of the software tools and also the performance of the humans that help with services, including repairing the software tools and getting the system back online.
Two main factors are the “uptime percentage” and the “response time.”
Onsite maintenance packages typically include response time, and this package may, or may not be negotiable for items like the number of hours and response time for critical maintenance.
But in SaaS contracts, the main factor is the guarantee of what percentage of time the systems will be working as promised, namely uptime and the uptime percentage.
Service Uptime Commitments in the SLA
The Tealium SLA commits to service uptime, stating they will use “commercially reasonable efforts” to make the services available with a Monthly Uptime Percentage of 99.9%” during any month of service. If Tealium does not perform at this level, the customer is eligible to receive a service credit.
While the language of “commercially reasonable” is not specific, it is acceptable because it is tied to a quantifiable uptime percentage, in this case, 99.9%.
When it comes to uptime percentage, there are two main factors your client should take into account. What is the actual amount of downtime allowed by the guaranteed percentage, and what credits does the tech company give if they drop below the guaranteed percentage?
While 99.9% sounds like a high and acceptable uptime guarantee, if you put that number into an SLA uptime calculator, it translates to 43 minutes per month in downtime, or about ten minutes per week.
As you review uptime percentage guarantees, you need to check with your clients and their tech team. Ask if this is an acceptable number to them. Each business is different, and for some highly time-critical companies, ten minutes a week in downtime may not be acceptable.
The tech guys may come back with the need for a 99.99% or even 99.999% uptime as an acceptable level. But ultra-high uptime percentage commitments make service commitments more complex, so this is likely a point of negotiation.
And uptime percentage is a defined term that typically excludes certain items like maintenance time. It is usually an acceptable term if the scheduled maintenance time is in the early morning hours, like between 3 and 5 am.
It is important that your client understands that downtime is not simply inconvenient. It can translate into lost sales and revenue.
How critical is this? And do you have a plan if it's down 40 minutes a month? Is that a big deal to you? Is that loss in sales okay? - Michael Curylo #ContractTeardown Click To Tweet
Service Credits and How to Make a Claim
The Tealium SLA has well-drafted sections at 3-Service Credit s and 4-Credit Requests and Payment Procedures that contract drafters can use as they build or review a similar SLA.
Many SLAs do not give you service credits. But,Tealium gives service credits if they drop below the uptime percentage commitment.
If the monthly uptime percentage is less than 99.9% but equal to or greater than 99%, then Tealium will give a service credit of 10% of the monthly subscription amount.
If the monthly uptime percentage drops below 90%, their customer receives a 20% credit.
And if the client needs more granularity in the numbers, you can build a table with more exacting percentages for varying scenarios. Input from the tech team can be invaluable in determining these numbers.
The claims procedure in this SLA is reasonable. The customer submits an email request that includes a “reasonably” detailed list of the instance when the service was not available, along with other pieces of information.
However, the customer has only 10 business days after the end of the month to submit the claim. This is a fairly tight time frame and means the customer’s tech team and leag team must be fairly quick communications.This is not always the case, and can result in emails from the legal department asking “Why didn’t someone tell me about this sooner?”
From the customer’s point, of view, it would be better to have a bit more time to respond and ask for the credit, like 30 or 60 days.
Remedies – Chronic Outages and Termination
While this SLA gives credits for downtime, what happens when the service is not acceptable?
Here, the customer can terminate the service order if the uptime percentage is less than 97 percent for two consecutive months or any four months in a 12-month period.
Again, while 3% may not seem like a large number, it is enormous in the world of online business. If you have an online blog, this may not be critical.
But 3% downtime is 21 hours per month. And if those 21 hours are during your peak customer buying times, this could be disastrous for most e-commerce businesses.
All the percentages are usually negotiable. So, this is an excellent opportunity to talk to the tech and marketing teams to determine a critical number of needed uptime, below which is unacceptable. In the land of e-commerce and SEO marketing, companies pay substantial amounts to direct traffic to their sites. You lose the potential sales and waste advertising revenue if you are offline.
Using Tables to Clarify Response Times and Set Customer Expectations
Tealium’s SLA has a good table detailing how they will respond to incidents and articulates severity levels, descriptions of the response, response time, and the time objective for resolution.
These tables are technical by nature, and the legal team typically does not get involved in drafting them.
Most SaaS businesses respond based on tables like this. Both sides better understand the definition of a critical defect, a material defect, or a minor defect and the response time and resolution time for those defects.
So, for example, the tech team knows the definition of a critical defect and the projected response and resolution time. This ties back into promised uptime and is a way to help mitigate the uptime requirement.
But it also helps the team understand if something’s not critical and that the response will be less than immediate. Tealium is setting customer expectations.
The Legalese is in the MSA, But the Flexibility is in the SLA
Although it seems that adding SLAs to an MSA creates more confusing and unnecessary paperwork and documents, the opposite is true.
An MSA is typically an agreement between two parties listing terms that govern all of their future transactions. It usually includes more generic terms and conditions like payment terms, warranties, IP ownership, jurisdiction, and dispute resolution.
But an SLA, especially for SaaS companies, gets into the specifics of what type of service is provided, how it is guaranteed, response times, resolutions, percentage of uptime, credits for downtime, tables, and more. Most SaaS companies use SLAs in addition to their MSAs.
SLAs allow the MSA to be cleaner and not full of tables, charts, and response times. And using SLAs allows clients to make different service levels for different customers without having to re-draft and renegotiate the MSA.
Many businesses view the MSA as the “legalese” of the agreement with all the indemnities, warranties, and other legalistic terms.
But they view the SLA as defining how the service will be performed and what to expect. And some companies allow some of the sales team the flexibility to negotiate some of the terms of the SLA, making it unique to each customer, while the MSA remains uniform for all customers.
And a major advantage of contract drafting is that the parties can re-open the SLA while leaving the MSA intact.
Leave the legalese in the MSA and give your client flexibility with a well-drafted SLA.
Show Notes
Subscription software companies whose entire business model relies on availability of service have good reason to contract service guarantees. Enter the Service Level Agreement, an accompaniment to a Master Service Agreement that specifically outlines services provided, how these are measured, and issue resolution. Watch as Michael Curylo, an L.A.-based lawyer working at the intersection of technology and entertainment, tears down the SLA for customer data platform Tealium. As Curylo says, while these contracts aren’t always necessary, they can do things the MSA can’t do to protect both parties and ensure their business relationship functions as it should.
THE CONTRACT: https://tealium.com/terms/sla-addendum_v28feb2019/ ; https://tealium.com/terms/MSA-Tealium_Terms_of_Service_Americas_v31MAR2020/
THE GUEST: Attorney Michael Curylo comes from a technology background before going into entertainment. He is currently practicing on his own and a contractor to several companies, including Beachbody, which merges tech with SVOD and entertainment with film production.
THE HOST: Mike Whelan is the author of Lawyer Forward: Finding Your Place in the Future of Law and host of the Lawyer Forward community. Learn more about his work for attorneys at www.lawyerforward.com.
If you are interested in being a guest on Contract Teardown, please email us at community@lawinsider.com.
Interview Transcript
Mike Whelan Michael Curylo, welcome to The Contract Teardown Show, how are you today?
Michael Curylo Great, great. Thanks for having me.
Mike Whelan I am glad you’re here because we’re going to do something. We’re going to pivot off of a conversation that we had before with my friend Darlene Tonelli about MSAs and the random other documents that pop up around an MSA. We’re going to talk about this document—I’m going to share it with the folks at home. This is a Service Level Agreement that has a relationship to an MSA. Before we dig into it, Michael, tell me about this thing. When are we going to see it?
Michael Curylo Yeah. So this is called—this is the SLA and MSA for Tealium that you’re going to see online, you can just google it. And they have a really nice MSA and SLA online, and we’re going to use it as an example. And what Tealium does is something called tag management. So this is useful, especially for tech guys who are trying to track what people do on their websites. So, you know, the clicks on the website where they’re spending the most time, what pages [on which] they’re spending the most time, those are tags that are sent back. So you can see what people are doing. So this is a place where uptime is especially important for marketers to see, you know, how much time people are spending on different parts of websites. So that’s why the SLA is important to their clients and why it’s a good, good example of uptime guarantees that can be given by tech SAS providers to your tech customers.
Mike Whelan Perfect. And we’ll talk about the relationship with the documents. Before we do, Michael, tell us about your background. What’s your practice like?
Michael Curylo So I am an independent lawyer who goes around and I work a lot in-house, kind of an external counsel in-house, but not…not in-house, but externally in-house, so to speak, for a lot of tech companies that do a lot of SAS platforms, SAS contracts, as well as production. So film production. So those are random, but that’s because of us being in Los Angeles and streaming providers.
Mike Whelan Yeah, I tell my wife, I’m like, I’m not self-employed, I’m strategically unemployed, right? I get to pick what I want to do. It’s awesome. I recommend it! So, let’s dig into this thing. I’m going to ask you some basic child questions because I’m the basic child in this scenario. I had a conversation, I don’t know if you saw this episode with my friend Darlene Tonelli, and we—I made fun of her a little bit because she was talking about this MSA, the Master Services Agreement that she was deal—I think it was Salesforce, if I remember. And I made fun of her because she said, You have to print—like an MSA will refer to a bunch of different documents, and so she’ll have to print them. And I was like, Are you just sticking them on the wall and tying strings between them, like [A] Beautiful Mind? And she said, sort of. And one of the things, the documents that she talked about was this Service Level Agreement. So paint the picture. What is the relationship between an MSA and an SLA? When are we going to see that kind of a—the need for this kind of document?
Michael Curylo Yeah. So not every not every MSA is going to have an SLA. That is something that maybe some SAS providers will provide, like a Google Cloud or Salesforce will automatically have it. But there are other critical operations that maybe won’t, and they may just give you and MSA. And the useful part, I think that, you know your clients could get from this, from this YouTube is that they can propose an SLA and tie it back to the MSA. And it’s not something always given to you, so you may want to add it in order to protect your end tech guy, who may complain, like, Hey, I bought this cool artificial intelligence thing, and they said it would work and it doesn’t work all the time. And your warranties may not protect you sufficiently, and we can talk about how that relates. But in section eight of the MSA is an especially good place where you see what the warranties are and those are your direct claims or ability to even cancel the contract. But here in their warranties, it’s really, you know, really revolves around—it performs in accordance with the documentation, which is, you know, a pretty standard warranty. And it’s hard to get more than that. Like to say that it’s going to be perfect. So that’s where the SLA comes in. Like you know, that OK, you’re not going to guarantee it’s perfect, but you can guarantee that it works 80 percent of the time or 90 or 99.9—
Mike Whelan —Well, so to clarify for my sake, when we talk about service, you know, it’s called a Service Level Agreement. Is the service—you know, a lot of times when you get these software tools, they also will give you human services like people working on helping you get on and whatever support it is that you get. But it’s also software as a service, the software itself, they’re using the language as a service. Does this refer to these sort of I.T. contracts where humans are coming in and helping you? Or is this more like this is what we are going to tell you that the software itself will do in terms of being consistently available?
Michael Curylo Yeah. So unfortunately, it can be both [laughs], but usually in the term that I’m going to use it, and, you know, the term that we’re using here, it’s both. And that’s both the uptime percentage that the software service is online and the amount of hours for, like, what I call critical maintenance or, you know, onsite teams, how they’re going to respond to incidents. So it can be both, um, you know, usually the onsite or those maintenance packages or something you could pay for to upgrade the response time, so to speak. And that’s maybe not—maybe it’s negotiable, maybe not. But—and you might look at those two as a tag team of their personnel response and the software uptime, so, you know, software as a service sometimes. But really, here we’re going to focus on the software as the service uptime.
Mike Whelan Got it. So let’s do that. So we’re going to jump to number two on this Tealium contract. In section two, it refers to the service uptime commitment. It says Tealium will use “commercially reasonable efforts,” which is a loaded phrase, to make the services available with a monthly uptime percentage of at least ninety nine point nine percent during any month. In the event the services do not meet the service commitment, customer will be eligible to receive a service credit. So before we get into the credits, talk to me about section two. Do you like this definition of uptime?
Michael Curylo Yeah, yeah. And you know, we’re going to go ahead. Like, in general, I would go ahead and accept that definition because “commercially reasonable efforts” is fine. Really, what I care about is the credits that I get if they drop below that percentage. The only thing that I will evaluate is the 99.9 percent in this clause. And you know, and here, I google, what’s an SLA uptime calculator? And I put in the 99.9, and that means it can be down ten minutes a week; or a month, It can be down 43 minutes. And then I’ll go call the tech team and say, You guys cool with that or do you need higher? Do you need 99.99? You need 99.999? And so, you know, they call it the three nines or the four nines. But that really lowers the down—the service commitment possibilities.
Mike Whelan This moment is literally the first moment that I put 99.9 together with forty some minutes a month [both laugh]. That’s actually a huge outage, being down forty something [minutes] a month.
Michael Curylo Yeah, as an acceptable level, right? And you know, and all these are defined terms. So it defines monthly uptime percentage. So monthly uptime percentage is a defined term that’s—it’s an operable state through, you know, whatever, but that will almost always exclude, you know, things like maintenance time. And actually in this one, I’m not sure if they actually exclude…this is just full avail—availability, but often I—we will allow, you know, if they have maintenance times and they’re between like three and five a.m. or something we’ll allow it. But all these are items that I try to communicate with the end tech people: How critical is this? And do you have a plan if—you know, if it’s down 40 minutes a month, is that a big deal to you? Is that loss in sales, or is it okay? And that becomes a question for them.
Mike Whelan Yeah, especially if you know, a bunch of APIs are relying on this thing being up. All right. Well, let’s talk about three and four. You mentioned the service credits. It talks about what’s going to happen with the service credits. It’s calculated as a percentage of the monthly subscription amount for the specific service. Three and four—three talks about what are the service credits and then four talks about how you get them and what the payment procedures are. So talk to us about three and four.
Michael Curylo Yeah, and just the reason I like this SLA is if you don’t see an SLA, you can use this, just because it lays out the what I would call an ideal structure that you can build from. And you know, a lot of SLAs will not give you even service credits, for example. And so this is great. They’re giving you service credits if they drop below this uptime percentage. So I mean, here it’s less than 99.9, but equal to 99 or greater than 99, then they give you 10 percent back a month. So that’s great. And that does happen. Like I have seen these things happen and then less than 99, you get 20 percent. And you know, if you need more granularity, you can build out a table and keep, you know, give it a more percentage or getting more percentage off if you like. And that’s a great—you know, when your tech team is going through pain, money back is great, makes everybody a little bit happier. And you know, the section for the procedure is also, you know, this one is very reasonable, just includes a list of the instances of unavailability and then what they need to do to make that claim. Usually, like in here, it’s 10 business days up to the end of the month. You know, is your tech team going to be responsive enough to remember that? I like to have more time than that, maybe like 60 days, but you know, if it’s ten days, you know, you just got to be on top of it. But it’s better to have a little bit of time 30, 60, just because of the whole life cycle of getting that communication back up to the legal team to put in that claim or even have the tech team know that they can put in that claim. Usually you won’t hear about this unless people are complaining, like, “things are out like last month,” and then “why didn’t anybody tell us in legal?” or “why didn’t anybody tell anybody?” And that—people forget right? Or they don’t know that they have a claim, for example. So that’s a great, great thing to communicate back to your—this actually is a great time to communicate with your tech buyer about their possible remedies.
Mike Whelan Speaking of remedies, in six it talks about an interesting number. It says if the monthly uptime percentage is less than 97 percent for two consecutive months or any four months in a 12 month period, you can terminate the service order. I’m sort of curious what happens between the 97 percent and the 99.9 percent. But what do you think about the chronic outages, I mean, again, I would think out three percent, you know, back in the AOL days, that would be awesome. But now that three percent is actually a pretty good chunk of a month?
Michael Curylo Yeah, so 97 percent on that uptime calculator, that’s twenty one hours a month. So that’s a full day a month that your service is offline. That would be highly detrimental to most—almost any, you know, anybody that’s relying on, say, online sales. So, you know, the 97 percent, all these are negotiable. We could always ask for higher. Often we just ask for the cutoff, you know, if they’re giving us 99.9 percent, then we’re just going to say, if it’s less than 99.9 percent for two consecutive months or any three months in the period, that may be enough that we can’t use your service. And this is something again where I go back to the tech team and say, Hey, if this is super critical, we can’t like— and we can explain that to the other legal team that we need, we need this uptime. Otherwise we have to be able to roll off to another service provider who can meet the uptime requirements. But yeah, I mean, this clause is essential. It’s the only other way to get out, often, of a contract that you’re locked into, if the technology is not working the way that people needed it to.
Mike Whelan Yeah, I mean for my, you know, for—if I’ve got a consulting site with a blog that I just want to be present, you know, the site being down for even a day, there’s not a lot of people other than my mom who’s going to care. Actually, my mom doesn’t care. My mom is never going to read anything that I write. That’s fine. [Both laugh.] But you know, to your point, if I’ve got an e-commerce site and I’ve got a lot of search engines pointing to that thing, I’ve got one chance to give them a positive experience and they might be customers for life. So yeah, that seems like a big—. Well, I’m looking at seven and seven’s got a pretty table and I love seeing a table in a contract that makes it so people can make decisions. But seven talks about the technical response time and the resolution time. Let’s talk about response times and escalating our support needs. What do you think about section seven?
Michael Curylo So section seven, I mean, this is again, I think, a really good table. Somehow legal doesn’t get involved in this too often, like we like to set this up. And I have actually…you know, I can’t even think of a time where someone’s called me for help on responding to a table like this. So, you know, most of the time these organizations, the SAS organizations, are responsive based on these tables and they let you know….the thing is, they’re saying—they’re defining what a critical defect is, material defect or minor defect. And these examples, this definition and the examples are a great way to help define that. So, you know, this critical defect definition and example help our team know what to expect if they are—if the system is really down, the uptime is off and they call. In this example, Tealium is saying they’re going to resolve this in four hours, you know, they’re going to call you back in two hours, resolve in four hours. There is no, for example, there is no kind of breach for this. But this does tie back into your uptime or your uptime SLA so this is a way to help them and you mitigate the uptime requirement. But also it helps your team understand if something’s not critical and they’re not getting back to you within a day or within an hour that, Hey, it’s okay, this is not the end of the world. They’re not ignoring you and it’s not like they don’t care about you. So they’re kind of, you know, for them, they’re setting expectations. From my side. I just want to see that there’s proper definitions. And like I said, normally I haven’t had a SAS provider kind of say like, Hey, that wasn’t a material or that wasn’t critical, and I didn’t get back to you for two days because, you know, we don’t care about you because, you know, they’re making that sale. Their goal is to keep their client. And, you know, I haven’t had a lot of tension around this clause. The earlier clauses there is some tension on, you know, especially being able to terminate. That ability to terminate, a lot of tension. Around this kind of clause, I’ve never had this— you know, a lot of impact on that.
Mike Whelan But presumably again, you’re going to your technical team and you’re saying, Hey, tell me what a critical defect is. You know, what would you guys define as really bad and what’s the proper response time? So it sounds like for this kind of agreement, and again, this is a callback to a conversation that we had with Darlene that these kinds of documents have to be team driven. You know, you’ve got to get together with all the people who are involved in these kinds of decisions and let them guide some of these technical decisions, it sounds like. Well, you know, maybe that leads us to the next question, which is sort of the big picture question, which is why the heck do we need these things? Why couldn’t a lot of these points—a lot of these lines, a lot of these guarantees— why can’t they be built into the MSA? Why do you want to Beautiful Mind it with documents all over your, you know, office wall with strings, tied between them? Why handle it this way? Why do you need an SLA?
Michael Curylo Yeah. You know, it’s an interesting question. I think, you know, some of that’s a contract-drafting question. Some of it’s probably a negotiating question as well. Like, I think having an SLA is beneficial to the customer and a lot of customers should expect it. I’m not sure that all of them do expect it or require it. But the, you know, possibly the reason it’s not tied in is—not always tied in and referenced—is to give them flexibility on giving different, different people, different packages as well as just making the MSA a little bit cleaner, not as, you know, not full of tables and charts and response times. I think sometimes people feel or maybe more like, that SLA is a little bit of a business interaction kind of relationship and that this MSA’s got all the indemnities and warranties and liabilities, and it’s more legalese heavy. Maybe the SLA, they allow their—I’m just going to guess like one of these bigger companies—may allow their sales guy to negotiate the SLA in order to, you know, kind of meet their demands and those tables are somewhat generally accessible. You know, once they set the parameters. So I think it could be a cost-saving measure in a way to just kind of help organize the documents.
Mike Whelan Yeah, I’m reminded of a story in the history of Tetris coming to America, and they—the Russians signed a document that changed part of the agreement with Nintendo. But because it was part of the agreement, it actually changed the entire agreement. Now Nintendo has the ability to make, you know, Tetris on Gameboy, and it totally changed the ownership. It seems like an advantage to this kind of thing is if they’re separate, I can reopen the SLA without reopening the MSA. The MSA, like you said, is a bunch of legal mumbo jumbo that we might want to stay around. But the SLA, it sounds like, is more for the technical folks and you don’t want to open—
Michael Curylo Yeah, and they have evolved. I would say they’ve gotten more, probably, you know, over the last like four or five years that I’ve been seeing these, they’ve gotten more and more higher uptime guarantees, more ability to cancel, more ability—I think everybody, you know, all these tech providers are more secure with their SAS platforms than or they feel more secure, even though we’ve been seeing all these outages recently. I think there was a big one recently with AWS and all that stuff. So I mean, they do happen. These outages happen, but—
Mike Whelan Well, and amazingly, even if it does, I mean, this is just to make people feel secure about a bunch of transactions. Obviously, that outage probably didn’t lead a bunch of people to leave, you know AWS? So you’re not going somewhere. There are other options, but if you’re on AWS, you’re not shifting your whole operation to jump off. Well, that’s awesome. I appreciate you going through this. I appreciate that as we talk more on these episodes that we start to see the relationships between the decisions you’re making in different parts of these documents. So that’s super helpful. Michael, before we go, I wanted to ask you what’s the best way for people to reach out to you if they want to learn about your strategically unemployed practice? What’s the right way to get to you?
Michael Curylo You know, I’m on Avo on LinkedIn. You can just google my name, Michael Curylo and you know, nothing special beyond that. I definitely—you can be in touch with me and look me up.
Mike Whelan Like the A-Team there, if you can find him, you can hire him. We’ll make sure that his information is linked below the blog post over at Law Insider dot com slash resources. And also, if you want to be a guest on The Contract Teardown show and beat up documents like this, just email us. We are at Community at Law Insider dot com. Thank you again, Michael, and we will see y’all next time.
Michael Curylo Thank you.