Pain Points

In recent years, RESO’s conferences have ended in a Pain Points session. These meetings are a moderated, yet mostly free-form discussion on where industry organizations are struggling.

Whether it’s inefficiency in standards, tools, processes or organizational relationships, Pain Points allows members to voice their current industry gripes to the RESO world.

Pain Points has quickly become RESO’s most popular conference session, and the spring 2021 rendition took it to another level. More than 200 attendees piled onto the Zoom link. It was scheduled for 90 minutes but continued for nearly three hours of discussions about the solutions that RESO can provide to the real estate industry.

What follows from this marathon brainstorm should illustrate the vast range of opportunities that lay before us as professionals that desire positive change for our partners, customers and even competitors.

If you didn’t catch all the content from RESO Remix, the full recap of sessions is here:

PAIN POINTS OPEN DISCUSSION: BREAK IT ON DOWN

Moderators Caitlin McCrory of Redfin and Dan Troup of RE/MAX led off the session with a conversation about the bumps and bruises of RESO Web API adoption. While initial implementations of Web API were somewhat inconsistent and paltry in their offerings, the latest iterations are finding more footing and, in some cases, full-market utilization.

WEB API UNIFORMITY IN UTAH

Brad Bjelke of UtahRealEstate.com was the early highlight of this session as he explained the process that his organization went through to convert every single MLS data consumer to Web API. UtahRealEstate.com is unique in that it builds its own API technology, and it independently decided to mandate the transition from RETS to RESO Web API.

With Redfin having been an early adopter of the Web API in Utah, McCrory talked about the benefits and the need for a long and clear transition timeline. Data consumers needed to know that they would have time to reasonably make changes to their systems, but they were also helped by the fact that they knew all data partners would be transitioning. There would be no walking back to RETS.

Bjelke noted that the vast majority of data consumer vendors made the transition on schedule. A few required a bit of additional time, and a tiny sliver decided it just wasn’t worth the effort and gave up providing services in that marketplace. These are often companies that supply websites to just one or two customers in a market.

As to the vendors that became functionally obsolete in the process, Bjelke’s stance was pragmatic. “You can be on Windows XP or Windows 95 if you want to, but we have to move on.”

UtahRealEstate.com made significant outreach at many stages in the transition process. Large vendors like Homes.com, Realtor.com, Zillow and Redfin made quick work of the changes.

GOING BROADER ON WEB API

Attendees dug in on some details of Web API that had stunted adoption in the past. As mentioned prior, some early Web API services didn’t have all of the fields a broker needed. This would cause vendors/brokers to say, “The Web API didn’t work,” when it was really an implementation issue. The 2021 mandate delivered by the National Association of REALTORS® (NAR) for all Web API services to have all broker participant fields brings some clarity to this issue.

Eric Stegemann of TRIBUS and Bill Boyer of Commissions, Inc. talked about the differences in working with some Web API services. These idiosyncrasies cause downstream data consumers to do more work as they have to build custom implementations in each market, which is obviously not the desired course for an industry standard.

These variations include:

The way photos are housed and accessed
The number of records that data consumers can access at a time
Replication vs. live query performance of Web API servers

RESO’s Joshua Darnell explained that much more uniformity of Web API services was coming through RESO’s new testing tools There are 40 queries that systems have to pass in the same way to achieve today’s Web API Core 1.0.2 standard.

Since all Web APIs will be certified to do that in 2021, the next step will be to address some of the other production issues around performance. It was shared that the process of replicating all data and photos from one MLS would take two months for a vendor in one instance. The ability to replicate is still somewhat scattered in boots on the ground experience.

RESO Chair and MRED CEO Rebecca Jensen emphasized the efficiency that MLS Grid is providing to customers adopting the multi-MLS database and API service. RESO board member and Metro MLS CEO Chris Carrillo noted that MLS Aligned also provides a multi-MLS API service and is also bringing this uniformity to the space. Metro MLS is a member of MLS Aligned and MRED is a member of MLS Grid.

Multiple members suggested that more uniformity is needed in Web API metadata. RESO has recently developed more consistent field/lookup metadata resources for implementation via the RESO Transport Workgroup.

DATA DICTIONARY MAPPING AND CERTIFICATION

There was significant conversation about native Data Dictionary database adoption of the RESO standard fields. The process of producing and ingesting data from other parties improves greatly when an MLS uses RESO standard formats.

There is still a lot of unstandardized data floating around the industry, which means custom data mapping for industry technology companies. A number of vendors proactively offered to share their mappings, and even shared their personal email addresses in the session chat, representing a quintessential example of the collaboration that happens at RESO conferences. Competitors frequently help one another to move things forward for the greater good.

