How to Increase Revenue in an Economic Downturn

 

Software vendors can increase their revenues during this prolonged recession.  How do these vendors make lemonade out of this lemon of a global economy?  They must look to their installed customer base.  Mike Smerklo, President & CEO of ServiceSource, has written an OpEd piece for SandHill entitled Delivering Predictable Revenue Streams.  ServiceSource is in the Service Performance Management business which aims to increase their clients’ service revenues by increasing the number of customers on maintenance and increasing the dollars spent on maintenance.

In economic downturns, such as we are now experiencing, customers defer new product purchases.  Although this is not a positive for software sales, it does increase the value that can be placed on enhanced maintenance and support services.  Software companies must continue to invest for the next generation of products, but enhanced maintenance today can drive revenue and provide the reliability that customers need.

Smerklo cites a Gartner study that the potential market for maintenance and support is over $180 billion annually and that only $150 billion is spent on maintenance every year.  It is easy to see that there is another $30 billion in potential maintenance and support not being tapped.  He increases our lexicon from the more familiar term “market share” to a new term he labels “service share”.  This is the total maintenance revenues available from the installed base.  And he lays out for us a complete 4 part service management strategy as follows:

1.     Technology Platform:  The vendor’s CRM must measure transaction data on the maintenance side down to the granular level.

2.     Business intelligence:  The analytical capabilities of the vendor must be able to show what the customers are buying and why some are saying no.

3.     Customer contact:  Must have the ability to help the customer extract the most out of their solutions.  This will enhance the relationship and could pay dividends down the road on renewals and purchases of new product.

4.     Benchmark against the competition:  Need to know your specific service metrics in comparison to the industry overall.

The Service Performance Management alternatives are as follows:

1.     Do Nothing:  All focus on product revenue and market share can come back to bite you especially on renewals.

2.     Build your own service management platform:  This could be costly.

3.     Partner with a Service Management Performance provider:  They have the expertise and the capabilities to manage on a global basis.

 

 

Side Letter: What Role Does the Parol Evidence Rule Play In Subsequent Writings?

 

This article is meant only to posit the question above in relation solely to an existing Master Service Agreement (“MSA”).  For a very good discussion of the Parol Evidence Rule please see Scott Unger’s article What Is The Parol Evidence Rule?  Unger covers all the bases in his article.  He provides the pertinent citations where the court explains the purpose behind the rule and he also cites case law discussing the policy concerns supporting the rule. 


"The Parol Evidence Rule is a substantive rule which states that whenever contractual intent is sought to be ascertained from among several expressions of agreement by the parties, an earlier tentative agreement will be rejected in favor of a later expression that is final."


Or more succinctly


"the final agreement made by the parties supersedes any terms discussed in earlier negotiations"


Unger also points out that a good draftsman should always include a “merger clause” in the contract.  This is usually a clause found near the end of a contract, probably in a miscellaneous section, simply stating that the agreement is the final and complete expression of the parties to the agreement.  It is there to aid the court.  What should also be found in that merger clause is a statement allowing for modifications to the contract.  The language should read something similar to the following:


“This Agreement may be modified only by a writing signed by both parties.”


Let’s now consider the question above in the title of this posting.  When asked to make an adjustment to the MSA, one automatically thinks of an amendment or perhaps a Statement of Work (“SOW”) if that is how changes are contemplated.  A change can also be easily accomplished through a Project Change Request (“PCR”) form if such a form was contemplated in the initial MSA and suits the desired change.  These are all standard ways to change the original MSA.  However there are times when your client requests a change be accomplished through a Side Letter.  And so the question we must ask is, “Why?”  This is of course a red flag to the attorney.


First you must assure yourself that there is no fraud involved.  At the slightest hint of any fraud the attorney must stop at once.  The next steps are quite involved and I direct you to the Model Code of Professional Responsibility.  I am not an expert in this area, however I did come across a very interesting article by Boris Feldman entitled WHAT TO DO WHEN YOU FIND THE SIDE LETTER: GUIDELINES FOR CEO’S, CFO’S, AND AUDIT COMMITTEE MEMBERS IN INVESTIGATING ACCOUNTING FRAUD.  Feldman lays out a step-by-step approach which could be very helpful.


So absent fraud, the question remains “Why a Side Letter”.  I do not think there is a definitive answer to this question.  In my experience it could be that business people are more comfortable with a side letter.  It could be the “that is the way we do business” mentality.  There could be a distrust of lawyers and contracts.  Also the lawyers are usually seen as placing roadblocks in front of the deal and so for expediency sake the business folks prefer a letter.  In their minds it is quicker and easier.  Of course there is the ever popular notion that the cost would be prohibitive.  A more formalized document just looks more costly.


One’s knee jerk response might be that the Parol Evidence Rule prevents the introduction of such a Side Letter in the event that a dispute regarding the Side Letter finds itself in the courts.  But as Unger correctly points out, the exclusion of all evidence of discussions or agreements purporting to change the existing agreement pertains to prior writings and expressions.  I also have seen that the exclusion applies to all prior and contemporaneous writings.  In the question I posit above I state that the MSA is an existing agreement; and therefore, the Side Letter contemplated is a subsequent writing.  The mere fact that the date of the letter is later than the effective date of the MSA should be sufficient to allow the Side Letter into evidence to prove the modification.  However may I suggest the following:


