A RESO Case Study
Tech Innovation Initiative Accelerated from 5 Years to 8 Months with Visionary Leadership and the Power of RESO Standards
Background
In late 2022, the leadership team from Doorify MLS (DMLS) – formerly known as Triangle Multiple Listing Service – envisioned a technology overhaul for their organization after analyzing its technology capabilities on the front end, on the back end and through distribution services.
The front end of MLS software platforms includes the user interfaces where brokers and agents manage their searches, reports, customer registration and listing alerts.
The back end is where data is processed, stored and managed.
Distribution services are where brokers, agents and approved vendors access data feeds. For DMLS, the data is accessed through Application Programming Interfaces (APIs).
DMLS serves over 14,000 brokers and agents located primarily in North Carolina’s Research Triangle, which is anchored by the cities of Raleigh, Chapel Hill and Durham, and was setting out on multiple highly technical initiatives at the same time.
In addition to the tech overhaul, DMLS was in the process of acquiring an MLS, managing growing data shares with other MLSs, converting its back end to a standardized format and creating “a front end of choice” option that included systems from multiple MLS software providers for its users.
DMLS had a single technology vendor for its front and back end systems, including data integrations with other software products. For data distribution to outside entities, DMLS used a different vendor’s API service. DMLS’s data and distribution were not yet certified on the real estate industry’s technology standards of the Real Estate Standards Organization (RESO) Data Dictionary and Web API.
Future Needs
DMLS leadership considered future changes in the industry that would require them to support new customer needs. During the strategic planning process, they addressed how the organization would adapt to changes through industry research, customer outreach and scenario planning.
The leadership team recognized that they had a single vendor-dependent pathway to each of two critical growth channels: integrations with software partners and distribution to data customers. Single points of failure in these channels were viewed as threats to the organization’s growth plans.
Vision
The organization imagined the MLS in a future state, with rules-based workflows that were cost efficient, agile and strengthened by industry standards. The most practical immediate benefit would be to create more product choice for customers by empowering its own back end data to integrate seamlessly with the three most-used MLS software front ends: Flexmls by FBS, Matrix by CoreLogic and Paragon by ICE (formerly Black Knight).
DMLS also envisioned a more valuable and consistent experience for its professional and consumer customers by using end-to-end RESO standards on its platform. Doorify MLS would ensure that its data had standard field names on incoming data forms and the same fields published out to MLS reports and data consumer feeds.
Whether the future brought a new consolidation with another MLS, a data share, a collaboration or an integration, DMLS would have the technology foundation to support its vision.
Requirements
Two phases were critical to ensure that existing data and new data would be capable of supporting the initiative:
- Integrate and convert back end data across existing platforms into the industry standard RESO Data Dictionary format, converting one property class (residential, commercial, rentals etc.) per year over five years
- Create a set of forms that govern all new inputs and changes to data entering the system, conforming to the RESO Web API Add/Edit and Data Dictionary 2.0 standards
Properly aligning all property data records involved going through 1.5 million real estate transactions conducted over 25 years on four different MLS platforms. Over that time, MLS rules had changed significantly, and data fields had been added, renamed, reconfigured and removed.
Order from Chaos
The data was an untidy patchwork, but the Data Dictionary format provided an objective roadmap to the necessary alignment of all data sets.
Input forms used in the past were a proprietary solution from a front end software vendor. With DMLS’s initiative requiring that only one set of forms with the same standard requirements would be allowed to alter the underlying data set, the Data Dictionary again became a guide for creating new forms that aligned incoming changes with existing back end data.
Capabilities
MLS organizations have vast differences in staff capabilities. The lack of available, technically capable staffing resources can create a high level of difficulty in executing MLS collaborative efforts. DMLS has a significant technical team, which is only common within the largest quintile of the 500 or so MLSs in the U.S. real estate industry.
Other MLSs, like some of DMLS’s partners, have as few as one employee on staff. So in these kinds of M&A or data share initiatives, the larger MLS often takes on most of the analysis and legwork. That work includes planning and communications between MLSs and vendors, as well as getting time commitments from the technical employees who can grant access to systems and make changes.
Most MLS systems have a mix of data fields. Some fields conform to RESO standards, while others are considered local fields, which are custom items that fit the local market but aren’t yet encompassed in industry wide standards.
Other fields are often nonstandard versions of standard fields. For example, the industry standard of List Price might be called “Ask Price” in a proprietary MLS system. These fields can be mapped to the standard so they can be combined accurately as data sets are joined between MLSs and their vendors.
Execution
DMLS guided the process of mapping local and nonstandard data fields with its collaborators. Much of this process is about finding acceptable compromises between organizations in custom local variations.
Finding the right MLS vendor contact to help with the process often requires a puzzling amount of effort. The vendor’s technical staff who can access, manipulate and report on MLS data are not always known by the MLS staff, and it can take a week or more just to track the right person down and schedule data delivery.
This output data often comes in what is known as a Real Estate Transaction Standard (RETS) data dump. RETS is an older format that must be analyzed, field by field, to understand how to make it match current standards. This process can take weeks or months, depending on the collaborators.
Analysis
While analyzing and making adjustment plans for these nonstandard data sets, DMLS realized how much easier this process would have been if there had initially been standardized API outputs from each of the participants to use for alignment.
In hindsight, DMLS was convinced that RESO’s Alignment Reports were designed for this exact situation. Data sets between organizations are only compared after formatting to the standard, creating clear comparisons and contrasts.
What took weeks to accomplish with traditional tools and processes would have taken five minutes if the parties were using RESO’s alignment reports. This was a key takeaway by DMLS for future planning.
The Acceleration Point
The initial plan was to convert one property class to the RESO standard per year, starting with rental listings. This would allow for a transition for customers over a five-year period. Six months into the work, though, that plan no longer made sense.
It was evident that doing an immediate full conversion of all classes to standards was the only way to create maximum efficiency. It would have greater upfront costs, but it would turn a five-year project into an eight-month project.
With this new direction for the greater initiative, DMLS’s plan had shifted:
- Standardize the entire back end and get it certified
- Integrate it into the three front ends
- Onboard customers into their front end of choice
DMLS needed to select the technology provider for the initiative’s data management foundation. To execute expeditiously and consistently, its board of directors and staff analyzed vendor technical capabilities, utilization of RESO standards and the resources made available at the time.
This research phase through early 2023 culminated in the selection of FBS as the technology vendor that aligned with DMLS’s requirements and vision of automation for the back end.
Conversions are Challenging
DMLS’s team went through intense analysis, coaching and negotiation with its data partners to create harmony between the organization’s newly standardized back end system and each of its access points: data shares, common interfaces and newly implemented products.
Conversions of this scale are somewhat rare in the MLS space. Though they are highly attractive for long-term capabilities, they are also daunting to MLS operators, as they affect the way customers’ businesses operate in real time.
Because conversions can have a heavy effect on the day-to-day activities of customers, causing frequent negative feedback, many organizations avoid this kind of work unless it is absolutely necessary.
So there was a lack of previous case study material for DMLS’s team to rely upon. And, as expected, surprises arose that the team needed to independently navigate.
But DMLS’s overall philosophy of aligning with an open standard allowed it to stay consistent, keeping negotiations focused when impediments arose. The third-party neutrality of the RESO Data Dictionary provided the pathway and guardrails for answering the vast majority of questions.
Despite the conversion’s heavy lift, DMLS completed its work nearly on schedule for the eight months it had planned, remarkably faster than the initial five-year plan.
Outcomes
With a RESO-standardized data set deployed into FBS’s back end system, the DMLS back end now powers its customers’ Matrix, Paragon and Flexmls front end interfaces. It can turn on and off new MLS tools à la carte with less reliance on the availability of other vendors. DMLS believes that this standards-driven approach creates the momentum for vendors to increase competition with each other to deliver more value.
The competitiveness of the new environment caused more direct involvement from front-end software vendors with customers. As vendors needed to make their product features and benefits clearer, they engaged at a higher level with the subscribers.
DMLS customers now see the same field names on their data input tools as they do in their MLS system interfaces, as well as in the reports and applications they share with their consumer clients. DMLS, as a business, can now compete on services provided for its customers, not just access to data alone.
Both DMLS and FBS confirmed after the work was done that using the Data Dictionary as their Rosetta Stone was critical. In hindsight and with user feedback, they said that in future conversions they would simplify inputs, with fewer fields and lookups in the input forms that might not be relevant to the local market, streamlining the experience even more for users.
DMLS, as a business, now sees itself competing on services provided for its customers, not just access to data alone.
User Feedback
User inertia is well documented in MLS software systems, as the general preference of agents is not to change current processes. But this level of product choice is rare, so tracking future changes will bring more insights.
DMLS offers customers the opportunity to choose one or multiple front ends to use, and there is a monthly cost for each. Among 14,000 customers, 660 of them chose to keep two front-end platforms, pointing to a desire by customers to try new systems and have choice available. These dual subscriptions resulted in an annual revenue boost of more than $180,000 for DMLS.
With any technology conversion, there are challenges. In MLS software conversions, changing customer behavior can be as challenging as technical change.
Although DMLS’s conversion allowed all customers to continue using their favored current MLS software platform, some negative feedback was still received.
A small number of customers questioned why the organization would devote resources to the initiative, as they did not understand why any current customer would want to change platforms.
When offered the new front-end platforms, 20 percent of DMLS’s users opted to change to a new system. This could be because these users were already familiar with the alternative interface from a previous MLS prior to M&A or via another data share.
Technical Response
Conversions to standards compliance often require changing data field names. While this generally happens in the underlying data that users do not see, sometimes the decision is made to change the labels that users do see in their input forms, applications and reports so that they all match. This was the case with DMLS’s goal of what is often called in the industry a “native” Data Dictionary experience.
While customers sometimes push back on these changes to well-known local field names, implementers like DMLS choose to use the internationally accepted standards documentation from RESO as a third-party backstop to assure customers that there is a benefit to the changes.
Future Considerations
DMLS noted some factors that would improve this process for other organizations. Focusing on unique IDs for data elements, in particular, would be hugely beneficial when working with multiple vendors.
RESO’s unique IDs for properties, people and organizations are examples. When a listing, a broker or an agent is created in an MLS system without an ID that is unique across different systems, data collisions become inevitable.
Other MLSs planning to combine sets of data across MLSs and different systems should consider whether adding these kinds of unique IDs to their data sets today could provide acceleration and efficiencies for their data collaborations in the future.
Additional Standards Usage Could Help
New standards could help as well. When there are changes in roster data, media, documents, etc., all systems need to know if these items are public, private or in another restricted status. Moving them between different vendor systems would be greatly improved if those statuses were identified and documented in a standard way.
Even the same data set, coming out of a certified API service, might have a slightly different shape to it depending on a vendor’s implementation. The level of prescriptiveness of a standard is always a back-and-forth negotiation in its creation, and DMLS viewed this as an opportunity to continue leaning toward “tightening the screws” of the standards even more.
Native as an Investment
RESO doesn’t dictate how an organization is set up at the database level or on its user interfaces. RESO simply certifies the interface that it sees at the API level. Organizations applying for certification are not required to go through an internal conversion process to become compliant.
But DMLS’s experience showed them that using the Data Dictionary across all of its systems was the most efficient way to implement it. Putting field names and data types in place according to the Data Dictionary simplified every other piece of work. Using those same names for input forms and output reports made for a consistent process of training users on the new changes.
MLSs and data partners planning collaborations and data alignment can review the experiences of companies who have made a “native” Data Dictionary conversion and consider whether this process is right for their individual goals for long-term outcomes.
A Future Powered by Aligned Data
DMLS has created one of the most flexible and agile MLS data structures in the industry. At the end of the process, its leadership team said that if they had to do it all again, they would have started by immediately converting every system to the RESO Data Dictionary.
With DMLS’s front end of choice phase complete, additional MLS services will benefit from the data alignment initiative. All data distribution services will be upgraded from legacy RETS to modern RESO-certified Web API services.
Creating an independent API is also a possibility to go alongside current API services. Integrating standardized member and office data with the Association Management System (AMS) is up next.
More front-end options are coming, as the new back end will support user interfaces from Perchwell and Zenlist. New ways to change listings will be implemented through standardized Add/Edit listing interfaces from Zenlist and Ocusell. Three new Comparative Market Analysis (CMA) products are on the way. Integration times will be faster because of the investment in the data foundation.
Going forward, when analyzing requests to add new data elements to its systems, DMLS has taken on a philosophical high barrier to entry. If it’s not a RESO standard item, the addition must be a critical unsolved problem in order to be considered.
DMLS’s data alignment initiative created significant improvements in customer choice, consistency of experience and capabilities for engaging with new technology opportunities.
Through local foresight and planning with the guidance of industry-tested standards, DMLS’s technology foundation is prepared to serve customers in a dynamic environment. The future is bright for this MLS platform’s next steps.
DMLS Interview Subjects: Matt Fowler, CEO; Matthew Nagy, VP of Engineering; Allan Nielsen, VP of MLS Systems; Brady Kirby, Senior Solutions Architect.
