Conversations about the MLS industry, creating software, and employee ownership.

Last week at Connection 2009, I listened to a presentation from Dale Ross about NAR’s Real Property Resource (RPR), which previously has been referred to as the Gateway, Channel, Library, etc.  Here are a couple of highlights from the presentation:

• Move, Inc. — Move has been doing the early development on the project, but Dale emphasized several times that the development was under a contract for hire.
• Alpha/Beta Testing — Nothing was shown during the presentation, but apparently there is an interface and it is going to be previewed and tested in the next few months.  There is an interface (it’s not just a back-end data repository) and it includes mapping; Dale described a map showing lots of layers, such as air traffic control patterns.
• Private to REALTORS — The RPR is intended for REALTOR use only, and not the general public.
• Not an MLS — The refrain continues that the RPR is not an MLS.  Instead, the emphasis was on MLS systems integrating the RPR back into MLS systems, though no details were provided on what the API might look like for doing that.
• Public Records — The primary pitch for RPR seemed to shift from “national MLS” to “national public reocrds”.  Instead of replacing MLS vendors and MLS systems, the focus now seems to be on RPR being a national public (for REALTORS only) records system of some sort.  At the same time, Dale did say that the system could become a national MLS, that just wasn’t the intent right now.
• Univeral Property ID — I have no idea if my repeated calls for NAR to create a univeral property ID system were heard or not, but Dale made clear that such a system is a key part of the RPR.

Those are the highlights I gleaned from the presentation.  Here are my thoughts:

• Universal Property ID — From the links above, there should be no suprise I think this is a great idea and I’m very excited that it’s become a key talking point.
• Open Communication — I think the NAR would do well to open up communication more about the details of their approach to the univeral property ID and the API in general.  I understand that this is product development and they may feel a need to develop in secrecy so as not to lose some competitive advantage.  However, a critical concept like a universal property ID should be approached as a standards effort and devloped openly.  This really goes for the entire project.  NAR should be focusing more on publishing API documentation than on developing user interfaces.
• Universal Property ID = URI — To be successful, a universal property ID system needs to be used, preferably by everyone.  That means there needs to be a URI for every property (RESTful development, and all that), and there needs to be an easy API to get the link for a given property.  One can easily imagine a URI like http://www.rpr.org/country/region/local/parcelnumber or something like that.  (Matt Cohen from Clareity also recommends standardizing the parcel number system.  I agree with that, though it’s a more daunting task.) Developing and promoting a microformat for the universal IDs also seems to make some sense.  Overall, though, NAR should be publishing information on the URI structure they’re intending.  Importantly, the universal property IDs also are something that cannot be private only; the IDs and the API for generating and accessing them need to be public, or they will not get used.  I’ve written before that a walled garden of data is passe, and what’s really important is developing a broadly-used method for linking property information together wherever it finds itself on the web.  To bring this to reality, the RPR system needs to promote and publish universal property IDs as URIs.
• Reaper or Ready?  I think it was Russ Bergeron who spun the RPR acronym into ReaPeR, and it seemed to catch on with others using the same term after the presentation.  Despite the effort to present RPR as a benign service, clearly some in the room continue to question the business model.  Will the system become a sink-hole for investment of member dollars or will there be a revenue model associated with it?  That was not clear from the presentation, and so the reaper reference remains floating in the air.  Equally uncertain is how ready RPR actually is.  The tone from the presentation is that the system is well along in development and at least ready for some private review and testing.  This takes me back to the earlier point, that more detailed information would go a long way to allowing people to understand how a system like RPR will impact their business, be it agent, broker, MLS, MLS vendor, public records vendor, or others.

In closing, I go back to an earlier post I wrote on this same topic, where I concluded:

What I think would be useful is for NAR to foster a discussion among brokers, agents and MLSs regarding the Open Web and what that means for real estate.  This same discussion is occurring right now with regard to the web as a whole, and Brad Neuberg recently suggested: “If we take the long term view, how can we give the web an open enough infrastructure to evolve over time and meet each generations needs, while maintaining its structure enough to actually mean something and stay true to its promise, similar to the U.S. Constitution?”  He emphasizes that this isn’t so much about specific technology but rather the general philosophy: “if we define the Open Web in terms of [specific] technologies, then we risk losing sight of what makes the web special and being able to have the intellectual nimbleness to evolve the infrastructure of the web. . . .  We will be fighting yesterdays battle while allowing new, proprietary technologies to take over if we focus on technologies rather than philosophy.”

I’m writing this from MLS Connection 2009, where Joel Singer just spoke.  Joel is with the California Association of REALTORS and the driving force behind calREDD, a new MLS system being offered by CAR.  Joel made a basic argument to justify calREDD:

