In the CRE data space, there are three different needs. Let’s start with what agents need. At the very least they need to know what’s available, owner information and historical prices. Some, but not all, want market data – vacancy, absorption, sale and leasing activity. Right now, CoStar, LoopNet and all the local CIEs/MLs and in-house systems provide that to one degree or another.
Besides the nuts and bolts data, agents also want leads. They get them through networking, marketing activities including websites/SM, and online lead generation sites – like LoopNet, Rofo or any of the other aggregators that let users “contact the agent.” Online lead gen only works if the source is known by the user – or the site appears in a search when the user starts the process. And agents have to perceive value – are they getting leads from a site, are they any good and is what they’re getting worth the time or price.
Brokerages have a different need, most of it production related – how are the company and its agents doing? That can be generated by accounting systems. But they could also use business intelligence. That can be derived from accounting data but it gets really interesting when you mix your data with other data sources – like economic and demographic data – or more importantly, market activity.
Unless the brokerage collects local property/listing/comp data themselves, there is no data source available for what’s going on “outside your office.” The aggregators don’t offer APIs or data exports so you can mix that data with your own. Aggregators don’t give anyone the ability to data mine either but if you own it, it’s yours to mine. So this forces brokerages to collect local data themselves – and once they’ve put the time and resources into doing that – guess what? They’re not going to share it.
User needs are the final part of the data picture. What do they want in terms of commercial real estate data and where or from whom do they expect to get it? This is tricky not just for CRE but for any company. Everyone is unique and part of your job is to do a needs analysis. But the overwhelming opinion is that users want more.
There’s a segment of the industry that worries about data commoditization putting brokers out of business. Not so – for now at least. There are two things on the industry’s side. The first is the law – you must be a licensed agent to broker a real estate transaction for another party. The second is complexity. Some, but not all, CRE transactions are complex.
Liken the complexity to what happened in the travel industry. As soon as you could search and book reservations online, some clients had no need for a travel agent. And while a large percentage did just that, there were still clients who didn’t want to be bothered, companies that preferred to outsource the dirty work and sectors of the industry, like group travel, that provided enough of a client base to keep some travel agents in business. And let’s look at all that travel data “out there” for the consumer. It’s still way too complex for some users who give it up and use a travel agent.
Even with those very large pluses, there are distinct generational differences. The CRE client of the future is going to be much more tech savvy and able to deal with the complexity. Duke Long talks about the CRE data portal of the future in a current post. Not just the standard address, SF, use search but information about the area, reviews from tenants, comparative prices and multiple photos or videos. That might appeal to GenY . Not so much to the older generations who are still making the bulk of the real estate decisions. But any company that focuses solely on current client needs jeopardizes their longevity.
It’s tough to know what to bet on for the future but the CRE industry has to be aware of changing expectations on the user’s part. We also need to know if the user of today is satisfied with what they’ve got – a bunch of free or pay for services, few of which have “everything.” And back to the agent and broker needs – is “what is” meeting their needs? Apparently not. Some thoughts on solutions in upcoming posts.