Austin Technology Law Blog : Texas Technology Lawyers & Attorneys for Copyright, Trademarks & Software Licensing in Houston, Dallas & Austin TX

From time to time, we like to post the thoughts of other clear thinkers in the IT industry.  Our friend, Derek Singleton, over at ERP Software Buyer's Guide, has written the following article and has graciously given us permission to repost it.  We have previously written a post on the same subject and cover similar issues.  You can see that article here.
 

9 Key Points to Negotiate in a SaaS Agreement

By: Derek Singleton

ERP Market Analyst at Software Advice

derek@softwareadvice.com

Derek recently graduated from Occidental College with a degree in political science. He writes about various topics related to ERP software and covers the manufacturing, distribution, and supply chain management software markets. In his spare time he enjoys training in boxing and martial arts.
 

Article:

So you’ve decided to go with Software-as-a-Service (SaaS). It’s easy to implement, easy to use and has a friendly subscription pricing model. You’re psyched.

Then comes the contract.

While SaaS has simplified enterprise software in many ways, you will still need to review, negotiate and execute a fairly complex contract when subscribing to an “enterprise-class” system. In this post, we will walk you through the nine most important things to consider when negotiating your SaaS agreement.

1. Pricing and Discounts
By pricing software as a utility service, SaaS vendors have simplified software licensing considerably. Most SaaS pricing is based on a subscription – monthly or annual payments for using the system during that period. The subscription pricing is typically based on one simple metric (e.g. users, records, projects) that roughly ties subscription fees to the value of the system. Finally, SaaS vendors tend to publish their pricing openly.

Even with this simplicity and transparency, there is still a need to be vigilant as a buyer. For one, don’t assume that straightforward published pricing means there isn’t room for some negotiation. Many SaaS vendors will discount up to 20% to win your business. The bigger the deal, the bigger the discount. Moreover, if the vendor’s pricing metric doesn’t fit with your business model, you might be able to negotiate custom pricing. Of course, you’ll have to make a cogent argument that the standard metric fails to balance price paid and value received.

2. Additional Costs
Another key component to pricing is ferreting out any extra costs early in the process. Published pricing may appear to be a good value, but extra fees can add up quickly. Common additional costs include extra users, customizations, integrations, third-party services, training and set-up fees. Work with your sales rep early in the process to understand what additional charges might apply to your account.

By far the best way to keep the additional costs down is to avoid customizations to functionality and integration with other systems. The inherent complexity in custom development and data integration makes these services expensive. We recommend that you start with the base system, make use of its core functionality and then assess how important the custom features or integrations are to your success. Start small, think big, grow quickly.

3. Term
If you are negotiating with a vendor over pricing discounts, subscription metrics and additional fees, expect to give something in return. Oftentimes, this means committing to an extended contract term. Vendors like longer terms because it provides more predictability in their revenue forecasting. Terms can be as short as 30 days or as long as five years. If the vendor wants a long-term subscription, we recommend that you start with the shortest – probably one or two years.

If you do agree to a longer term of three to five years, make sure you have an out clause. Typically this would provide a window of opportunity to break the contract during a specific time window. For example, it might allow you to walk after one month of using the system but before 90 days. Another example might be the ability to break the contract if certain levels of service are not provided consistently.

4. Service Level Agreements (SLAs)
Regardless of what you pay for the system, reliability is paramount. The SLA is the vendor’s commitment to keeping the system up and running. It is typically expressed as a percentage of “up time.” You will almost always see the SLA represented as 99.9% or thereabouts. However, there is wide variation in how that number is calculated. Many vendors will simply start with 100% and subtract time during which their internal systems reported an error. Most of these SLAs leave far too much wiggle room for vendors.

If this new SaaS system is mission critical, push the SLA issue to see who is really ready to stand behind their service. The SLA topic is far too detailed to delve into all the considerations here, so we’ll refer you to this great blog post on SLAs. However, we’ll suggest you focus most on the penalty for breaking the SLA when negotiating. Usually these penalties are paltry discounts paid out against future purchases. Just pushing for bigger penalties will provide great insight into the reliability of the system.

5. Renewals
Hopefully, you will want to renew your contract. However, given that the renewal process provides an important exit opportunity from a bad contract, as well as an opportunity to re-negotiate, make sure you are still in control when the renewal date comes around. Be on the lookout for something known as an “evergreen” renewal. An evergreen automatically renews your term, usually 30 days prior to expiration.

If you spot an evergreen renewal, ask to remove it. When a company refuses to remove the clause, this is a red flag. The vendor should have to continue to win your business. Not the other way around. Vendors who offer quality services can be confident that their customers will renew based on value, not because the customer forgot to cancel in time.

6. Scalable Pricing
As your business changes, you may want to expand your use of the system; or, unfortunately, you might need to scale back your use if business deteriorates. It seems likely that your vendor will be more than happy to grow your account, but what if you need to downgrade? In the current economy, this is all too common. Present this scenario to the salesperson and know your options.

