When customers negotiate technology contracts infrequently, the contracts may be short-sighted, incomplete, or inflexible. Such contracts can lead to impasses between the parties, and in turn to rapid vendor turnover and frequent system changes. This is expensive for the organization and unsettling for members. Clareity Consulting negotiates dozens of technology contracts every year and prefers to see contracts that provide a foundation for a long-term relationship. Although no article full of tips can replace a practiced eye, Clareity Consulting’s finely-honed contract language recommendations, and the use of a seasoned technology contract attorney, can save time and prevent error. This article will provide, at minimum, a baseline for contract review.

Define the Product. A strong contract must include a complete product definition by reference, with the documentation included as an addendum. The contract must define every function and interface, so that if the product does not meet expectations, both sides can reference the documentation to see whether the agreed-on performance was delivered. If a Request for Proposal (RFP) process resulted in a detailed description of deliverables, the contract also should reference and include the response to the RFP. The contract should include all definitions of initial customization and integration, or at least define a process by which the contract can be amended to include them as they are discovered. The customer should take the time to document all verbal promises, including delivery dates for specific functionality. If the product is highly dependent on vendor-supplied data, define data update periods and standards for data accuracy. If the contract includes upgrades, it should not lock the organization into a specific version. The product will change over time, and a process to update the product description, along with descriptions of any customizations made for the organization over time, must be written into the contract. 

Define the Service. Products rarely are sold without services; the contract should include complete descriptions of all included services, as well as detailed descriptions of initial and ongoing training for both staff and members. Training descriptions should specify whether training is lecture-style or hands-on, class size, and responsibilities for facilities and training materials. The contract should describe support services in detail, including the days and hours of support for staff and members, exceptions for holidays, processes for emergency staff support, and metrics (such as average hold times, voicemail thresholds, and email and voicemail response speed). Especially if support is a shared responsibility, it may be important to include access to a common support system or knowledge base. The contract should establish processes for bug fixes, including severity classifications and processes for different classes of bugs, reporting, and metrics (such as time to resolution). If the contract properly defines services, service expectations, and reporting methods, the parties should never disagree regarding the service level received.

Plan Implementation and Deployment. To minimize risk, the contract should specify a schedule for implementation and deployment/delivery, including visible milestones, procedures for missed milestones, and project management communication. The contract should always define a testing and acceptance period before delivery, training, and cutover. It also must specify documentation and help files which have been customized to the installation for delivery – definitely before the software is fully in use and ideally before training. If the software is customized for the organization, it probably will not identify all customizations required by the members before they are using the software en masse. Therefore, it is ideal to specify a grace period for changes identified post-deployment, during which time modifications are completed as part of the original price.  

Define the Product/Service Future. The contract must answer many questions to set appropriate expectations for how the product and service will change over time. Which enhancements will be provided for free? How often will enhancements be provided? Must the organization accept new features developed by the vendor and provide them to members? What is the hourly programming rate for custom programming? How are customer requests included as enhancements rather than costly custom programming? What are the processes for enhancement specification, cost estimation, acceptance, and deployment? Does the cost include a certain number of hours per year of custom programming? If the contract adequately answers these questions, it will leave less chance for conflict about the product and service levels.

Set Protections. Most contracts define “uptime” only in terms of availability, but to be meaningful, uptime must be defined in terms of three criteria together: availability, performance, and functionality. What is the use of reaching the MLS server if the search function is broken? If users can search but the search runs painfully slow, the system is basically unusable and shouldn’t be considered “up.” It is important for the contract to link these criteria into a unified definition of uptime. Many contracts specify 99% uptime, which is inadequate for a typical web application! Uptime percentage often is reckoned in terms of “five nines”: these refer to unplanned downtime per year:

A sound technology contract should also include protections such as:

• reasonable definitions of and limitations on performance in the case of civil or natural disaster (“Force Majeure”)
• Representations and warranties
• reasonable security precautions by the vendor
• intellectual property definitions and mutual confidentiality agreements that cover all content the organization and its members enter or cause to be entered into the system
• terms of contract assignment for both parties
• definitions of which provisions survive contract termination (such as confidentiality)
• assurances that the vendor cannot market other products to the organization’s members directly without written permission of the customer
• terms for the escrow of source code
• setup documentation.

Dispute Resolution. The contract must specify a meaningful method of dispute resolution. It must define mechanisms for notification of non-performance and an issue resolution process. It should include a definition of default events, penalties and remedies, and a period within which defects and non-compliance can be cured. The contract should define mediation and/or arbitration mechanism to deal with more serious disagreements, and for the most serious issues, the contract should specify legal interpretation, legal cost-bearing, governing law, and jurisdiction. Monetary holdbacks or termination for cause should be the last resort in dispute resolution.

Getting Your Data Out. It is important to define the mechanisms and costs for obtaining constant access to your updated data for use in integrations, regular access to an organization-owned backup for risk mitigation or disaster recovery, and/or a way to extract and convert your data near the end of your contract.  Ideally, the contract should specify the data in question to include any information or documents that the organization or its members enter or cause to be entered into the system. For an MLS system, this might include not only listing data but photos, virtual tours, video files, contact data, documents, and even calendar and preferences, such as saved search criteria, listing carts, and prospect searches. In this example, does your MLS contract also specify what information – other than listings – will be imported from the old system? As technologies continue to expand their scope, one must eliminate unreasonable limitations on the scope of the data one can contractually convert to or retrieve from the system for use in other systems. It is particularly difficult for a contract to define the format in which data can be retrieved from the system. A delimited file or RETS standard can be used for listing data – but we currently lack an ”industry standard” format for other MLS data or data/documents in transaction or document management systems, contacts, calendars, and similar areas. This means that even if one can contractually extract the data, there’s no good way to ensure that it will be in a format usable by another vendor. Currently the most one can do is to specify existing standards and write the contract to apply other industry standards as they emerge. Finally, if the client requires real-time read-only database or RETS connectivity, the contract should specify it. 

Pricing. Clareity always advises clients to start by selecting the system desired, then consider price. Too often, real estate organizations reject their preferred technology because it is more expensive – but then are dissatisfied with the selected technology and end up spending more money and member good-will converting to a better technology. Negotiate a fair price, remembering that you get what you pay for. If your technology partner isn’t making a decent profit, chances are your organization will get inadequate service, the vendor will lack the money to perform adequate R&D, and may even go out of business. The contract should try to anticipate any “extras” that may be needed and specify all costs explicitly. Ideally, the contract’s pricing should be variable to protect both parties. For example, it is no longer unusual for contracts to tie pricing to Consumer Price Index adjustments. Also, if the technology’s pricing would vary based on the number of users, the contract should include a grid showing the price differences if your membership size changes.

Conclusions. Aim for a win-win contract that protects both parties. Watch out for contract language that does not adequately define product or service, account for change, or identify dispute resolution methods. Inflexible contracts often lead to dissatisfaction that is difficult to resolve through renegotiation and to relationship failures that hurt both parties. The goal of this article is to help you understand risks in your current contracts and identify some areas where you can improve your new contracts -- but no simple set of tips can replace a business consultant’s practiced eye, the time savings created by using finely-honed contract language, and the use of a seasoned technology contract attorney. I negotiate enough real estate technology contracts to be able to say with assurance that the devil is in the details, and a single word can make all the difference between a bad and a good contract.