What the leasing office knows: introducing WP FloorMap Velocity

Ask a leasing manager which units will be trouble this month and the answer arrives before the question is finished: 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, those two units sit side by side under the same ‘Available now’, in whatever order their availability dates happen to put them.

Velocity is a new part of WP FloorMap that closes that gap. It keeps a leasing history for every unit and every floor plan, built from the property’s own data feed, and uses it 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 of any kind.

Four strategies

A list of available units looks neutral, but it is not. The first cards get read closely, and most renters are scrolling by the time they are halfway down. 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 screen’s own words ‘so aging inventory gets the impressions instead of the units that would have leased anyway’. It works on the same reasoning as a concession, without reducing the rent. This is what most operators want, 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: 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, not just units

Velocity measures at two levels. Every available unit has its days on the market. Every floor plan has a record of its own: the median days a unit of that plan takes to lease, and the age of the oldest unit of that plan still available. The second measurement is what turns ordering into promotion. A renter doesn’t really compare forty vacancies; she compares a handful of layouts, and 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 names the surfaces 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. 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. Nothing is hidden either. 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 all four strategies, 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: 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. If they disagree, it keeps the curated order instead: interleaving two different notions of best produces a list that means nothing, and we’d rather show the order an editor chose than invent one.

Order, never price

Velocity changes the order in which units appear. It never changes 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.

We state that without qualification because 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. Velocity pulls one: 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, which moves it by giving up rent. Balanced occupancy moves it by putting it where renters are already looking, and leaves 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; the record needs the number that moves only when the rent does.

It reads leases, not visitors

Much of the software that reorders a web page learns from the people looking at it. Velocity reads nothing of the kind: 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

Velocity is part of WP FloorMap on every plan, and it 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; the history takes longer. Balanced occupancy and Fastest moving apply on their own 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 also needs several completed leases on a floor plan before it can say anything about that plan, so it starts working plan by plan. Revenue has nothing to wait for and Off measures nothing at all. 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, without watching anyone and without touching a rent. 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 portfolio surfaces. 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 at all, 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?

Nothing is invented. 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.