What the leasing office knows: introducing WP FloorMap Velocity

A leasing manager can name this month’s difficult units before you finish asking: the two-bedroom over the garage entrance that has been on the market since spring, and the corner unit with the balcony that will be gone by Friday because it’s always gone by Friday. The property management system knows the same thing to the day. That knowledge rarely reaches the website. On most property sites, including many the PMS itself produces, the two sit side by side under the same ‘Available now’, in whatever order their availability dates put them.

Velocity is a new part of WP FloorMap that closes that gap. Built from the property’s own data feed, it keeps a leasing history for every unit and every floor plan, and uses that history to decide which homes and which layouts renters meet first, according to a leasing goal each property chooses. It changes which unit comes first, never what any unit costs, and it reads no visitor data.

Four strategies

A list of available units looks neutral, but it is not. Sorting by date or by price is a leasing strategy too, made by default rather than by anyone accountable for leasing. Velocity makes the choice an explicit one:

• Balanced occupancy: slow units first. The units available longest are surfaced first, in the settings screen’s own words ‘so aging inventory gets the impressions instead of the units that would have leased anyway. This is what most operators want, and it is the same reasoning behind offering a concession.’ Velocity applies that reasoning without reducing the rent, and it suits a community carrying a tail of hard-to-lease homes.
• Fastest moving: quick-leasing units first. The layouts that have historically leased fastest come first, for when the goal is signed leases per visit rather than clearing the tail, as in a lease-up or any property with a hard occupancy deadline.
• Revenue: highest rent per square foot first. For a stabilized asset optimizing income rather than headcount. It works from current rent and floor plan size, so it needs no leasing history and applies from the moment it’s chosen.
• Off: availability or price. No reordering. Nothing is measured and nothing is inferred, and the site keeps the order it already had.

It promotes floor plans as well as units

Velocity measures at two levels. Every available unit has its days on the market. Every floor plan has a record of its own, combining the median days a unit of that plan takes to lease with the age of the oldest unit of that plan still available. The second measurement is what turns ordering into promotion. Because a renter compares a handful of layouts rather than forty vacancies, the plan cards she meets first are the ones she asks about. Under the property’s chosen strategy the plan that serves the leasing goal leads the grid: the layout that has been sitting, under Balanced occupancy; the layout that signs fastest, under Fastest moving; the layout that earns most per square foot, under Revenue.

The settings screen says where the order applies in one line: this property’s available units, and any floor plan grids left on their default card order. Lists are long and screens are short, so that order decides what a renter actually sees:

• The first screen of the unit list. The explorer and portfolio lists page at twenty cards and open on Recommended, which is the property’s strategy. Page one is the twenty homes the leasing goal put first.
• The units inside a floor plan. Open a plan with forty vacancies and its panel lists ten, and says so. Which ten it lists is the strategy’s decision, and with no strategy chosen they are simply the ten cheapest.
• The floor plan grid. A floor plan block left on its default order ranks the layouts themselves, so the plan the strategy favors leads the grid, and on a phone it’s the top card of the stack.

Where an editor has asked for an explicit order—A to Z, price, bedrooms—that wins, because a person chose it. There are also places Velocity deliberately doesn’t reach: the SightMap map stays Engrain’s, pins and all, and no price on the page is ever a Velocity decision. Every available unit is still listed, the filters still reach any of them and unpriced or off-market homes stay at the tail where they always were.

The measurements travel with the data. Every WP FloorMap site fetches them in the same payload that already carries its units, availability and pricing, and that payload carries the measurements all four strategies need, because the choice itself stays a setting on the property rather than something our API decides. The building’s goal is applied wherever its plans and units appear, without being configured again per page or per block.

Set per property, which is what a portfolio needs

The strategy belongs to the property, not to the website. It matters most on a portfolio site, where one goal imposed on every building would suit almost none of them.

A new building and a fifteen-year-old one in the same portfolio don’t want the same first apartment, and often they are the same building a few years apart, as the lease-up stabilizes, the stabilized asset ages and a tail appears. On a portfolio site each property carries its own setting, so the lease-up can run Fastest moving while the aging community runs Balanced occupancy and the stabilized tower runs Revenue, on the same site, at the same time. When a building’s goal changes, one setting changes with it and nothing else has to be rebuilt.

Where a single block gathers floor plans or units from several properties at once, WP FloorMap applies a strategy only when those properties have chosen the same one. Interleaving two different notions of best would produce a list that means nothing, so where the properties disagree the curated order stands.

Rents stay where the operator set them

Velocity changes the order in which units appear, never what they cost: it doesn’t set rents, it doesn’t suggest them and it doesn’t benchmark them. Even the Revenue strategy only reads the rent the operator has already set, together with floor plan size, in order to sort by it.

The multifamily market has watched algorithmic rent-setting draw antitrust scrutiny, and operators have learned, rightly, to ask any software touching leasing data which lever it pulls. The one lever Velocity pulls is which home a renter sees first on a property’s own website, decided from that property’s own data.

When a unit lingers, the familiar remedy is a concession, and good tools already help an operator judge when one is warranted: Engrain’s own Asset Intelligence maps days vacant across a property so a team can see where occupancy is slipping. Velocity works from the same kind of signal, though never from that product’s data, since it keeps its own record, built from the SightMap feed the site already receives. The difference is where the signal goes. Instead of advising the office what to give up, Velocity changes what the website shows, putting the slow home where renters are already looking and leaving the rent exactly where it was.