In most cases, the vendor will not let you downgrade until the end of your term – another reason to keep the term relatively short. However, if you get in a pickle, you might be able to offer to extend the term of your contract in return for lowering the scale of your subscription.

7. Support
No matter how good the system is, you will need a little help somewhere along the way. Knowing what help is included in your support package is very important. A key point you will want to know is how you will receive support. Is it delivered via the web, by email, phone, or chat? Also ask about the hours of support availability. Is support available 24 / 7 or only during business hours?

Moreover, you should know the quality of support included in your package. A valuable metric for support quality is the response time guarantee. The best support organizations guarantee a thirty minute response time for emergencies and two hours in all other cases. Having a dedicated support staff (i.e. a “customer success manager”) is also very helpful. Flesh these points out in the contract. Just keep in mind that high levels of support might cost a little extra.

8. Backups and Recovery
You’ve trusted someone else with valuable business data; you don’t want them to lose it. Luckily, almost every SaaS vendor performs regular data backups. However, some providers backup more frequently than others. Most vendors will backup data either on a daily or weekly basis. If you input valuable data every day, then you will want to ensure the provider performs a backup each day. Others might back up throughout the day.

The way the backups are performed is also important. Some vendors maintain numerous backups, while others maintain only one and overwrite the previous backup. Creating separate entries allows you to rollback to a prior date if necessary. This takes up a lot of space so you will probably have to ask for it specifically. The final consideration with backups is whether the data is backed up in a separate data center. Keeping it at a separate center will add a buffer against data loss in the event of a data center disaster.

9. Data export
Finally, you will want to include a clause about data export. Two things are key here: you should always retain ownership of your data and you should know how to get it back. This will be most important in two scenarios: 1) if you want to migrate to a new system because you are unsatisfied; or, 2) the vendor goes out of business and you need access to your data even before you select a new system.

The method for getting your data back will vary, but common methods include a XML, CSV, and HTML. For the very technical, a SQL export may be better. That’s all well and good but what happens if the company fails? Most SaaS vendors have prepaid the data center hosting company to “keep the lights on” for a couple months in case they go out of business. This will keep the doors open long enough to get your data exported.

In the comments section below, please share your personal experiences with contract neogtiations. Also, feel free to add other considerations that you feel are important.

• Email This
• Print
• Comments
• Trackbacks

This is actually Chapter 4 in a rambling dissertation on why the "Cloud" is what it is.

In previous posts (see here, here and here), we have chronicled the evolution of the “Cloud”, Software as a Service and various permutations thereof and labels therefor. So, now that we think we know how we got here, what do we do now? If you are considering the procurement of cloud services and if you have the negotiating clout to request changes to the vendor’s standard contract, you need to consider some additional things to request.

In addition to the general considerations such as price, term, etc., the following are additional considerations to be discussed with the vendor and possibly included in the governing agreement:
1. In most cases, the vendor owns or licenses the software and the customer owns the data. The customer should always have the right to access and move its data, even in an alleged default situation. This is particularly true if the customer is in a regulated industry.
2. What happens if the vendor goes out of business, declares bankruptcy or is acquired? What happens if the acquirer is one of your competitors? The customer should have an exit strategy and the agreement should be compatible with such strategy.
3. How much responsibility or liability will the vendor assume if the systems are unavailable or if your data is lost? What are the backup procedures, business continuity plans and disaster recovery arrangements? Most vendors’ heads would explode if you requested that they be responsible for the value of your lost data but what are the procedures to recover the data, to back it up and protect it and who pays for that?
4. What kind of investment will the vendor make in software upgrades, enhancements and development? A company for which I once worked pledged 5% of its outsourcing revenue to software development and maintenance. Most companies won’t commit to a specified amount or percentage but a purchaser should review their plans and should have some input, through user groups or otherwise, into the direction of software development.
5. What will you use to determine if the software is functioning in the manner that you expected? What are the warranties surrounding such? Most software providers will warrant that the software will perform in accordance with its documentation but you should request that the basics of any functionality found in sales proposals, demos, RFPs or other material used to sell you on the software be part of the warranty.
6. A purchaser should consider whether the vendor routinely conducts a SAS 70 audit and makes the results available.
7. Since the purchaser has less control over the software used in a SaaS situation than in any on-site situation, a reputable vendor should be willing to provide an intellectual property indemnification that will pay for a legal defense (usually the biggest exposure for a user) and should provide an alternative if use of the subject system is enjoined or interrupted in any manner.
8. The escrow of source code, executables and other information necessary to carry on the processing if the vendor goes out of business or becomes unavailable should be considered. In most cases, this makes the user feel better but because of the long lead times involved, may be of marginal benefit.
9. Performance metrics, also called service level agreements (SLA) should be negotiated. Matters that are important to the user should be identified and reflected in the SLAs.
10. The foregoing are fairly standard components of most outsourcing contracts (which the delivery of cloud based software is, even if it is referred to as a software agreement). Perhaps the biggest divergence by Cloud based solutions from standard outsourcing situations is the question of security, the location of the data and the compliance of the system with Gramm Leach Bliley, HIPAA, Sarbanes Oxley and international data transfer restrictions. If the user is a financial institution or subject to HIPAA then the problem becomes particularly acute and addressing those issues in a manner that the benefit of Cloud computing can be realized by regulated entities is a difficult process.