Certification was discussed as a process-improvement angle for applicants, not just a checkbox to be fulfilled. A number of companies discussed how they tweaked and improved their systems based on the feedback they got from the RESO testing process, particularly using the RESO Commander open source testing tools.

RESO’s Transport Workgroup Chair, Paul Stusiak, reiterated that this was one of the good things that has resulted from certification. Almost without exception, every one of the vendors has jumped to address some of the issues that the certification process has identified.

COMMUNICATING CHANGES

Attendees discussed the challenges in notifying and receiving updates about technical system changes. Much like the other Pain Points sessions over the past year, data consumers lamented the lack of progress and consistency in data-related communications.

While major breaking changes are delivered to data consumers in a generally sufficient, if not consistent way, some changes that data producers consider minor aren’t strongly communicated and look like a bigger deal to consumers when the change takes place. Session attendees are hoping for more standardization and longer timelines for these kinds of disruptive changes, even if they are nonbreaking.

RESO’s Greg Sax suggested that most companies should have generic departmental email addresses (e.g., data@, update@, etc.) to avoid staff-specific email addresses that can create outdated notification lists due to staff turnover. Attendees agreed that this was a major cause of disconnect. Two members stated that their organizations now require data consumers to update their contacts on a monthly basis to stay in sync.

RESO’s discussion on a Notification (Messaging) Resource was brought up as a potential solution for common notifications in this space.

LET’S $EXPAND WEB API STANDARD CAPABILITIES

A large group of attendees agreed that one place RESO needed to focus was on the $expand capability standard for Web API services. This feature was originally planned as a Web API Platinum capability, but the specification needed more detail in order to truly forward the kind of standard that data consumers need.

The $expand capability is being planned as an endorsement option for Web API services. It asked if it should be required for all MLSs that are certified, and most conversation participants thought it should.

The $expand endorsement would allow for data consumers to grab more specific sets of data through more complex queries. It’s basically an advanced search for a Web API. What’s still needed is to identify which Data Dictionary resources might be part of the ability to use $expand.

RESO has defined relationships between fields in its Common Schema Reference Metadata and its Common Schema Open API Reference.

It was agreed that the Transport Workgroup should discuss making $expand a mandatory feature of an MLS Web API server and that its relation to the Media resource should be covered.

There was general consensus that the speed of accessing photos/media was a primary pain point for data consumers.

FRACTIONAL OWNERSHIP

Fractional ownership is a part of the RESO Data Dictionary. It’s often confused with time-share (which fractional is not), and it is not implemented broadly as a property subtype across MLSs.

There are semantic and representational issues with displaying co-ownership properties in the MLSs today. Marnie Blanco of Pacaso talked about the need to present a true picture of a property that is selling just a share of its ownership.

Many MLS staff members agreed that this is a common issue. They want to provide clear information to agents and consumers. If you’re selling one-eighth of a home, that should be advertised clearly.

SHOWING IT OFF TO EACH OTHER

Many members discussed the need for an expansion of standards around real estate showings.

Consolidation in the showing space over the past few years and recent expansion of new services has created some urgency around ensuring standards are used by new entrants.

Some attendees suggested an open-source platform to create transparency in the space. It was offered that showing information could travel between brokers via the MLS, or even directly between brokers.

Some of the largest MLSs in the industry have been exploring these concepts. The need for an Add/Edit standards solution is probably required if this information is to be stored in an MLS’s primary database and updated by multiple showing systems. Solutions for these “API Update” needs are already documented at RESO.

The number of MLSs instituting showing standards up to this point has been low; individual vendors have created their own standards. There are currently 32 fields in RESO’s Showing resource, and expansion is actively being discussed by the Data Dictionary Workgroup.

SMART TECH IN SOLD HOMES

Following a mixer session that occurred earlier during the conference, smart homes were brought back as a topic during Pain Points. While it is not necessarily a RESO-centric topic, there are many concerns to address going forward.

From thermostats to smart cars, refrigerators and other facets of smart homes, how does software ownership and account management get identified and expressed during a transaction?

More disclosures are likely needed by home sellers, and a more managed process of transferring these smart home assets could help transaction participants. At RESO, the possibility of new fields that support smart home documentation may be worth discussing.

BRINGING IT BACK TO THE WORKGROUPS

Those were the main topics for this round of Pain Points, and we will be addressing all of them during workgroup sessions and official policy as the year progresses.

We at RESO cannot overemphasize the importance of these Pain Points sessions to RESO’s strategic objectives. They have become a critical catalyst for the kinds of member-led changes that a standards body needs.

When we say “Bring the pain,” we mean it. Thank you to all of our members for continuing to engage on moving the industry’s technology efficiency forward.