The record behind it keeps base rent rather than the all-in figure, because an all-in total moves whenever a fee schedule changes and a ledger reading it would mistake a new monthly charge for a movement in price. Renters should still see the all-in number, as we argued in The teaser rent, while the record needs the number that moves only when the rent does.

It reads the leasing record

Much of the software that reorders a web page learns from the people looking at it. Velocity reads none of that: no clicks, page views, sessions or favorites. Its only input is the leasing record from the property’s own data feed, so the order one renter sees is never shaped by how another renter browsed. The leasing office never needed to watch a prospect’s cursor to know which unit was slow, because the answer was in the lease dates. We have argued before that a property website should welcome a visitor rather than interrogate her at the door.

Thirty days, then it runs on its own

Included on every WP FloorMap plan, Velocity builds its record from the Engrain SightMap® feed that already brings a connected property’s units, availability and pricing to its site. Twice a day it reads that feed and writes down what changed, so collection starts as soon as a property is connected.

Choosing a strategy takes a moment, but Balanced occupancy and Fastest moving apply on their own only once thirty days of leasing history exist, and until then the page keeps its usual order while the settings screen counts the days collected so far. Fastest moving then arrives plan by plan, once a floor plan has five completed spells of availability within the last year. A spell closes when the feed marks a unit unavailable. Revenue has nothing to wait for and Off measures nothing. Thirty days isn’t a long wait, and we’d rather ask for it than reshuffle a renter’s list on a few days of evidence.

The short version

• The knowledge already exists. The PMS records every move-out, vacancy and lease, yet most property websites still list units by date or price.
• Velocity makes the order a choice: slow units first, quick-leasing units first, highest rent per square foot first or no reordering at all, on every plan.
• Floor plans as well as units. Each plan carries its own leasing record, so the strategy decides which layouts lead the grid, not only which vacancies lead the list.
• The choice is per property. A portfolio runs one goal per building on a single site, and changes any of them when that building’s goal changes.
• Order, never price. Velocity doesn’t set, suggest or benchmark rents.
• No visitor tracking. Its only input is the leasing record from the property’s data feed.
• Nothing is invented. Failed feeds record nothing, empty payloads remove nothing, stale properties aren’t ranked and any failure falls back to the normal order.

The leasing office has always acted on what it knows in the quiet ways a good office does: the tour route, the concession, the unit mentioned first on the phone. Velocity gives the website the same information, and applies it to the one thing a list can change, which is the order. If you would like to talk through which strategy suits each of your properties, get in touch.

Frequently asked questions

What is WP FloorMap Velocity?

Velocity is the part of WP FloorMap that decides the order in which available units appear on a property website, using the property’s own leasing record. Each property picks one of four strategies in its settings screen: Balanced occupancy puts the slowest units first, Fastest moving puts quick-leasing units first, Revenue puts the highest rent per square foot first and Off keeps the usual order by availability or price. The order applies to the unit cards in the floor-plan explorer, the available units listed inside a floor plan, the floor plan blocks left on their default order and the portfolio lists that gather more than one property. Velocity is included on every plan.

How does Velocity work across a portfolio?

The strategy is stored per property, not per website, so one portfolio site can run a different goal in every building: Fastest moving in the lease-up, Balanced occupancy in the community with an aging tail, Revenue in the stabilized asset. Each property’s pages follow that property’s own choice, and an operator can change any building’s strategy as its goal changes. Where a single block mixes floor plans or units from several properties, WP FloorMap applies a strategy only when those properties have chosen the same one, and otherwise keeps the curated order rather than interleaving two different notions of best.

Does Velocity promote floor plans as well as ordering units?

Yes. Velocity measures floor plans as well as units: the median days a unit of that plan takes to lease, and the age of the oldest unit of that plan still available. The property’s chosen strategy then ranks the plan cards in any floor plan block left on its default order, so the layout that serves the leasing goal leads the grid. It also decides which units are surfaced where a screen can’t hold them all: the first page of the unit list, and the ten available units listed inside a floor plan. Where an editor has asked for an explicit order, such as A to Z or price, that order wins instead.

Does Velocity set or recommend rents?

No. Velocity changes the order of units, never their price. It doesn’t set, suggest or benchmark rents, and every price on the page is exactly what it would be with Velocity switched off. Even the Revenue strategy only reads the rent the operator has already set, together with floor plan size, in order to sort by it.

Does Velocity track website visitors?

No. Velocity reads no visitor or site-interaction data: no clicks, page views, sessions or favorites. Its only input is the leasing record from the property’s data feed, so it needs no visitor tracking, and the order one renter sees is never shaped by how another renter browsed.

How much leasing history does Velocity need?

Velocity builds its history from the property’s Engrain SightMap feed, reading it twice a day and recording changes in availability and base rent. Balanced occupancy and Fastest moving apply on their own once 30 days of that history exist, and the settings screen shows the progress until they do. A floor plan’s median days available is drawn from a 365-day window and calculated only once at least five availability spells for that plan have completed, so Fastest moving starts working plan by plan rather than all at once. Availability already under way when collection began is recorded as a lower bound rather than guessed. Revenue uses current rent and floor plan size, so it needs no history and applies immediately.

What happens if the data feed fails?

A failed or untrusted feed records nothing, so an outage never becomes a lease. An empty payload never removes units, and a guard across every property we serve holds back mass removals for a few cycles. A property whose feed has been stale for more than three days isn’t ranked. If measurements fail for any reason, the property simply shows its units in the normal order.