Should I Make SHORT-Term or LONG-Term Commitments to My SAAS Customers?

Have you thought about which parts of your SAAS customer contract commitments should be a short-term, and which parts should be long-term? Well, if you have not thought about it, then how about we do that now.

What Should/Could Be Short Term?

The key with SAAS models is that most* are not perpetual (aka forever) models (like a typical software licensing model where the customer receives a perpetual license to the software), so things are supposed to change along the way. The functionality you provide may change, along with the feature set. Oh yea, this is pretty typical and actually expected for SAAS companies, so don't feel bad about it. So the takeaway here is to think about keeping your commitments as to functionality, features, support  and pricing short in duration (i.e. maybe a year or less and not multiple years). Why you say? Well, things could change, so be careful what you commit to for long periods of time. By the way, if you contractually commit and don't' perform, then that will likely turn into a 'breach of the contract' on your part (aka not a good thing).

• Examples of Long-Term Commitments Requested by Customers: price caps, support commitments, feature and functionality commitments, etc.

What Should/Could be Long Term?

Well in the SAAS model I am not sure there are many really long-term commitments, as the customer is receiving/buying a subscription based offering (something that is time bound). As  I scratch my head to think about what long term commitments you could/should make, I really can't think of any. In fact, maybe that is the answer:  you should not make any really long-term commitments as that is not the model (if you do make any long term commitments, make sure you think it through as things will change). As I said above, the issue of long-term commitments comes up very frequently when licensing software in perpetuity as the customer is paying you for something (and buying something) they could use forever (they are thinking super long term).

So think short-term commitments in your SAAS contracts, and keep the flexibility in your model (to the extent you can). That is what SAAS is all about!

Resources:

Oracle's Long Term Commitment to Support Siebel Products.

Ubuntu Long Term Support Commitment

* Exception: I have seen and worked with some SAAS companies which provide really long-term solutions to their customers, so they will have to address long-term commitment issues, but the key thing is even those are not perpetual models (aka forever).

Disclaimer: This post is for educational and informational purposes only, and does not constitute legal advice.

What a FBI Hostage Negotiator Can Teach You About Software Customer Negotiations.

I read a really interesting negotiations book, and thought about a few takeaways for every software or SAAS company in their customer negotiations (maybe even as a software negotiations best practice).

Background: The book by Gary Noesner came out in September 2010 and is called Stalling for Time: My Life as an FBI Hostage Negotiator. It has all the kinds of things you would expect to find in a book written by the retired head of the FBI's Crisis Negotiations Unit (here is a podcast on the book from NPR): stories about estranged husbands holding their wives hostage, the Branch Davidian shootout in Waco, the DC sniper incident, etc. etc. But what is really interesting, and I think useful, are some pearls of wisdom regarding dealing with irrational people and people under lots of emotional stress. So here are a few things you may be able to use in your next software or SAAS negotiations.

1) Behavioral Change Stairway. I had never heard of this concept before, but it may be useful to you. This is how it works: a) you show interest, b) you respond emphatically (which leads to rapport), and c) only then do you attempt to influence. This makes sense, as during any negotiations with a customer, you need to show interest and listen to them, and then show them you understand their concerns and issues (you don't have to agree to them); only then can you attempt to influence them.

2) Key to Successful Negotiations. Mr. Noesner suggests that it is important to figure out a person's motivation, goals and emotional needs, and then to make use of this strategically. This is relevant too, as having a deep understanding of your customer's (and the person you are working with) motivation, goals and emotional needs can really help to close the deal.

For example, maybe the company has been burned by a previous technology vendor by not appropriately supporting the product. Even if you are the best negotiator, you may not be able to get past this issue as the customer feels burned and abused by that vendor, and they don't want it to happen again. You may have to carry this burden (in some way at least) in the negotiation, and be forced to address the issue.

3) Paradox of Power. Another interesting point is that the harder you push the more resistance you will get. I totally agree with this, and you should definitely remember this in your negotiations. Negotiations are very much about education, and not simply imposing your will on the other party.

4) People Want to Work with People They Like. You probably already knew this, but take this a reminder as the person negotiating the purchase of your technology has a lot more discretion than you probably realize, and if they like you and want to work with you, your deal is much more likely to close.

5) Active Listening. If you don't know what this is, basically it is repeating back to the speaker what they have said or otherwise acknowledging their statement/concerns. Try this, as it takes practice, but really works. Here is a short article that the author wrote on Active Listening.

