A few more thoughts:
Understand the Industry Standards
Know the industry standards. I already talked about limitation of liability and indemnity the last time around, but this applies to a lot of other terms too. The SaaS/cloud industry is not that difficult to understand. Want some easy advice? Log onto salesforce.com and read their master services agreement. That will give you an idea of what the rest of the industry is like.
IP Related Issues
Two more things I want to highlight: first, IP ownership. A lot of procurement departments think that they can put SaaS vendors on their own paper, which often include work-for-hire provisions that would force all IP to become the customers. Hold your horses: SaaS is all about a company hosting the application for a client in their environment. The industry standard is that where a company owns the infrastructure, does the development, and maintains it all, then the SaaS company owns all rights and licenses it to the buyer (or provides access to the buyer).
Some vendors have gone to the other extreme and starting claiming that SaaS services have nothing to do with IP, and not granting any license or even an IP related indemnity. That’s absolute nonsense, but it’s also a response to buyers trying to grab IP. This includes source code escrows. These are not, and should not be, standard for a SaaS/cloud contract.
SLAs and credits
The standard in the industry that the client or customer has to make a request for SLA credits. This is and has always been the norm. I’ve always needed to monitor my web hosting service at Site5 to make sure that I am above the 99.9% uptime, and when they are below, it’s my job to request the credit. But for someone who isn’t familiar with the industry, this is often what happens in discussions:
Buyer: So you’re telling us that if there is downtime, we need to request a credit?
Vendor: Yes.
Buyer: Don’t you monitor downtimes on your end?
Vendor: Yes.
Buyer: Then shouldn’t you just give us the credit automatically?
Vendor: No. You need to request a credit.
Buyer: (*silence*) That doesn’t seem right. Y-y-you should do that for us… It’s-It’s-It’s your job to do it. (In a tone has been increasingly akin to, “that’s not fair!”)
Vendor: I’m sorry you feel that way, but we just can’t do that. You need to go through our process.
Let me give you a couple of reasons why the industry doesn’t: 1) if you didn’t notice the downtime, and you’re a business, the truth is that it probably didn’t hurt your business. If you’re a business where downtime is critical, then you’ll know very soon when something is down and have a Priority 1 ticket into client services. 2) IT normally tracks server uptime, not finance. Finance departments are overburdened in most companies as is—no one is going to ask finance to track refunds on top of that when most finance departments I know have a hard time just paying the bills on time. It makes zero business sense. 3) Businesses don’t want to give revenue away. On the flip side, it’s hard enough to get clients to pay on time.
Bottom line: get used to it, it’s the way the industry works.
In SaaS, there is usually no “burn-in” period, like some would have you believe. Mr. Classen’s article states:
Service-level credits should be apply after an initial “burn-in” period during which the services provider can bring the company’s systems online without worrying about financial penalties. The “burn in” period should be no longer than 60 days…
Now I appreciate the pro-company stance, but this is a remnant of the 80’s and 90’s where burn-ins were required on PC hardware. There is no burn in for most SaaS and cloud services. (Yes, new servers can be problematic, but that should be part of downtime in SLA) Either you should be sandboxing or testing in a test environment or before going live, or you expect the thing to work (like SuccessFactors). If you’re migrating to Amazon Web Services, you better be testing those servers before flipping the hard switch.
I’d love to have this clause in my company’s contract–but we handle payment card processing for Clients. Imagine if we had a 60 day burn in during an MMO launch—a Client could lose millions on our downtime easily.
Don’t believe everything you read.
Next time, I’ll try to give some more practical advice.
