NAR published proposed policies and best practices for MLSs in September. Since then, Michael Wurzer of FBS and I have been blog volleying over a best practice for planning a “native” Data Dictionary compliant MLS system, which has garnered more attention than expected.
The Feedback Phase
When a best practice or policy is proposed, NAR has a comment period to gauge whether these proposals should become official. RESO invited subject matter experts to its conference in October to provide a feedback forum.
Rodney Gansho of NAR, TJ Bolan of CMLS, and Jon Coile of Homeservices of America (NAR’s current Multiple Listing Issues and Policy Committee chair) led a discussion on all proposals. They spent 90 minutes of the three hour Pain Points session on policy. This post will focus on just the one RESO-related best practice.
The Technology Voice Takeaway
MLS execs, technical leads, vendors’ founders and engineers were in attendance. The technologists in the room and on the livestream had plenty to say. Their concerns generally centered on keeping policy focused on outcomes, while leaving internal technology implementation decisions as competitive differentiators for operators of businesses.
RESO doesn’t typically take official positions on outside policies, and this situation is no different. But it’s important for those who weren’t able to attend to hear the feedback the RESO members provided.
The RESO crowd seemed to agree that this best practice needed more research and analysis. It might encourage MLSs down a path that’s not their best use of resources in the short term. They supported the goal of RESO compliant inputs and outputs to MLS systems. They didn’t think specific recommendations about internal MLS technology, particularly databases, should be part of policy.
What is RESO Compliant?
Before talking about what technology should be RESO compliant, it’s important to reiterate what compliance is: RESO compliant systems include RESO Data Dictionary fields alongside unique, local custom fields which are not in the Data Dictionary. A system that uses Data Dictionary fields correctly, and includes custom local fields, is standardized and RESO compliant. (Currently, RESO only certifies Web API services, but other systems can still comply with RESO standards.)
Non-compliance is the use of non-standard field names for standard fields that are in the Data Dictionary. ListingPrice is a non-compliant field because ListPrice is already in the DD. MilesToVolcano is a valid local field which isn’t in the DD.
Unique local fields are encouraged jointly with DD fields. The goal isn’t to cram every local field that’s “kind of close” into a DD field. It’s to match fields which mean the same thing into the standard DD field, use local fields for unique items, and consider adding those unique fields into the DD in the future.
The DD even provides standard fields to encompass local variances. MlsStatus is a DD field which allows for local flexibility in statuses used uniquely in a marketplace. StandardStatus is a rollup DD field which maps local MLS statuses into broader categories for easier display in aggregated data sets. They’re both valuable and compliant.
As is often stated, if the dictionary does it, and you do it, you have to do it the dictionary way. But you don’t have to do everything the dictionary does. And if the dictionary doesn’t do it, you can add to it.
RESO Compliant Input and Output Interfaces
Current State of Some Non-Compliant MLS Modules
(Note: Field/lookup names are tested for compliance. Local display names/labels may differ.)
First Things First: Input, Output, Compliance
Here’s what we heard from the RESO crowd:
- A system with a RESO compliant listing input, user interface, and API output is the ideal. RESO compliant data moving into an MLS interface and out from an MLS interface should be emphasized, while what happens inside that MLS technology system may not be the business of a trade organization or a standards body.
- The overriding story of the week was the new “Sunlight on the MLS” reporting system that will publish the data reports for every certified MLS over the next year. Analysis of current data standardization will be done with this new data to level-set the industry on where we are today.
- With this analysis, compliance with current policies should be the first focus. This RESO reporting will allow NAR, its member MLSs, and their MLS participants to have transparent, thorough policy compliance discussions.
- Making listing input modules RESO compliant is another important step for MLSs to take. This ensures that what agents see going into their MLS is what they see coming out.
- Converting legacy non-standard fields to standard fields through full “native conversions” has created efficiencies for some MLSs who’ve documented their conversions. It is time and resource intensive.
What’s in a Name?
It’s become clear that there are discordant views on what “native” means. In discussions with RESO’s CTO, Josh Darnell, and leadership from our Data Dictionary and Transport workgroups, it has been suggested that terminology should focus on inputs and outputs: “I/O compliant”, or something similar–feel free to suggest names.
With this focus on interface compliance (listing input, MLS user interface, and API output), the technology companies would work with their customers to make their own internal technology decisions.
Getting to the Numbers
Why did NAR start down this path to a best practice proposal? Multiple MLSs have touted their efficiencies gained with their native conversions. It has long been asked what it would cost an MLS, or all MLSs, to make these internal conversions. The answers have always been “a lot”, or “too much”.
A part of this process was a fact finding mission: getting feedback from the technology industry so policymakers can make more informed decisions. We were able to speak with a number of MLS software providers and MLS executives about the cost of conversions.
Answers varied greatly. One estimate was three months for the technology work alone. An MLS estimated one year and one million dollars, as there is significant planning and training involved as well. Of course, that’s the bleeding edge conversion. The process would likely become more efficient.
The more important question is, which MLSs can or should be focused on that work today, and which have far more pressing needs to get their I/O compliance in place?
Continuing the Fact Finding
The industry is healthier for continuing to ask these kinds of questions publicly. Kudos to NAR and CMLS leadership for coming straight to the technology crowd and hearing the tough questions. The transparency in the MLS data space will grow astronomically this coming year. We’re on the right track.
NAR’s consistent mantra in the MLS space in recent years has been: accuracy, cooperation, transparency, efficiency. So it’s important that any MLS-related organization actively engage in the discussion and policy-making process, as these efforts to improve the MLS will not slow down.
Seek out the many publications that come out of NAR’s MLS committees. Attend CMLS’s MLS Matters sessions. Put the timelines when decisions are being made on your calendar. They’re the same, twice a year, every year.
Keep your eyes peeled as sunlight starts spreading across MLS data sets, and we’ll debate next steps in the coming year.