Briefly

TRANSCRIPT

00:07
Adam Stofsky
David, I want to ask you about a kind of contract that I think is fairly specific to technology, but I could be wrong. And this is something called an SLA or a service level agreement. Can you kind of walk us through what that is?

00:22
David Tollen
Yeah, it is pretty unique to technology. Not entirely. It's a useful concept that other industries use too. SLA stands for Service Level agreement, but the name is actually a little bit deceptive. An SLA isn't usually a separate contract. It is not a standalone agreement. It's in most cases it's a clause in a contract. So you see them most often in the technology world. In cloud services, the vendor is providing software as a service infrastructure as a service platform as a service, AI as a service. And the SLA is an attachment to that contract. It could even be a section in the main body, but usually it's an attachment. And what it does is it describes a few things. One way to put it is that the technology will not do so. For instance, the vendor promises four nines.

01:21
David Tollen
That means they're promising that during 99.99% of the month the technology will be up and running. And so they're promising that less than that won't happen. And if it does work less than that, usually the SLA also has a remedy. And the typical remedy in technology agreements is the customer gets not a refund. Vendors don't like that. The remedy is usually a credit against future bills, which for the vendor is real nice because it means to take advantage of the remedy for something going wrong. You got to stay a customer, you got to stay on to next month to get that credit. But that's at a very basic level what service level agreements do.

02:05
David Tollen
There's a lot of other sort of moving pieces, but the most common is that four nines or five nines or that promise about how much of the month usually the system's going to work and credits if it doesn't.

02:17
Adam Stofsky
So it's basically like a promise for software people selling software. It's a promise that like, hey, this is going to work most of the time.

02:25
David Tollen
Yeah, in a weird technical way, they're actually not promising that it will. Maybe elsewhere in the contract they have a warranty where they're actually promising it will, they're warranting the system will materially conform to whatever its specifications are in the service level agreement. Arguably what they're really saying is we're not actually promising it's going to happen. We're saying if it doesn't happen, we're going to give you these credits. It's a sort of subtle distinction and it's rarely talked about. But the reality is a lot of service level agreements even say your only remedy for these failures described here in the service level agreement is this credits. In other words, there's no right to damages, there's no right to terminate. There's. There's an attempt on the vendor to say vendors part, to say essentially the credit is it.

03:21
David Tollen
And so you could argue they're not really promising it's going to work, they're just promising credits if it doesn't. But it works well. Vendors don't like to give those credits. It's embarrassing. It's paperwork, it's loss of money. And so it is a good incentive for the vendor to keep the system working well.

03:39
Adam Stofsky
Yeah, it seems to me that, you know, the remedy for software being down a lot is that the customer just goes to a competitor. But I guess this is just a good roadmap for what expectations should be within centers for the vendor to do a good job. Is that right?

03:55
David Tollen
Yeah, that's right. And hopefully if the customer is smart, maybe they've accepted the idea that the credits are the only remedy for these failures, but they've also retained the right to terminate, you know, if they're getting too many failures. So maybe you're getting credits every month and lots of them, you don't really want the credits, you want the system to work. So often you try and retain a right to terminate too, and then you do go to a competitor.

04:23
Adam Stofsky
Can you take a little bit of a deeper dive on SLA you talked about? Is it the five nines? The four nines? What else do you see in these things? That's fairly common.

04:36
David Tollen
Yeah. So usually at the top is that four nines or five nines. But then there's other stuff that SLAs cover. So sometimes they'll cover other technology metrics than just is the system up and running? Like there's terms like latency and jitter, things that very confusing language that most of us don't use every day. But they are talking about the speed of communication between two points, for instance. Or there might be terms like transaction processing speeds. Let's say your software as a service is supposed to process some sales or it's supposed to give answer to a prompt. If it's artificial intelligence, that's sort of AI vocabulary, how fast is it? And you might have an SLA clause that says it's going to give that answer within X split seconds. Every time it's going to process that transaction within X split seconds.

05:37
David Tollen
And that's another thing where if it doesn't, there could be a failure that prompts credits. The other thing that you very often see in service level agreements is, gets more to the human side. You see something that are called error levels and response times. So if we get a level one error, a really severe bad error in the system, we're going to get a call, or we're going to get a call back. Maybe we submit a trouble ticket, we're going to get a call back within 10 minutes or we're going to get a call back within an hour. You often have some kind of description of the types of error and how fast the vendor is agreeing to respond to it. And if the vendor doesn't respond, that's a, doesn't respond that quickly, that's a failure.

06:25
David Tollen
In some cases, you know, the vendor, if they're very brave, they might also promise how quickly they're going to fix the error. A lot of times vendors want to avoid that. They don't want to make a commitment about that. They want to make a commitment about getting back to you, getting a proposed fix in because they're not sure how fast they're going to fix it. But you could have fixed times also in a service level agreement. Those are all additional terms that you tend to see in there.

06:53
Adam Stofsky
So are actual customer service obligations put in an SLA or does that often go into a different contract term?

07:02
David Tollen
In theory, the only real customer service obligations that go in a service level agreement are those error response times. But there's no hard and fast rules. I mean, to me it's sort of better drafting to put it somewhere else to say, you know, you're providing tech support to the customers of your software as a service. And so there's people available by phone between 8 and 6 and they can answer questions about how to use the technology and how to address problems. That's conceptually kind of different. That's about humans and the service they provide and less about the speed of technology. But the two can overlap. As I mentioned, SLAs don't just address how technology works. They usually address how quickly humans will respond to a failure. So you could put more human terms in an sla. There's no hard and fast rules.

07:59
Adam Stofsky
Okay, very interesting. I'm glad we don't have to sign SLAs. As parents, I'll tell you that I think my children would like a better response to the quick.

08:11
David Tollen
Yeah. Or I think my kids would say the SLA is about the services I provide to them and probably not adequate. And I owe lots of credits for failures.

08:23
Adam Stofsky
I think I owe lots of credits for failures and delays.

08:25
David Tollen
For sure. Yeah. All right.

08:27
Adam Stofsky
All right. Thank you, Dave. That was very interesting.

08:29
David Tollen
Thank you.