We need one MLS (as opposed to many) to compete with Zillow.

I had my hand up to address this argument, but the next topic was up and so I didn’t get a chance during the sessions.  Instead, I’ll just post what I would have said here.

This argument is wrong on many counts.  First, Zillow is not and never will be an MLS.  Second, the MLS is more than technology.  Third, the idea that a monopolistic bureaucracy can innovate over the long term is fundamentally flawed.

This fear argument from CAR is passe.  Zillow’s a good company, doing some exciting things.  That doesn’t mean they are an MLS or that MLSs aren’t innovating, too.  The innovation ecosystem around MLSs is huge.  We deliver data every day, all day on behalf of MLSs to all kinds of developers and others doing interesting, innovative things.  This is what competition and markets do, they innovate.  The fear being pushed by CAR to reduce competition and create a monopoly is exactly the opposite of what this industry needs.

In a post last week, I asked a pretty open-ended question: “Are the costs of an MLS [coverting to a standard format] worth the long-term benefits?”  I asked this question because we have several MLSs contemplating this very question now, and I thought it might be interesting for them to hear some outside perspectives.  We received some great comments on that post, and in this post I want to put some more meat on the bone by outlining in more detail the potential cost savings for regionalizing MLS data.

Importantly, there are several ways to regionalize MLS data and so I think the first requirement is defining the objectives (benefits) of regionalizing.  Once the benefits are quantified, then the costs of the potential solutions can better be judged and the “bottom line” or ROI of the entire effort will hopefully be clearer.

Benefits of Regionalizing MLS Data

Some of the oft-sited reasons for regionalization are:

• Eliminate or reduce duplicate listing entry, which often means learning and complying with different rules for listing entry;
• Eliminate or reduce the payment of fees to belong to more than one MLS;
• Eliminate or reduce the costs associated with managing disparate IDX feeds and IDX rules; and
• Increase the exposure of listings to more MLS members.

The next step is to quantify these costs or opportunities.

Cost of Duplicate Listing Entry
Formula	# Duplicate Listings Per Year x Cost Per Listing
#Duplicate Listings	Finding the number of duplicate listings is not always easy.  One of the biggest challenges is that the data likely is not stored the same way for each of the MLSs involved, and so comparing addresses or parcel numbers may not be accurate.  Also, you may not have ready access to the listing data from all of the other MLSs involved.Importantly, though, we’re not looking for perfection here but an estimate.  In that regard, if you don’t have access to all the data for such an analysis or the address matching is too unreliable, an alternative approach would be to survey your brokerages/offices to ask them how many MLSs to which they belong and to estimate the percentage of their listings they enter into other MLSs.  (This same info will be helpful in assessing duplicate membership fees discussed below.)For example, let’s say your MLS has 200 offices and ten percent (20 of them) belong to more than your MLS and have a policy of entering all their listings into those MLSs.  Of those twenty, perhaps your survey finds that twelve offices enter listings into three additional MLSs, four of the offices enter into two additional MLSs, and four others enter their listings into just one additional MLS.  You could then take the annual new listing count for each of those 20 offices and multiply it by the number of additional MLSs revealed from the survey for that office and you’d have a rough estimate of the number of duplicate entries for a year.
Cost Per Listing	There are a couple of methods for estimating the cost for entering a duplicate listing. First, you could use the cost for data entry personnel and an average amount of time for entering a listing as an estimate of the cost. For example, an average data entry salary is approximately $30,000 per year or about $15 per hour (rounding up). Assuming someone can enter a listing and upload the photos in 30 minutes on average (our time estimates are less than this, but 30 minutes is a conservative high-side estimate), the cost per duplicate listing is $7.50. On the other hand, many agents enter their own listings and so the cost really is the opportunity cost to them of their time, which is much more difficult to assess. For this reason, I’d recommend using the outsourcing cost as an estimate.  However, I’d also add some additional cost for review by the listing agent and other compliance issues that arise.  Accordingly, perhaps doubling the cost of listing entry is a good estimate for the cost of entering a duplicate listing.  (Note:  Of course, these costs may differ for you locally depending on relative salary costs in your area and other compliance requirements.)
Example	1,000 duplicate listings entered per year x $15 per listing = $15,000 potential cost savings per year Caveat: I’m just making up these examples.  You need to put in your own numbers for your MLS.