While software negotiations are not as emotionally charged as a crisis negotiation, it would be worth your effort to try some of these skills if you are dealing with a difficult or irrational person on the other side of the table/phone (even if they are unarmed!). Practice this beforehand though. I plan to try these skills with my kids when they take my TV remote control hostage, as that becomes a crisis negotiation at my house!

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.

 

What Does Your Software EULA or Software as a Service Agreement Say About Your Company?

Interesting question. When a software, software as a service or other IT company sends its written software EULA or software as a service agreement to the customer as part of closing a deal, it is really telegraphing a message about the company and its sophistication. As a software copyright attorney, I actually think about this stuff.

The wrong message/impression would be:

1. Is this company for real?
2. This contract seems too complex?
3. I don't understand what they are providing and what we are responsible for?
4. I need to send this to the legal department or to outside counsel?
5. I will read this later; maybe on Friday.
6. It looks like they bought this on the web for $29.
7. I think they wrote it themselves.
8. I am not sure this company knows what they are doing?
9. Is this their first sale?

None of those messages/impressions would be a good thing or help the agreement move through the process.

 

Here is what your EULA,  SAAS contract should be telegraphing about your company.

1. They are serious about this!
2. I understand their pricing/licensing/services model. It is very simple.
3. They seem to be transparent about the way they work and their revenue model.
4. Looks like they know what they are doing.
5. I bet they sell a lot of this stuff.
6. Looks like they have vetted this agreement, and will stand behind it.
7. This looks fair, and I am going to approve/sign it.
8. I don't see any tricks in here.

So, what does your agreement say about your company?

 

Read your agreement and find out, at least before your customer does.

TAKE THIS QUICK TEST: Read this 2 page IBM NDA agreement and see what it telegraphs about IBM. IBM NDA.

Why aren't your customer facing agreements this simple?

SAAS Agreement vs. Software EULA. Which One Do I need?

As a SAAS lawyer, I sometimes run into the issue of "Do I need a Software as a Service Subscription Services Agreement (SAAS Agreement) or Software EULA?"  In other words, what should I start with (EULA sample or template, or SAAS agreement sample or template). It is pretty easy, as it all depends on the primary item provided. Let me explain.

If a company is trying to define their model in their end user agreement and are unsure of the form agreement to start with, they should figure out if there is any software downloaded by the users, or if they are only providing software-as-a-service through a browser. While many companies have hybrids (some services and some downloaded software) I think it should be viewed as what is the company primarily providing.

• If they are primarily providing software through a browser, but there is some software downloaded (think Go-to-Meeting or Webex), then they would need a Subscription Services Agreement, as they really are in the SAAS business.
• However, if they are primarily providing software which will be downloaded, but there are some services provided (maybe support/maintenance/training/some services through the web), then they would need an EULA, as they are licensing their software.
• Also, some models may be more of a true hybrid, with a SAAS agreement for their online subscription service, and then a EULA for the software that will be downloaded and used with the subscription service..

Every software based company should figure out which form of end user agreement they need, as their customers will be asked about it, and they need to have it right!    A few thoughts, from a SAAS attorney on SAAS agreements and Software EULAs.

What is the Purpose of a End User Agreement (EULA or SAAS Agreement)?

While this may seem basic, from the perspective of a software attorney, it is something that I often discuss with clients. If you think about it, end user agreements (whether an EULA or SAAS Agreement) are arguably more important than contracts in other industries. In most industries, the buyer purchases a tangible product they then own, or generally knows what type of services they will receive. However, in the IT world it is not that simple. As the buyer in the IT world does not ‘own‘ the product and often is unsure of exactly the type of service they will receive, I suggest that the contract is more important in this context and can be very helpful to the selling process.

Let me explain further.

1. The contract should explain/support the business model of the seller, and be 100% consistent with that model.

2.The contract should set the right expectations, so that the customer knows what they will and will not receive, and what the seller will and will not provide.

3. The buyer should be able to read and hopefully understand most of the contract without going to their attorney.

4. The contract should of course address what happens if things go wrong, but I suggest that is not the sole purpose of a contract (see 1-3 above for main purpose).

I realize this is a very simple take, but that is really the point. As a software attorney, I suggest that every IT company should take a look at their contracts and figure out their purpose.

Remember, contracts are too important to be left only to the lawyers!