Now that we've looked at the Cloud from both sides now, it may be the Cloud's illusions we recall and that we really don't know the Cloud at all.  Or it may be just that we are out of cheesy cloud references.

• Email This
• Print
• Comments
• Trackbacks

Ina Fried, from CNET.com, reported this week that Microsoft filed a patent infringement case against SalesForce.com. SalesForce.com is, among other things, a customer relations management (CRM) software company that provides its product through the cloud. Microsoft is no stranger to patent lawsuits. In fact, they were just ordered to pay $200 Million to Virnet X in a patent infringement lawsuit regarding VPN technology. However, the peculiar thing about the lawsuit filed against SalesForce.com was that it was Microsoft doing the suing. Microsoft has only filed 4 suits against competitors. Most infringement issues involving Microsoft commonly end up in some type of license agreement with the alleged infringer. (See HTC) From this Microsoft receives damages and then licenses their technology to the competitor. However, there appears to be more uncertainty surrounding this case.

It is no secret Microsoft is one of the more established players in the IT world. However, Microsoft, along with everyone else has been losing ground to Google. Microsoft and Google are competitors in e-mail (Gmail/Hotmail), browsers (chrome/IE), search engines (Bing/Google), electronic documents (Office/Google docs), and soon in operating systems (Windows/Chrome OS). Microsoft is attempting to chase Google into the cloud computing realm, as evidenced by the direction Office 2010 and other products are trending. The lawsuit against Salesforce.com might be just another way to gain ground. One of the benefits of being in the game as long as Microsoft has is that they have ownership to some of the foundational technology we all use today. Take a look at the subject matter referenced in these patents:

Ø       7,251,653: Method and system for mapping between logical data and physical data

Ø       5,742,768: System and method for providing and displaying a web page having an embedded menu

Ø       5,644,737: Method and system for stacking toolbars in a computer display

Ø       6,263,352: Automated web site creation using template driven generation of active server page applications

Ø       6,542,164: Timing and velocity control for displaying graphical information

Ø       6,281,879: Timing and velocity control for displaying graphical information (the 164 patent above looks to just be a continuation of this patent)

Ø       5,845,077: Method and system for identifying and obtaining computer software from a remote computer

Ø       5,941,947: System and method for controlling access to data entities in a computer network

All of these patent subjects are associated with cloud computing factors. This is no surprise since Salesforce.com is run from the cloud, but it does question what Microsoft will do next? Will they pursue other companies that infringe on the broad patents? Are they trying to get enforcement out of their patents before the Supreme Court returns an opinion on In re Bilski? Are they just trying to get another license agreement?

• Email This
• Print
• Comments
• Trackbacks

With each passing day we are providing more and more personal data to companies through online transactions, social networks, and cloud computing.  Concurrently, there is also a growing framework of laws, regulations and contractual obligations in how companies should treat this information.  These colliding paths are creating what has been dubbed the "The Legal Defensibility Era."  David Navetta of the Information Systems Security Association (ISSA) has written an excellent article outlining this trend and highlighting several important issues that companies must focus on to properly handle data in this new era.

The focus of legal defensibility is understanding how a plaintiff ’s attorney, judge, jury, or regulator will view an organization’s security posture in light of applicable legal requirements.  Under a legal defensibility analysis security choices become legal positions or arguments to be used to persuade legal decision-makers that an organization’s security was legally sound, and increase the likelihood that a judge, jury, or regulator will find a company legally compliant. Ultimately, there may not be a clear “right” or “wrong” answer, but rather a more or less persuasive legal argument/position on security.

To create an effective legal defense, companies should create a security plan with the view that a security incident is a "when" and not an "if."  Companies must create an adequate security policy, abide by that policy, comply with the appropriate laws, regulations, and industry standards; and ensure that its vendors are also handling personal information with the appropriate level of care.   With the advent of cloud based services, the last point is becoming extremely important.  Companies should effectively scrutinize their vendors' security policies and procedures before agreeing to transmit personal information to them.  Focusing on legal defensibility will require more communication and cooperation between a company's IT and legal departments to effectively implement security policies in this new era.  Additionally, for a viewpoint from the security professional side, check out this article. 

• Email This
• Print
• Comments
• Trackbacks