• First and foremost assure yourself that no fraud is involved in the request.


• Absent fraud, then insert an “incorporation by reference” clause into the contract. This should allow the multitude of protections existing in the MSA to be applicable to the matter discussed in the Side Letter. It could be as simple as “This letter is hereby annexed to and made a part of the Agreement specified above.”


• Insert an Acknowledgement at the end of the letter after the signature block. I usually use the following language, “Please acknowledge your acceptance of the above terms by signing and dating this letter in the spaces provided below and returning a signed original to me at the address as provided above.” This helps us meet the “…may be modified only by a writing signed by both parties” language that should be found in the merger clause.


I’d like to know what you think. Have you encountered this type of request? Does the incorporation by reference and the use on an acknowledgement suffice? Is there more that needs to be inserted into the Side Letter? Should we simply say “no” to any Side Letter?
 

 

Checklist: Preparing for the Master Service Agreement

 

I have stated in an earlier article, Checklist Before Outsourcing Your IT, the high value I place on the use of a checklist before drafting an agreement. It is also obvious that a tool such as a checklist can provide invaluable assistance to the IT Project Manager when preparing for the implementation of a newly purchased software suite. In my research I have found a very interesting article in Wisconsin Technology Network News, WTN News, by Richard Marcus entitled Six things to consider before a major software implementation. Marcus presents a very useful list in his March 2006 article. Admittedly this article is over 2 years old and in this fast-paced high-tech environment the concept of what is “new” and what is “old” takes on different meanings from our traditional understanding of the terms. However, I believe his advice stands the test of time regarding this subject matter.


Marcus begins his article by cautioning the buyer on the critical nature of the purchase and that concentrating solely on the pricing could be a perilous mistake. He then provides his six points that the purchaser should take into account before forging ahead with the implementation. A brief synopsis of these six crucial points is as follows:

 

  • The Software Vendor and the Customer are partners in this undertaking. Both parties must bring their knowledge and skills together in a committed relationship. Success depends on having sufficient resources. The Vendor should already have their team ready and the customer should have a comparable team prepared to spend the estimated time needed for the project. See also the February 15, 2008 post to this Blog, The IT Worker Shortage: Practical Considerations for Tech Buyers

 

  • Communication is key. Insist that the Vendor set the correct expectations. Talking is not the only art form in this communication process. Listening is essential. Ask questions and let those answers lead you to more questions. Strive to learn not only what the software can do, but also what it cannot do. In the past, I was a consultant for a large software vendor. As a newbie on one of my first implementations, I learned the catchphrase consultants were often overheard to say to the customer when discussing the software’s capabilities, “The salesman said it could do what?” Make sure your requirements are well known and can be met.

 

  • Pricing. Marcus’ admonition above is still valid. Price is not the only factor, but it is still a factor nonetheless. Negotiate a payment schedule that is tied to clearly defined and identifiable milestones that are realistic. Holdbacks dependent on successful acceptance test results should be discussed and inserted into the contract. Too much money upfront surrenders too much influence to the vendor. I was interested to read that Marcus warns the reader not to be swayed by the software vendor’s pleas and worries about revenue recognition. In my career I have discussed this many times, but only in a software license agreement negotiation. A Master Service Agreement is usually a time and materials agreement and hence revenue can only be recognized as it is earned. A Fixed Fee arrangement is a totally different case and will be a topic for a separate post to this Blog.

 

  • A separate Master Service Agreement should be drafted. Marcus points out that it is common for the license agreement itself to contain sections pertaining to services such as ongoing support and maintenance. However, these services are not directly related to the implementation. I have come across license agreements that purport to contain the implementation services section within the license. This should be avoided. His article deals with a major implementation and so most major software developers and vendors already have their contract model set up to have a separate license agreement and a separate Master Service Agreement. This is the preferred approach. An implementation section contained within a license agreement may not address all the salient points of an implementation and also may not be clear and unambiguous on other necessary elements.

 

  • The Master Service Agreement should contain Service Levels. This is a very important item and one that should not be overlooked. A service level agreement (“SLA”) can take the form of a separate schedule attached to the license agreement. Alternatively and depending on the complexity of the requirements of the customer, a separate SLA may be more appropriate. In the SLA the customer should make certain that all of its requirements that were fleshed out during its communications with the software vendor (see point 2 above) are memorialized for future reference.

 

  • Know the use limitations in the license and plan accordingly. Many software licenses are User based pricing. Many vendors are willing to provide some form of price protection for future purchases of users. The Customer should verify that no further implementation work will be needed if more Users are added. However, if the Customer is faced with product based pricing and is not purchasing the entire software suite of products, then further implementation work will be needed if more products are added. This possibility should be fully explored and the consequences understood in the event of future growth.

Marcus concludes his article by stressing that the Customer must do their due diligence on the front-end. With proper planning the Customer can avoid mission-creep and other costly mistakes. Once a major implementation is set in motion it becomes cost prohibitive to put a complete stop to it or redirect your efforts towards another project.