I’ve been involved in scores of MLS contract negotiations over the past dozen years, working alongside attorneys to make sure business issues are properly addressed – but the environment keeps changing and I must be ever vigilant to make sure new issues are taken into account so that my clients are well protected. Last year I posted an article on the subject – “Negotiating Win-Win Technology Contracts” but it’s time for an update.
RETS (www.rets.org) has been a boon to the real estate industry, but it has added another level of complexity to MLS system contract review.
Consider RETS when defining contractual performance and uptime language. Back when RETS was less critical, one might define system speed, functionality, and availability as part of a performance and uptime guarantees solely in terms of common “front end” functions: this search would take a maximum of this amount of time; these statistics would take a maximum of that amount of time; these functions work substantially as they were documented this percent of the time. Now that RETS is becoming more important for many MLSs, benchmarks for the speed, functionality and availability of RETS must be included in the contract either explicitly or as part of more general performance-oriented language. Also, a process for setting benchmarks and the follow-up step of measurement against those benchmarks must be set.
It’s also important to make sure the RETS feed is available, tested, and validated as early in the conversion process as possible, and that there is a contractual obligation on the part of the vendor to provide this in a timely fashion – ideally at least two months before system cutover. This is especially important if your MLS has been providing delimited data and photographs via FTP but would no longer plan to do so with the new vendor. You don’t want a lot of last minute calls from brokers, IDX vendors, statistics producers and other companies getting a data feed from the MLS – all complaining that there is not enough time for them to learn RETS and transition to it. Even if you provided RETS to these companies in the past, the new vendor’s RETS server may likely have some idiosyncrasies or differences in RETS metadata that will cause problems if brokers and others to whom data is distributed don’t have a chance to properly test the new RETS feed properly.
Lastly, new versions of RETS are always becoming available and each new version has capabilities that the MLS and its members can leverage. For example, RETS now has fairly robust capabilities allowing listings to be input via other front ends – for example broker systems, or forms software, and ensuring that these front ends follow the MLSs business rules. But most MLSs don’t offer their brokers this capability. Why? Because it’s not in the contract. When a new version of RETS become available, the vendor must becontractually obligated to provide it in a specific timeframe, and support the old one for a good amount of time afterward to allow for smooth third party developer transitions.
Those are just a few examples of how a single technology becoming more important requires MLS system contract changes. MLSs should be wary of signing extensions without appropriate review on contracts that no longer have the relevance they did during the original term and should carefully review their new contracts to ensure business issues are addressed. MLS systems are continually changing and interacting with other real estate information systems in new ways (i.e. SSO) and MLS system contracts have to reflect that.
Share this post: