45
As "the guy" who led the development of the first pricing and revenue management system for multifamily housing (LRO) and was the industry's first-ever VP of Pricing and Revenue Management (PRM) back in 2001, I've watched with great interest the past 23 years as adoption evolved.

What started out as a practice highly questioned for its relevance to rental housing has become de rigeur for the NMHC Top 50 and at least a few hundred other companies. And while the current lawsuit has many operators looking for alternatives that are well within antitrust "safe harbor" laws, I know of no one who wants to go back to the days of manual pricing. The benefits of PRM software are simply too much to ignore.

Yet the one thing that has troubled me throughout the past 15 years of widespread adoption is how little any of the systems have evolved and changed. They work well, and they've been an incredible cash cow for their software vendor owner, but it's highly unusual for such mission-critical software to look and function today as similarly as they functioned back in the mid-00s when the initial wave of adoption occurred.

With ten years of leading the implementation of a system at an S&P 500 REIT, ten-plus more years of consulting with a wide variety of dozens of operators and owners across the spectrum of business models and now four-plus years leading a data analytics software company dedicated to rental housing, I propose the following seven things that virtually all PRM associates and operators I've spoken with agree should change.

The main legacy systems are simply too complex and too opaque for anyone to be able to explain with certainty exactly why the recommended price is the recommended price. We can guess, wave our hands a bit and then move on, but this lack of clarity makes it harder for executives and field operators to trust the models. And lack of trust can undermine the model's results since selling apartments at recommended prices requires leasing associates to be confident in presenting to prospects. It's time for PRM applications to show users exactly how and why the recommended price is what it is.

Legacy systems were built before we really could understand how they would be used. And the result, like all v1 software, is that not all assumptions about workflow turned out to be correct. The result is interfaces and workflows that, candidly, are clunky. With proper attention and contemporary UX design, we now know where actions take more clicks than they need to take and where time is wasted fishing around for places to intervene with recommendations. It's time for software vendors to reduce the "total cost of ownership" by designing models and interfaces that improve user productivity thus freeing up time for higher-order activities and reducing the cost of operating these systems.

In the late '90s, as LRO was first being built, everyone thought that PRM systems would eliminate concessions. So LRO and subsequent systems were built implicitly assuming that only net effective rent mattered. However, much as the personal computer revolution of the 1970s and '80s didn't eliminate paper, neither have PRM systems eliminated concessions. It's time for PRM applications to be built in a way that gives users flexibility on how they handle concessions rather than forcing them into a "one size fits all" approach.

Rent control has become a much bigger, and more complex, thing than when the legacy systems were built. So, it's no surprise that those systems struggle with many of the situations and don't even address others (e.g. "process" control laws where long-term residents or residents getting larger increases must be given longer notice of rent increases). It's time for vendors to address the myriad, complex web of rent control and process-related rules and regulations that have popped up around the nation—and to do it in a way that "future proofs" against new regulations yet to come.

To be honest, lease-up pricing was not in the "consideration set" of problems to be solved. We weren't being ignorant or cavalier; we simply were faced with the gargantuan task of figuring out how to build the first automated pricing model for rental housing and didn't want to distract from that effort for something that was a small single-digit percentage of the use-cases. Understandable…even laudable by today's Agile software development principles. However, leaving such an important piece of the puzzle untouched 20+ years later maybe isn't such a good thing. It's time for PRM software to address lease-up pricing as well as it does stabilized assets.

A very similar story to lease-ups. Renovation pricing is complex, and it's more than just "a renovation amenity add-on." It's time for PRM software to address renovation pricing as well as it does stabilized assets.

This was yet a third "distraction" as a low-value use case, but it's not a "no value" use case. And in a year where operators are scratching for every extra dollar they can find, it's even more imperative to leave no stone unturned. Furthermore, experience in the scattered home single-family rental world has shown a way to price the ultimate in small count UTs—each home there is truly a "snowflake." It's time now that we finally address small count unit types.

The list could go on—integration with a business intelligence platform, ensuring non-volatile pricing, improved amenity pricing without using non-public data, etc.—but this list of seven would certainly move our industry forward in the breadth and sophistication of our pricing solutions!