Duplicate Membership Fees
Formula	# Duplicate MLS Memberships x Average Cost Per Membership
# Duplicate MLS Memberships	If each MLS uses the NRDS ID as a tracking identifier for members, finding duplicates should be relatively straight-forward if you have access to the data. Other possible matching methods are email address or, as a last resort, name and possibly street address.  Or, as mentioned above, you can get an estimate of the number of extra MLSs to which members belong by surveying your membership.  Again, a solid estimate is what we’re after. In designing your survey, you should be clear that you’re asking about MLS memberships other than yours. Or, alternatively, ask for total MLS memberships and then be sure to subtract one when doing your calculations. Another complicating matter here is that members may belong to multiple MLSs for a variety of reasons unrelated to data sharing or regionalization. For example, lock box access often is an issue that needs to be solve simultaneously with MLS data exchange. Overall, however, estimating the total number of duplicate members will provide an outside estimate of the potential cost savings.
Cost Per Membership	The cost per membership likely will need to be an average as calculating the exact number for each person would likely be impractical.
Example	50 duplicate memberships x $240 average cost per membership per year = $12,000 potential savings per year. Note: An interesting side note here is that the saved duplicate membership fees are lost revenue to the other MLSs in the region.  The members save by not having to pay duplicate fees but the MLSs actually lose some revenue.

Costs of Maintaining Disparate IDX and Other Data Feeds
Formula	(Total # of Data Feeds Delivered by All MLSs in Region – # of different entities receiving the feeds) x Average Cost to Maintain Each Feed plus (Total # of New Feeds Delivered by All MLSs in Region – # of different entities receiving the feeds) x Average Cost to Setup Each Feed x Discount Rate
Total # of Feeds Delivered	This number should be relatively easy to obtain by looking at the RETS manager in your MLS system or inquiring with each MLS vendor involved.The number of new feeds delivered each year could be estimated by looking at the number of new requests received in the last year, and using that as a proxy or estimate for the number expected in the future.
# of Different Entities Receiving Feeds	You need to subtract the number of developers receiving feeds from the total number of feeds, because each developer would have to convert and maintain at least one feed no matter what.  Note:  Subtracting this number will only provide an average, because some developers may receive more than one feed from the same MLS, but, as mentioned above, we’re estimating here and this should provide a close proxy for the total extra feeds.
Cost of Converting and Maintaining Disparate Feeds	As an MLS vendor, we’re not on the receiving side of too many IDX data feeds, but we do have quite a bit of experience with data conversions.  In a typical conversion, you have both programming and QA personnel involved and these processes collectively may take approximately 24 hours per property type to convert and test. Assuming an IDX feed would take about a third as much time (or 8 hours) and that an average MLS has 5 property types, that would be 40 hours per feed to get it set up. Assuming an average cost of $133 per hour for programming and QA, the cost to set up an IDX feed is about $5,320. (If there is anyone reading who has more exact cost estimates for converting IDX feeds than this, please comment or send me an email.)Of course, the conversion expense is a one-time cost, and, for those vendors already operating in your markets, the cost has already been incurred, and so will not be saved except for new feeds.  The only cost that will be on-going is the cost to maintain the disparate feeds.  Once the conversion program is written, the cost of maintenance is relatively minimal unless the MLS changes fields frequently, which is unusual.  I would think a conservative (high) estimate of the cost to maintain a feed per year would be about $1,000 (7.5 hours per year at $133 per hour average for development and QA).
Discount Rate	A potentially important issue here is that the costs for processing the feeds often are not born directly by brokers or agents but rather by IDX and other product vendors. Accordingly, even if the process is made more efficient for these vendors, that doesn’t mean the prices paid by the brokers and agents will be lower. Of course, some brokers and franchises also hire developers in-house to process these feeds and competition likely will force prices lower over time, but it may be prudent to build in a “discount” rate on this potential cost savings to reflect that the savings may not all pass through to your members.
Example	(50 new feeds per year – 20 different entities receiving the feeds) x $5,320 per feed = $159,600 per year (200 totals feeds – 50 different brokers receiving the feeds) x $1,000 per year per feed for mainteance = $150,000 per year As mentioned above, some discount rate likely should be applied to these formulas, because all the cost savings may not be passed through to your members.

Increase Exposure of Listings; Potentially More Sales

Formula

Even though this is one of the biggest potential benefits, I’m not sure it can be estimated properly. First, there is at least some argument that no increase in sales will occur because the listings that benefit from exposure in more than one MLS already are being exposed by the duplicate entry. Second, if there are some people who aren’t willing to spend the time or money on duplicate entry now such that there would be some additional or faster sales from more exposure, estimating that number would be pretty hard. Perhaps one method would be to try to find out how many inter-MLS sales there are now on the duplicate entries and extrapolate that number to the non-duplicate listing base. However, such an extrapolation is filled with potential inaccuracy given that the agents and brokers likely weren’t entering it into the other MLSs already because they didn’t see a big benefit to doing so. Overall, I think this is the area where many regionalization decisions can go awry. The potential benefit of the extra exposure and sales seems limitless and so justifies nearly any cost when, in fact, the benefit may be negligible at best.

The above are some of the key cost savings and efficiencies that can be gained by regionalizing or standardizing the data processing for an MLS. Perhaps there are others I’ve missed or different ways to estimate the savings. Please let me know in the comments. Also, if you have numbers for your area you’d like to share as real-world examples instead of my made up examples, that would be very interesting.

Costs of Regionalizing

Once you have an estimate on the annual savings, you can then begin to compare those savings to the cost of getting there.  The cost, who pays, and how likely the solution is to produce the savings identified above will depend on the strategy you choose for harmonizing the data. I’ll be addressing these different approaches in a follow-up post, so stay tuned.  When we’re done, we should have a decent model for MLSs to assess the costs and benefits (or the “bottom line”) of regionalizing their MLS data formats.

We released a new 1004 Market Conditions option for the statistical CMA in flexmls Web a week ago, and the response has been so positive I thought it was worthwhile posting some of the responses here:

Hello Michael!

I just wanted to share with you a few comments from our appraisers concerning the Fannie Mae 1004MC.

The relief on my appraisers faces has been amazing and from what I understand from the gentleman I talked to today is that flex is the only system in the state that has anything in place to help them with the form.  Out State MLS isn’t even on board yet.

Several of them wanted me to express their Thank You! Thank You! Thank You’s! You guys are the bomb! We are so lucky to have this system…I could go on and on.

Kudos to you and the crew.  GREAT JOB!

Kristy Barrett, AEO
Campbell County Board of REALTORS
and the Multiple Listing Service

---

Date: 4/7/2009
… I just wanted for you to pass on to whomever created the extra data form for us appraisers, regarding that 1004MC formatted information, gets my MOST incredible applause and thanks! This formatted data saves us so much time, it is incredible! Thanks to those who’ve worked on that!

Ric Becker

Tillamook, OR

---

TO ALL FLEX MLS 1004MC TEAM…

THANKS FOR THE GREAT WORK ON THE 1004MC… THIS WILL CERTAINLY MAKE OUR LIFE MUCH EASIER. OUR ALTERNATIVE WAS SORTING, FILTERING AND REPORTING THRU MICROSOFT EXCEL OR ACCESS.

ON BEHALF OF APPRAISERS HERE IN THE GALESBURG, IL FLEXMLS… “THANK YOU!!!!”

---

By the way, once you get this buttoned up, I hope your sales organization is aware that EVERY appraisal in the USA going through Fannie Mae or FHA has to use this form; and that there are classes being held on it and books (36 pages to explain 1 page) being published about it; and that appraisers are putting out Excell spreadsheets and howto blurbs in online forums; and that some appraisers are predicting that completing the 1004mc will add 2 – 3 hours to each appraisal (that’s even how long it took me the 1st time manually); and that what you are doing is completely replacing all of that. If they are not aware of all that, then tell them.

---

Pretty cool, huh?  I think we do a great job of responding to our customers’ needs, but it isn’t often we get this kind of outpouring of gratitude.  Clearly, we hit on a key issue for the appraisers here.  All of this makes me wonder, are there other opportunities we like this out there where we can make our customers’ jobs easier?  Success like this makes coming to work every day a pleasure, and so it’s a true win-win if we find more opportunities to make our customers more efficient.

I’ve long advocated MLSs to work together on as wide of a basis as possible (nationally or regionally) to agree on a common data format for MLS listings.  My theory is that if there were a common data format, the data could move much more easily among MLS systems, enabling MLS vendors such as ourselves to more easily and effectively create regional MLSs along market boundaries.  My question is this:  Assume all MLSs all had common listing formats, would exchanging data among MLS systems be much easier?

Here are some follow up questions:

• If data exchange were easier, would it eliminate the need for any broker to belong to more than one MLS?
• Would it eliminate the need for duplicate listing entry?
• Would it make IDX data feeds consistent?

And here’s the doozy of all questions on this topic:

• If the answers to the above questions are yes, how do we get all the existing disparate formats converted to a new common format?  By this question, I don’t mean how do we agree on a format.  Rather, assume agreement is reached.  Instead, I’m wondering about the actual conversion work.  Anyone that’s been involved in a data conversion knows that it isn’t trivial.  The new formats require changes to forms, the new formats have to be learned by members, saved searches often have to be re-done, someone has to write a conversion program to transform the data, and lots of other details.  Are the costs of this effort worth the long-term benefits?