Book a demo
Book a demo

Author: Daria/SEO

Standardization without uniformity: How multifamily portfolios can control move operations while supporting property-level needs

Posted on by Daria/SEO

Enterprise operators face a recurring tension every time they try to standardize move operations across a portfolio. Corporate wants every property to present the same ancillary offers, enforce the same insurance requirements, and deliver the same resident experience. Site teams, meanwhile, are managing real differences: a downtown high-rise has a different vendor landscape than a garden-style community two hours away, and a property with a younger resident base engages differently than one with a more established one. Push standardization too hard, and it becomes a policy that looks good on paper but gets quietly ignored at the property level. Leave too much to local discretion, and the portfolio ends up with the performance variance that shows up in inconsistent ancillary revenue and uneven insurance compliance.

The answer is not choosing between centralized control and property-level flexibility. It is knowing precisely where each one belongs. Multifamily operational standardization succeeds when it standardizes what actually needs to be uniform- revenue capture, insurance enforcement, resident-facing workflow- while leaving room for genuine market and community differences everywhere else.

This is not a new problem for enterprise operators. Still, it has historically been difficult to solve because standardization and flexibility have usually been treated as opposites on a single dial: turn one up and the other necessarily goes down. In practice, they operate on different axes entirely. An operator can keep required tasks uniform across every property while still giving site teams real discretion over tasks that were never supposed to be standardized in the first place. The failure mode is not too much standardization or too much flexibility. It is applying either one to the wrong category of task.

Why centralized standards matter

Move coordination is one of the few resident touchpoints that happens, without exception, at every single property in a portfolio. That makes it one of the highest-leverage places to apply centralized standards, because even small inconsistencies at the property level compound into meaningful portfolio-wide gaps.

Centralized standards matter most in three areas. Revenue capture needs to be consistent, because ancillary offers, movers, packing, storage, insurance, utilities, and internet generate different amounts of income depending entirely on whether they are presented to every resident or only to some. Insurance enforcement needs to be consistent, because a portfolio’s liability exposure is only as strong as its weakest-performing property. The resident experience also needs a baseline of consistency, since residents increasingly expect the same quality of onboarding regardless of which community they lease from within the same brand.

Without centralized standards in these three areas, portfolio standardization in property management becomes aspirational rather than operational, a policy document that exists but does not reliably shape what happens at the property level.

Where properties genuinely need flexibility

Not every part of the move process should be standardized identically across every property, and treating every difference as a compliance failure is a mistake. Some variation reflects real operational realities rather than inconsistent execution.

Market-specific vendor relationships are one clear example. A property in a dense urban submarket may have access to a wider range of moving companies and service partners than a property in a smaller or more rural market. Forcing identical vendor options across dramatically different markets does not create consistency; it creates a policy that some properties simply cannot fulfill.

Resident demographic differences are another legitimate source of variation. A property with a high volume of corporate relocations will need a different move-in communication cadence than a property serving primarily local renewals. Staffing structure differences also matter: a larger property with a dedicated move coordinator can absorb certain manual tasks that a smaller, leaner-staffed property genuinely cannot.

The goal is not to eliminate these differences. The goal is to ensure they exist within a standardized framework, not to replace the framework entirely.

Required tasks versus optional tasks

The clearest way to reconcile centralized control with property-level flexibility is to explicitly separate move-related tasks into two categories: required and optional.

Required tasks are tied directly to revenue capture and risk mitigation, and they should be non-negotiable across every property, regardless of market or staffing differences. Presenting ancillary service offers to every eligible resident, verifying proof of insurance before move-in, and enforcing minimum coverage requirements all belong in this category, because inconsistency here directly costs the portfolio revenue and increases liability exposure.

Optional tasks are the ones where property-level judgment genuinely improves the resident experience without compromising revenue or compliance. The specific communication cadence for move-in reminders, the tone of resident-facing messaging, or which secondary vendor a property chooses to highlight when multiple approved options exist, can reasonably vary by property without creating portfolio risk.

Task typeExamplesStandardization approach
RequiredInsurance verification, ancillary offer presentation, minimum coverage enforcementUniform across every property, no local exceptions
OptionalCommunication cadence, vendor emphasis, resident messaging toneProperty-level discretion within approved parameters

This distinction gives regional and site teams a clear answer to the question that otherwise causes friction: which parts of the move process can we adapt, and which parts are fixed regardless of our local market.

Accounting for vendor differences by market

Vendor availability is one of the most common reasons standardization efforts break down at the property level, and it deserves a deliberate approach rather than a blanket policy. Rather than mandating identical vendors across every market, a more durable approach standardizes the categories of service that must be offered- movers, packing, storage, insurance, utilities, internet- while allowing the specific vendor partners fulfilling each category to vary by market based on actual local availability.

This preserves the required-task standard: every resident sees the same categories of ancillary offer, while acknowledging that a rigid single-vendor mandate is simply unworkable across a portfolio spanning multiple metros and submarkets. It also gives regional teams a legitimate, documented reason for vendor variation, rather than leaving vendor choice as an undocumented, ad hoc decision made independently at each property.

 

Governance: who owns the standard

Standardization efforts frequently fail not because the standard itself is wrong, but because no one is clearly responsible for maintaining it once it is rolled out. Effective governance assigns clear ownership at two levels.

At the portfolio level, a centralized team, typically a regional or corporate operations function, owns the required-task list, updates it as insurance requirements or vendor partnerships change, and is responsible for auditing compliance across every property. At the property level, site leadership owns execution within the approved optional-task parameters and flags when local conditions genuinely require an exception to the standard, rather than deviating without documentation.

This two-level governance model prevents the two most common standardization failures: a rigid corporate policy that ignores real property-level constraints, and an undocumented patchwork of local exceptions that corporate has no visibility into until performance variance shows up in the financials.

Governance also needs a defined escalation path for exceptions. When a property genuinely cannot meet a required-task standard, limited vendor coverage in a rural submarket, for instance, site leadership should have a clear process for documenting and escalating that exception to the centralized team, rather than quietly working around the standard. A documented exception is a governance input that can inform future policy updates. An undocumented workaround is simply a compliance gap that will eventually show up as unexplained performance variance in portfolio reporting.

Measuring adoption, not just publishing policy

A standardization policy that has been published but not measured is not actually standardized; it is aspirational. Multifamily consistency has to be tracked the same way any other operational metric is tracked, with defined indicators reviewed regularly.

Operators measuring adoption effectively track:

  • Percentage of eligible residents who received every required ancillary offer, by property
  • Insurance verification completion rate, by property, against the portfolio standard
  • Frequency and nature of documented property-level exceptions to required tasks
  • Time from policy update to full property-level implementation
  • Resident experience consistency scores across properties within the same market or brand

Properties that consistently show gaps in these metrics are not necessarily failing to comply deliberately. They are often signaling either a genuine local constraint that governance has not yet accounted for, or an adoption gap that needs direct intervention, and the measurement itself distinguishes between the two.

Adoption metrics also need a consistent review cadence, not just a consistent definition. A metric reviewed only once a year cannot catch a property that drifted from the standard three months after rollout. Reviewing required-task adoption monthly or quarterly, the same cadence most operators already use for occupancy and delinquency reporting, keeps standardization current rather than treating it as a one-time initiative that gets checked off and forgotten.

Portfolio reporting that supports both control and flexibility

The final piece of a durable standardization approach is reporting that gives corporate leadership visibility into required-task compliance without erasing the legitimate property-level differences that governance has already approved. A useful portfolio report separates required-task adherence, which should show minimal variance across properties, from optional-task execution, where variance is expected and does not indicate a problem.

This separation matters because it prevents a common reporting failure: treating every property-level difference as a red flag, which trains regional teams to hide legitimate local adaptations rather than document them. When reporting distinguishes required compliance from optional variation, it becomes possible to standardize what actually needs to be uniform while giving properties room to operate within their real market conditions.

Reporting cadence matters as much as reporting structure. Required-task compliance should be visible to portfolio leadership regularly, not surfaced only during an annual audit or after a compliance issue has already materialized at a specific property. Building this reporting into the same regular operating rhythm used for other portfolio metrics keeps standardization a living practice rather than a policy revisited only after something has already gone wrong.

How Moved supports standardization without forcing uniformity

Embedding move-related tasks directly into the resident onboarding workflow is what makes required-task standardization enforceable rather than aspirational. When ancillary offer presentation and insurance verification happen through the same digital workflow at every property, compliance doesn’t depend on individual staff members remembering to follow policy, removing the primary source of standardization failure described earlier.

At the same time, a workflow built for multifamily operators can accommodate market-specific vendor networks and property-level messaging within that same standardized structure, so operators are not forced to choose between portfolio-wide consistency and the operational realities of individual communities. Required tasks stay uniform. Optional tasks stay flexible. Governance and reporting can see both clearly.

Frequently asked questions

How do multifamily operators standardize processes across properties?


 Operators standardize processes by separating move-related tasks into required and optional categories, enforcing required tasks like insurance verification and ancillary offer presentation uniformly through a standardized digital workflow, while allowing optional tasks such as vendor emphasis or communication cadence to vary within approved parameters based on local market conditions.

How can property managers create consistent resident experiences across portfolios?


 Property managers create consistent resident experiences by embedding required move-related tasks into the same resident onboarding workflow at every property, so that every resident receives the same ancillary offers and insurance verification regardless of which community they lease from, while still allowing property-level flexibility on details that do not affect revenue or compliance.

Consistency where it counts, flexibility where it’s earned

Standardization without uniformity is not a compromise between control and flexibility. It is a more precise version of control, one that identifies exactly which parts of the move process need to be identical across every property and which parts can legitimately vary. Operators who make this distinction explicit, govern it deliberately, and measure adoption consistently are the ones who close portfolio performance variance without forcing every community into an identical operating model that ignores real market differences.

Operators ready to standardize required move tasks across their portfolio while preserving property-level flexibility can explore how Moved for multifamily operators works, or reach out directly to discuss a governance model for a specific portfolio.

The hidden labor ledger: How much multifamily teams spend coordinating resident moves

Posted on by Daria/SEO

Most multifamily operators can tell you, almost instantly, that their site teams are stretched thin during peak leasing season. What they usually cannot tell you is exactly how much that strain costs. Move coordination, chasing down proof of insurance, fielding move-in questions by phone, and routing approvals between leasing and maintenance rarely appear as their own line item anywhere in the budget. It shows up instead as overtime, as delayed turns, and as staff burnout. The labor cost is real. It’s never documented anywhere an operator can see it.

This is the hidden labor ledger: the administrative hours multifamily teams spend coordinating resident moves that never get quantified, benchmarked, or addressed, because no one has ever built the model to measure them. For enterprise operators managing dozens or hundreds of properties, that unmeasured labor cost compounds into a meaningful drag on operating expenses and, just as importantly, on the staff time that could otherwise be spent on the revenue-generating conversations that move coordination should be creating in the first place.

Multifamily operating expense reduction efforts tend to focus on costs already visible on a P&L: utilities, maintenance contracts, staffing headcount. Labor spent on move coordination rarely appears anywhere on that list, not because it is small, but because no one has built the model to isolate it. That gap is precisely what makes it worth quantifying now.

The visible cost versus the hidden cost of move coordination

Every property budget accounts for the visible costs of turnover and move-in: make-ready expenses, leasing commissions, marketing spend. What almost no budget accounts for is the labor cost of the coordination work happening around every one of those moves. A single resident move touches leasing, maintenance, and often a regional support function, each of which spends time on emails, phone calls, and manual approvals that never get tracked as a discrete cost.

This is the core problem behind property management labor costs: the expenses that get measured are the ones that show up as a single invoice or a single line item. The expenses that get ignored are the ones that are distributed across dozens of small, five-minute tasks performed by multiple staff members, dozens of times per week. Multiplied across a portfolio, those small tasks add up to a labor cost that rivals, and sometimes exceeds, more visible operating expenses.

Email and phone volume: the first hidden cost

The most obvious, and most underestimated, source of hidden labor is the sheer volume of email and phone communication generated by a single move. A resident moving in typically has questions about move-in logistics, utility setup, and required documentation. A resident moving out generates a parallel set of questions about move-out timing, deposit return, and forwarding logistics.

None of this communication is inherently unproductive. The problem is that it is almost entirely manual, repeated, and untracked. A leasing consultant answering the same set of move-in questions by phone for the fifteenth time this month is spending time that could otherwise go toward presenting ancillary services, movers, packing, storage, and insurance that generate revenue rather than simply administering the move. Every hour spent on repetitive move-related communication is an hour not spent on the resident-facing tasks that actually drive ancillary income.

Manual approvals: the second hidden cost

Move-related approvals, insurance documentation review, move-in date confirmations, deposit and fee adjustments are another significant source of hidden labor. These approvals typically require a staff member to review a document or request manually, confirm it meets policy, and route it to the next person in the chain.

Each approval takes only a few minutes. But approvals rarely happen in one pass. A single resident move can generate multiple rounds of back-and-forth if documentation is incomplete, if insurance proof is missing required coverage limits, or if a date change requires re-approval. Multiplied across a portfolio processing hundreds of moves per month, manual approvals become one of the largest and least visible sources of administrative labor.

Cross-team handoffs: the third hidden cost

No single team owns a resident move. Leasing initiates the process, maintenance prepares the unit, and in many organizations, a regional or centralized support function handles insurance verification or compliance review. Every handoff between these teams introduces coordination overhead: someone has to communicate status, flag exceptions, and confirm next steps.

Cross-team handoffs are particularly costly because they are asynchronous by nature. A leasing consultant may complete their portion of a move and then wait, sometimes days, for maintenance or a support team to confirm the next step, during which time the resident is often the one following up to check status. That follow-up communication becomes yet another layer of labor that was never accounted for in the original move-related task list.

Quantifying the staff hours behind a single move

Multifamily labor efficiency starts with a basic but rarely completed exercise: quantifying how many staff hours a single move actually consumes, across every team involved. When operators walk through this exercise, a consistent pattern emerges.

Task categoryTypical staff time per moveTeam primarily involved
Move-in and move-out email/phone communication30–45 minutesLeasing
Insurance and documentation review15–25 minutesLeasing or centralized support
Cross-team status updates and follow-up15–20 minutesLeasing and maintenance
Manual approval routing10–15 minutesLeasing or regional support
Exception handling (missing docs, date changes)Variable, often 20+ minutesLeasing

None of these figures looks large in isolation. Added together, a single move can consume well over an hour of distributed staff time before accounting for exceptions, which are common rather than rare. That hour is not spent on presenting movers, packing, storage, or other ancillary offers to the resident. It is spent entirely on administrative coordination that produces no revenue and, if insurance verification is handled manually, still leaves compliance risk on the table.

 

Turning staff hours into cost per move

Once staff hours per move are quantified, translating that into a cost per move is straightforward: multiply the estimated hours by a blended hourly labor rate for the staff involved, then add the cost of any overtime or temporary staffing that peak leasing periods typically require. For an operator processing a meaningful volume of moves per month across a portfolio, this calculation frequently reveals a labor cost per move that rivals other, more visible line items in the operating budget.

This is the number that tends to change how operators think about administrative labor. It is one thing to know that site teams are busy during turnover season. It is another to see a specific dollar figure attached to the coordination work behind every single move, and to recognize that reducing it does not require adding headcount. It requires removing the manual, repetitive coordination work in the first place.

Building a portfolio-level labor model

Cost per move only becomes strategically useful once it is modeled across the full portfolio rather than a single property. A portfolio-level labor model takes the cost-per-move figure and multiplies it by expected move volume across every property, then breaks the result down by region, property type, or staffing structure to identify where administrative labor is concentrated.

Building this model gives operators a defensible, quantified basis for two decisions that are otherwise difficult to justify: where to prioritize automation investment, and how to measure the return once it is in place. Properties with the highest cost-per-move labor burden are typically the best candidates for standardizing and automating the move workflow first, since that is where labor savings will be largest and materialize fastest.

This kind of model also gives regional and asset managers a way to compare labor efficiency across properties the same way they already compare occupancy or delinquency, on a standardized, portfolio-wide basis rather than through informal reports of which sites “seem” understaffed. That distinction matters when the model is used to justify budget or staffing decisions to ownership.

A useful portfolio-level labor model typically includes:

  • Estimated staff hours per move, broken down by task category and team
  • A blended hourly labor rate reflecting the mix of staff involved in move coordination
  • Total cost per move, calculated consistently across every property
  • Portfolio-wide monthly and annual labor cost tied specifically to move coordination
  • A baseline against which future automation-driven labor savings can be measured

How embedding the move workflow reduces the hidden labor ledger

The most effective way to reduce property management labor costs tied to move coordination is not to add staff. Instead, remove the manual work by embedding movers, packing, storage, utilities, insurance, and internet directly into the resident onboarding workflow, so residents can complete move-related tasks and access services without generating a new round of emails, phone calls, or manual approvals for site staff.

When insurance verification happens automatically rather than through manual document review, the approval labor described earlier largely disappears, along with the compliance risk that comes from inconsistent manual enforcement. When resident move-in and move-out questions are answered through a standardized digital workflow rather than repeated phone calls, leasing staff recover hours that can be redirected toward higher-value, revenue-generating resident interactions. This is how a labor efficiency initiative becomes a revenue initiative. Every hour of administrative coordination removed from a leasing consultant’s day is an hour that can instead go toward presenting the ancillary services that drive ancillary income for the property.

Measuring labor savings from automation

Operators evaluating whether a move workflow investment is paying off should track the same metrics used to build the original labor model, now measured after implementation:

  1. Staff hours per move, benchmarked against the pre-automation baseline
  2. Reduction in move-related email and phone volume per property
  3. Reduction in manual insurance verification and approval routing time
  4. Change in labor cost per move, calculated using the same blended hourly rate as the original model
  5. Portfolio-wide labor cost savings, annualized and compared against the cost of the automation investment itself

Because the original labor model was built with a defensible baseline, post-implementation results can be measured against it directly, rather than relying on anecdotal reports that staff “feel less busy.” This is what makes labor savings from automation a metric multifamily operators can present to ownership groups with the same rigor as any other operating expense reduction initiative.

Frequently asked questions

How can multifamily operators reduce administrative labor?


 Operators reduce administrative labor by embedding move-related tasks, insurance verification, service scheduling, and resident communication into a standardized digital workflow, removing the manual emails, phone calls, and approval routing that otherwise consume site staff time on every move.

What property management tasks create the most wasted staff time?


 The tasks that create the most wasted staff time are repetitive move-in and move-out communication, manual insurance and documentation review, and cross-team handoffs between leasing, maintenance, and support staff, since each of these is typically handled manually and repeated on nearly every move.

How can operators measure labor savings from automation?


 Operators measure labor savings from automation by first quantifying a baseline cost per move, staff hours multiplied by a blended labor rate, and then tracking the same metrics after implementation to calculate the reduction in staff hours, communication volume, and labor cost per move across the portfolio.

The hidden ledger is worth writing down.

The labor cost of resident move coordination has always existed. It has simply never been written down as its own line item, which is exactly why it has been so difficult to reduce. Quantifying staff hours, translating them into a cost per move, and modeling that cost across the full portfolio gives operators the same rigor for administrative labor that they already apply to every other operating expense, and it reveals a source of savings that requires removing manual work rather than adding staff.

Operators ready to quantify their hidden labor ledger and see how much staff time an embedded move workflow could recover can explore how Moved for multifamily operators works, or reach out directly to walk through a labor model for a specific portfolio.

The portfolio variance problem: Why the same move process produces different results across properties

Posted on by Daria/SEO

Every multifamily operator eventually runs into the same puzzle. Two properties in the same portfolio, run on the same policies, staffed through the same training program, and supported by the same vendor network, still produce different results. One community converts ancillary offers at a healthy rate, keeps insurance compliance above 90 percent, and shows minimal revenue leakage during turnover. Another, operating under an identical playbook, quietly underperforms every quarter.

This is the portfolio variance problem, and it is one of the most financially significant and most frequently overlooked blind spots in multifamily operations. A move event is not a single transaction. It is a sequence of resident touchpoints, staff decisions, and vendor handoffs that, multiplied across a portfolio, either compounds into ancillary revenue and reduced liability exposure, or quietly erodes both. Understanding why performance varies across seemingly identical properties, and building a system to catch it early, is now a core competency for enterprise operators.

Why standardized policies don’t guarantee standardized outcomes

Operators often assume that once a move-in and move-out policy is documented and rolled out, execution will follow consistently across the portfolio. In practice, a written policy only sets the ceiling for performance. What actually happens at the property level, resident by resident, determines whether that ceiling is reached.

This is the gap that shows up in multifamily performance variance reports: the same resident onboarding workflow, applied across properties, produces different ancillary conversion rates, insurance compliance rates, and resident satisfaction scores. The policy is constant. The execution is not. Understanding property operations benchmarking as a discipline, rather than a one-time audit, lets operators see this gap before it shows up in the financials.

The forces driving property-level variance

Multifamily portfolio benchmarking consistently points to five underlying forces that create variance between properties, even under identical corporate policy.

Property-level adoption. A new resident onboarding process is only as strong as the site team’s willingness to use it consistently. Some communities fully integrate move coordination into their leasing and turnover routines. Others treat it as an optional add-on, especially during high-volume leasing seasons, which quietly suppresses ancillary revenue and insurance verification rates.

Staff behavior. Turnover, training gaps, and inconsistent onboarding at the property management level all shape how residents experience the move process. A well-trained leasing consultant who proactively introduces movers, packing, and storage options during lease signing will generate materially different ancillary outcomes than a property where the same offers are mentioned only in passing, or not at all.

Vendor availability. Local market conditions affect which service partners, from movers to internet providers, are realistically available to residents in a given metro or submarket. A property in a dense urban market may have broad vendor coverage. In contrast, a suburban or secondary-market property may see lower resident engagement simply because fewer relevant options are presented.

Resident engagement. Demographic differences, lease type, and household composition all influence how residents interact with move-related offers. Renewal-heavy properties will show different engagement patterns than properties with high move-in volume, and communities with a younger resident base may respond differently to embedded service offers than those with a more established resident population.

Revenue variance. All of the above compound into the metric operators ultimately track: ancillary revenue per move event. Two properties with identical unit counts and similar resident demographics can post significantly different ancillary revenue per turn, purely because of how consistently the move workflow was executed.

Left unaddressed, these five forces do not stay contained to a single property. Because leasing staff moves between communities, because vendor networks shift with market conditions, and because resident demographics change with every lease cycle, the variance gap tends to widen rather than close on its own. A property performing well this quarter can slip the next if a strong leasing consultant leaves, or if a preferred moving vendor exits a submarket. This is why property operations benchmarking must be treated as an ongoing discipline rather than a one-time diagnostic.

What unmanaged variance actually costs operators

The financial impact of portfolio variance is easy to underestimate because it rarely shows up as a single, visible loss. Instead, it accumulates quietly across three areas that matter most to enterprise operators.

Revenue leakage is the most direct cost. When ancillary offers, movers, packing, storage, utilities, insurance, and internet are inconsistently presented across the portfolio, the properties with weaker adoption simply generate less revenue per move, and that gap widens every turnover season.

Insurance and liability exposure is the less visible but higher-stakes cost. Properties with inconsistent insurance verification carry disproportionate compliance risk. A portfolio-wide policy requiring proof of renters insurance means little if enforcement varies property to property, since the operator’s overall risk exposure is only as strong as its weakest-performing site.

Operational inefficiency compounds both. Properties that rely on manual coordination for move-related tasks spend more staff hours per move, which further reduces the bandwidth available to present revenue and compliance opportunities to residents consistently.

Portfolio scalability is where these costs ultimately surface for ownership groups and asset managers. An operator planning to acquire additional properties, or scale an existing portfolio, needs confidence that a new community will perform in line with existing assets within a reasonable ramp-up period. When performance depends heavily on which staff happens to be on-site, that confidence is difficult to establish, and it becomes a real underwriting risk rather than a theoretical one. Standardized execution is what allows an operator to project ancillary revenue and compliance performance for a new acquisition with the same confidence as an established property.

Variance driverWhat it looks like on-siteFinancial or risk impact
Property-level adoptionMove workflow treated as optional during peak leasingSuppressed ancillary revenue per move
Staff behaviorInconsistent presentation of mover, packing, and storage offersWide swings in conversion across similar properties
Vendor availabilityFewer relevant service partners in secondary marketsLower resident engagement, regardless of policy quality
Resident engagementDemographic and lease-type differences across propertiesUneven ancillary revenue per move event
Insurance enforcementInconsistent proof-of-insurance verificationElevated portfolio-wide liability exposure

How Moved standardizes execution across every property

Closing the variance gap requires more than a better-written policy. It requires embedding the revenue-generating and risk-mitigating steps of the move process directly into the resident onboarding workflow, so execution doesn’t depend on which property, which staff member, or which week of the leasing season a resident happens to move in.

Moved is built as move infrastructure rather than a task-tracking tool. Movers, packing, storage, utilities, insurance, and internet are presented consistently to every resident through the same digital workflow, regardless of property-level staffing or training gaps. Insurance verification is enforced automatically rather than relying on manual follow-up, closing the compliance gap that drives much of the liability variance operators see between properties. Because the workflow is standardized and centrally managed, multifamily operators gain visibility into ancillary conversion, insurance compliance, and move-related revenue at the property level, not just the portfolio level, which is what makes benchmarking possible in the first place.

Identifying outlier properties before they cost you

Multifamily performance variance is only manageable once it is measurable. Operators who successfully close the gap between high- and low-performing properties tend to track a consistent set of indicators across the portfolio:

  • Ancillary revenue per move-in and per move-out, benchmarked against the portfolio average
  • Insurance verification and compliance rate by property
  • Percentage of eligible residents who received and engaged with move-related service offers
  • Average staff hours spent coordinating each move manually
  • Resident satisfaction and complaint volume tied specifically to the move process

Once these metrics are tracked consistently, outlier properties become visible quickly. A property performing meaningfully below the portfolio average on ancillary revenue or insurance compliance is not necessarily a staffing problem. It signals the need to investigate adoption, vendor coverage, and resident engagement at that site before the gap widens further.

It also matters how variance is measured, not just what is measured. Comparing a property purely against the portfolio-wide average can be misleading if that portfolio spans different market types, unit mixes, or resident demographics. A more useful approach groups properties into comparable cohorts, similar market tier, similar unit count, similar resident profile, and benchmarks within those cohorts first. This surfaces genuine execution gaps rather than differences driven by market conditions, and it gives asset managers a defensible basis for prioritizing which properties need intervention first.

A corrective action framework for closing the gap

Identifying variance is only the first step. Enterprise operators need a repeatable process for closing the gap once an outlier property is identified.

  1. Benchmark every property against portfolio averages for ancillary revenue, insurance compliance, and resident engagement regularly, not as a one-time audit. A single snapshot cannot distinguish a temporary dip from a structural adoption problem.
  2. Investigate root causes at underperforming properties: adoption gaps, staffing turnover, vendor coverage limitations, or resident demographic differences. The corrective action for a staffing gap looks nothing like the corrective action for a vendor coverage gap, so root-cause investigation has to come before any fix is applied.
  3. Standardize the resident-facing workflow so that execution does not depend on individual staff members remembering to present offers or verify insurance. Workflow-level consistency removes the single point of failure that staff turnover otherwise creates.
  4. Automate insurance verification and compliance enforcement so liability exposure does not vary by property or by staff member. This step alone tends to close the largest share of the risk-related variance operators see across a portfolio.
  5. Re-benchmark on a quarterly cadence to confirm that corrective action is closing the variance gap rather than simply shifting it elsewhere in the portfolio. Variance that reappears at a different property after being addressed at one site is usually a sign of a systemic gap, such as vendor coverage, rather than a site-specific one.

This kind of framework turns portfolio variance from an abstract concern into an operational discipline that ties directly to ancillary revenue growth and reduced compliance risk across the entire portfolio.

Frequently asked questions

How do multifamily operators benchmark property performance?
 Operators benchmark property performance by tracking a consistent set of move-related metrics, ancillary revenue per move, insurance compliance rate, resident engagement with service offers, and manual coordination hours, across every property regularly, then comparing individual properties against the portfolio average to identify outliers.

Why does operational performance vary across apartment communities?
 Operational performance varies because written policies do not guarantee consistent execution. Differences in property-level adoption, staff behavior, local vendor availability, and resident demographics all influence how the same move workflow performs from one community to the next.

How can operators identify property-level variance?
 Operators identify property-level variance by measuring ancillary revenue, insurance verification rates, and resident engagement at the individual property level rather than only at the portfolio level, then flagging properties that fall meaningfully below the portfolio average for further investigation.

Closing the variance gap starts with standardized infrastructure.

The properties in a portfolio that consistently outperform their peers over multiple leasing cycles are rarely the ones with the best-written policy. They are the ones where execution does not depend on which staff member is on shift or how a particular resident is onboarded. Standardizing the move process across every property, and measuring performance consistently enough to catch variance early, is what turns move coordination into a source of portfolio-wide revenue rather than a portfolio-wide risk.

Operators ready to close the gap between their best- and worst-performing properties can see how a standardized, revenue-aligned move workflow applies across a full portfolio by exploring Moved for multifamily operators, or reaching out directly to discuss a specific portfolio’s variance profile and how a benchmarked, embedded move workflow would apply to it.

The Resident Journey Data Layer: What Multifamily Operators Can Learn From Move Events

Posted on by Daria/SEO

Every move generates data. What a resident requests, what they ultimately purchase, when they make each decision, and how their behavior compares to residents at other communities in the portfolio  all of it is captured somewhere in the move workflow. The problem for most operators isn’t a lack of data. It’s that move-event behavior gets treated as administrative exhaust instead of operational and revenue intelligence.

A resident journey data layer changes that. Instead of treating each move as a one-time transaction to process and forget, operators can treat the aggregate pattern of resident requests, purchases, and timing as a continuous signal  one that informs vendor strategy, pricing structure, and portfolio-level decisions long after any single resident has moved in.

This matters because move events are one of the few points in the resident lifecycle where behavior is both frequent and financially consequential. Unlike a lease renewal, which happens once a year at most, move-in and move-out events happen constantly across a portfolio every unit turn, every new lease, every relocation generates another data point. Treated individually, each of those data points is a completed task. Treated collectively, they form a live, ongoing picture of how residents actually behave, one that updates every time a new resident moves through the workflow.

Move events as behavioral data.

Every move event a lease signing, a move-in, a move-out  is a sequence of resident decisions made under time pressure, with real money attached. Which mover did the resident request a quote from first? Did they compare storage options before choosing one, or book the first offer they saw? Did they need multiple reminders before verifying insurance, or complete it immediately?

None of these decisions happen in isolation, and none of them are random. They reflect real resident behavior shaped by timing, trust, and friction the same forces that drive conversion. The difference between treating move events as paperwork and treating them as behavioral data is the difference between processing a move and learning from it.

Operators who capture this data at the individual level, then aggregate it across hundreds or thousands of move events, get access to a pattern library no single property manager could build from memory. That pattern library is the foundation for smarter vendor decisions, more accurate revenue forecasting, and portfolio strategy that’s grounded in what residents actually do rather than what operators assume they do, replacing anecdote with a data set large enough to be trusted.

What residents request

The first layer of signal is request behavior what services residents ask about, click into, or start a quote for, regardless of whether they ultimately purchase. Request data is valuable precisely because it captures interest that a pure purchase metric misses. A resident who requests a storage quote but doesn’t complete the booking is still telling the property something: storage was relevant to their move, even if the offer, price, or timing didn’t convert them.

Tracking requests separately from purchases lets operators see where interest exists without assuming that interest failed to matter. It also surfaces demand for services the property may not currently offer. If a meaningful share of residents are searching for packing supplies or short-term storage that isn’t part of the existing vendor lineup, that’s a direct signal to expand the ancillary service offering rather than guessing at what residents might want.

Request data is also a useful early forecasting signal. A spike in insurance-related requests two weeks before a batch of leases turn over gives the property team advance notice to make sure verification capacity and vendor response times can keep pace with demand, rather than discovering a bottleneck only after residents start missing lease deadlines.

Services purchased

Purchase data is the second, more concrete layer  what residents actually bought, from which vendor, at what price point. This is where request behavior becomes revenue, and it’s the metric most directly tied to ancillary income performance.

Looking at purchase data in isolation tells you what happened. Looking at it against request data tells you why. A service category with high requests but low purchases has a conversion problem somewhere in the path  pricing, vendor selection, checkout friction. A service category with both low requests and low purchases likely has an awareness problem: residents don’t know the option exists, or it isn’t being surfaced at a moment when they’re paying attention.

Data layerWhat it showsWhat it’s used for
RequestsResident interest and intentIdentifying demand and gaps in offerings
PurchasesCompleted ancillary transactionsMeasuring actual revenue performance
Requests vs. purchasesWhere interest fails to convertDiagnosing pricing, vendor, or friction issues

Timing patterns

The third layer is when residents make each decision, not just what they decide. Timing patterns reveal the actual decision windows for each service  often different from the assumptions built into a standard onboarding checklist. If the data shows most residents finalize moving company selection within 48 hours of signing a lease, but the standard onboarding email doesn’t surface moving services until move-in week, that’s a mistimed offer showing up clearly in the data, not just as a theory.

Timing data compounds in usefulness over time. A single move event’s timing tells you about one resident. Aggregate timing data across a portfolio tells you about the actual decision calendar residents follow information that can reshape when the entire onboarding workflow presents each ancillary offer, portfolio-wide. It can also reveal that timing windows shift by season, lease length, or resident type, insight a single move event could never surface but that becomes clear once enough data accumulates.

Property-level differences

Not every community behaves the same way, and the resident journey data layer makes those differences visible instead of assumed. A downtown high-rise with a younger resident base may show different storage demand than a suburban garden-style community with more established households. A property in a market with strong local moving competition may show lower moving-service conversion than a property where the vendor network is the clear, trusted default.

These differences matter because a single, portfolio-wide vendor strategy applied without property-level context will underperform at some properties and overperform at others without anyone knowing why. Comparing resident journey data across properties  same metrics, same definitions  lets operators see which differences are meaningful (a real market or demographic pattern) and which are noise (a temporary staffing gap or a vendor having a bad month at one location).

This is also where portfolio-wide averages can mislead. A blended, portfolio-level conversion rate for storage services might look healthy overall while masking the fact that three specific communities are dragging the average down. Meanwhile, the rest of the portfolio performs well above it. Without property-level visibility inside the resident journey data layer, those three underperforming communities stay hidden inside a number that looks fine at the top line and the revenue left on the table at those specific properties never gets addressed.

Using data for vendor strategy

Resident journey data turns vendor management from a relationship-based decision into an evidence-based one. Instead of renewing a vendor contract because the relationship has been in place for years, operators can review request-to-purchase conversion, response timing, and property-level performance for that vendor and make a renewal decision grounded in resident behavior.

This also strengthens vendor negotiations. An operator who can show a vendor exactly where residents drop off  slow response times, a checkout flow that doesn’t match resident timing patterns, weak conversion in specific markets is negotiating from data, not guesswork. That data can inform which vendors get expanded resident volume, which need a corrective conversation, and which should be replaced with a better-performing alternative.

Evidence-based vendor strategy also changes the tenor of the conversation itself. A renewal discussion grounded in “residents in your service area have a conversion rate 15 points below the portfolio average, and response time has grown from same-day to 48 hours over the last two quarters” gives the vendor something specific to address, rather than a vague sense that the relationship “isn’t working.” It’s a more productive conversation for both sides, and it gives operators a documented basis for the decision if the vendor doesn’t improve.

Using data for portfolio decisions

At the portfolio level, resident journey data supports decisions well beyond individual vendor management. Aggregate timing patterns can reshape the standard onboarding workflow across every property, not just the ones where a problem was first noticed. Aggregate request data can identify ancillary service categories worth adding to the standard offering across the whole portfolio, rather than testing them property by property. Aggregate property-level comparisons can flag communities that are underperforming their peers on ancillary conversion, prompting a review before the shortfall shows up in quarterly revenue numbers.

  • Use aggregate timing data to standardize when each ancillary offer is presented portfolio-wide
  • Use aggregate request data to identify gaps in the ancillary service lineup.
  • Use property-level comparisons to catch underperformance early, before it compounds.
  • Use vendor-level conversion and timing data to support renewal and negotiation decisions.ns
  • Use seasonal and lease-length patterns to anticipate demand shifts before they show up in vendor capacity strain.

None of this requires guessing at resident behavior. It requires capturing move-event data consistently enough, across enough properties, to see the patterns that were always there just previously invisible because move events were processed as one-off administrative tasks rather than a continuous stream of behavioral data. The shift is less about collecting new data and more about aggregating and comparing data that portfolios are already generating with every move.

From administrative exhaust to operational intelligence

A resident journey data layer only works if move-event data is captured consistently across every property, in a structured format that supports comparison  not scattered across separate vendor systems, spreadsheets, and email threads that never get aggregated. That consistency is the hard part, and it’s also where most portfolios lose the value of the data they’re already generating. Without it, even a well-designed scorecard or dashboard is only as good as the incomplete data feeding it.

Moved captures resident request, purchase, and timing data directly inside the resident move workflow, giving operators a consistent behavioral data layer across every community instead of fragments trapped in individual vendor systems. For multifamily operators and ownership groups making vendor and portfolio decisions, that means resident behavior data that’s usable—comparable across properties, tied to revenue outcomes, and available when a renewal or expansion decision needs to be made. Contact the Moved team to see how a structured resident journey data layer compares to your current move-event reporting, or read more on the move-in and move-out process and property management revenue and the ultimate guide to resident onboarding automation.

FAQs

How can multifamily operators use resident journey data? 

Operators can use resident journey data to identify which ancillary services residents are interested in versus which they actually purchase, when each service decision typically happens, and how behavior differs across properties in a portfolio. That data supports evidence-based vendor renewal decisions, portfolio-wide timing adjustments to the onboarding workflow, and early identification of underperforming communities.

What resident behavior should multifamily operators track?

The most useful behaviors to track are service requests (what residents show interest in), completed purchases (what they actually buy), and the timing of each decision relative to lease signing and move-in. Comparing requests to purchases highlights where interest fails to convert, and comparing timing data to the current onboarding workflow shows whether offers reach residents at the right moment.

How does resident journey analytics improve property operations? 

Resident journey analytics replaces guesswork with evidence in three areas: vendor management, since operators can evaluate partners on actual conversion and timing performance; onboarding design, since aggregate timing data shows when each ancillary offer should be presented; and portfolio oversight, since property-level comparisons surface underperforming communities before the gap shows up in revenue reporting.

The Ancillary Vendor Scorecard: 10 Metrics Multifamily Operators Should Track

Posted on by Daria/SEO

Most multifamily portfolios have no shortage of vendors. Movers, packing providers, storage partners, insurance carriers, utility and internet providers  the roster fills up fast. What’s usually missing is a consistent way to tell which of those vendors are actually generating revenue and reducing risk, and which are just names on a list that residents rarely use.

Vendor count gets mistaken for vendor performance more often than operators realize. A portfolio can have a dozen approved moving companies and still see ancillary income underperform because nobody is tracking whether those vendors convert resident interest into completed transactions, deliver reliably, or meet their end of insurance and compliance requirements. A scorecard fixes that. It turns “we have vendors” into “we know exactly which vendors are worth keeping.”

Why vendor count isn’t vendor performance

Adding vendors feels like progress. More options for movers, more insurance carriers, more internet providers it looks like a stronger ancillary program on paper. But a long vendor list without performance data is just administrative sprawl. Each additional vendor adds coordination overhead, dilutes resident attention across too many choices, and makes it harder to enforce consistent insurance verification and compliance standards across the portfolio.

The operators who generate the most ancillary income and carry the least liability exposure aren’t the ones with the longest vendor list they’re the ones actively managing a smaller, higher-performing set of partners against a consistent scorecard. That means moving from “is this vendor approved” to “is this vendor producing revenue, staying compliant, and keeping residents satisfied.” Ten metrics make that evaluation possible.

This shift matters more as portfolios grow. A single property can often manage vendor relationships informally  a leasing manager knows which mover shows up on time and which insurance carrier processes claims quickly, based on lived experience. That informal knowledge doesn’t scale across a multifamily portfolio spanning multiple markets and dozens of communities. Without a shared scorecard, one property’s hard-won vendor knowledge never reaches another property working with the same underperforming vendor. A standardized framework turns individual observations into portfolio-wide intelligence, and it gives ownership groups a consistent basis for renewal, renegotiation, or replacement decisions instead of relying on anecdote.

1. Conversion

Conversion is the starting point of any vendor scorecard, because it’s the clearest signal of whether a vendor is actually generating revenue rather than just sitting on an approved list. For every vendor, operators should track the share of residents who were offered that vendor’s service and actually completed a purchase movers booked, storage units reserved, insurance policies verified.

A vendor with strong brand recognition but weak conversion is quietly costing the portfolio ancillary income every month it stays in rotation. Tracking conversion at the vendor level, not just the category level, is what makes it possible to spot this before it becomes a pattern across an entire portfolio.

2. Revenue per transaction

Conversion tells you how often residents buy. Revenue per transaction tells you how much each purchase is worth to the property. Two vendors can have identical conversion rates and produce very different ancillary income if one vendor’s average transaction value is meaningfully higher  whether through a stronger insurance premium structure, higher-margin storage tiers, or a broader packing services package.

Tracking revenue per transaction alongside conversion prevents operators from over-rewarding a vendor purely for volume when a lower-conversion, higher-value vendor might be generating more actual ancillary income.

3. Fulfillment

A booked transaction isn’t the same as a completed one. Fulfillment measures whether the vendor delivered the service as promised—movers who showed up on schedule, storage that was available when needed, insurance that was properly bound and verified. A vendor with strong conversion numbers but weak fulfillment creates a downstream problem: resident complaints, refund requests, and reputational risk that falls back on the property, not just the vendor.

MetricWhat it measuresWhy it matters
ConversionOffers turned into completed purchasesDirect signal of revenue generation
Revenue per transactionAverage value of each completed purchaseShows true ancillary income contribution
FulfillmentServices delivered as promisedProtects resident experience and property reputation

4. Resident satisfaction

Vendor performance isn’t only financial. Resident satisfaction with a vendor collected through post-service surveys, star ratings, or direct feedback is a leading indicator of whether that vendor will keep converting residents over time. A vendor with high conversion today but declining satisfaction scores is a vendor whose performance is about to erode, and operators who only track transactional metrics won’t see the drop coming until conversion has already fallen.

Satisfaction data also protects the property’s own reputation. Residents don’t distinguish between “the property’s insurance offer” and “the property” when a vendor underperforms a bad vendor experience reads as a bad property experience.

5. Complaint rate

Complaint rate is a sharper, more actionable version of satisfaction tracking. Rather than relying on survey response rates, which are often low, complaint rate captures every instance where a resident escalated a problem with a vendor — a missed pickup, a denied insurance claim, a billing dispute.

Tracking complaint rate per vendor, normalized against transaction volume, makes it possible to distinguish between a vendor with a few isolated issues and a vendor with a systemic reliability problem. This metric belongs squarely in the risk mitigation column: unresolved vendor complaints create compliance and liability exposure for the property, particularly around insurance and moving damage disputes.

6. Geographic coverage

For portfolios spanning multiple markets, geographic coverage determines whether a vendor relationship is actually usable at scale. A moving or storage vendor that performs exceptionally well in one metro but has no presence in three others isn’t a portfolio-wide solution  it’s a single-property solution wearing a portfolio-wide label.

Tracking coverage prevents operators from over-relying on a vendor that can’t scale with the portfolio, and it surfaces gaps where a new vendor relationship or a broader partner network is needed to maintain consistent ancillary revenue and compliance standards across every community.

7. Response time

Response time measures how quickly a vendor acts once a resident engages how fast a moving company confirms a booking, how quickly an insurance carrier processes verification, how fast a storage provider confirms availability. Slow response times directly drive lost conversions because move-event intent is time-sensitive. A resident who doesn’t get a timely response often just moves on to a vendor they found on their own.

Response time is also an early-warning metric. A vendor whose response times are creeping upward is often a vendor whose operational capacity is falling behind demand worth flagging before it shows up as a drop in conversion or fulfillment.

8. Compliance

Compliance tracks whether a vendor is meeting the insurance, licensing, and documentation standards required to operate within the portfolio’s risk framework. This includes valid insurance certificates, up-to-date licensing, and adherence to any data handling or resident privacy requirements tied to the partnership.

Compliance is where vendor management most directly supports the property’s liability exposure reduction goals. A vendor scorecard that skips compliance tracking is missing the metric most directly tied to legal and financial risk, not just resident experience or revenue.

9. Complaint resolution and compliance follow-through

Beyond whether a vendor is compliant at onboarding, operators should track whether compliance documentation stays current and whether the vendor resolves flagged issues within an agreed timeframe. A vendor that lets insurance certificates lapse or fails to respond to a compliance flag represents ongoing risk exposure, even if their conversion and revenue numbers look strong. This metric turns compliance from a one-time checkbox into an ongoing performance indicator.

In practice, this means setting a defined response window for compliance issues for example, requiring a lapsed certificate to be resolved within a set number of business days and tracking how consistently each vendor meets that window. A vendor that resolves compliance flags quickly and reliably is a lower-risk partner than one that requires repeated follow-up from the property team, even if both vendors are technically “compliant” on paper at any given snapshot in time.

10. Renewal and retention of vendor relationships

The final metric is a lagging one, but it’s the clearest summary signal available: does the property keep renewing this vendor relationship, and does the vendor keep meeting the terms of that renewal? A vendor with strong renewal history across multiple lease cycles has proven performance across conversion, fulfillment, satisfaction, and compliance simultaneously.

Tracking renewal and retention at the portfolio level also surfaces patterns  if multiple properties are declining to renew the same vendor, that’s a stronger signal than any single property’s experience, and it should prompt a broader review of that vendor relationship.

Building the scorecard

Individually, each of these ten metrics tells operators something about one dimension of vendor performance — revenue, risk, or resident experience. Together, they form a structured framework for deciding which vendors deserve more resident volume and which need to be replaced.

A practical scorecard doesn’t need to weight all ten metrics equally. Revenue-focused metrics — conversion and revenue per transaction — should sit at the top of the evaluation, since ancillary income is the primary reason the vendor relationship exists. Compliance and complaint rate come next, since unresolved risk exposure can outweigh strong revenue numbers if it creates liability for the property. Fulfillment, satisfaction, response time, coverage, and renewal round out the picture, giving operators the operational efficiency layer that supports — but doesn’t replace — the revenue and risk metrics above it.

  • Score vendors quarterly, not annually, so declining performance is caught early
  • Normalize metrics against transaction volume so high-volume vendors aren’t unfairly penalized for raw complaint counts
  • Review scorecards at the portfolio level, not just the property level, to catch patterns a single community might miss
  • Use scorecard results to guide vendor renewal conversations, not just internal reporting

From vendor list to revenue infrastructure

A vendor scorecard only creates value if it’s built on consistent data across every property and every vendor relationship. That’s difficult to maintain manually across a portfolio of any size — tracking conversion, revenue per transaction, fulfillment, and compliance for a dozen vendors across dozens of communities is not a spreadsheet-friendly problem for long.

Moved centralizes vendor performance data directly inside the resident move workflow, so operators can see conversion, revenue per transaction, and compliance status for every moving, storage, and insurance partner without stitching together reports from multiple vendors. For multifamily operators managing partner relationships across a portfolio, that means a consistent scorecard instead of a fragmented one, and a vendor network that’s evaluated on the same ten metrics everywhere it operates. Contact the Moved team to see how a structured vendor performance framework compares to your current approach, or read more on the move-in and move-out process and property management revenue and the ultimate guide to resident onboarding automation.

FAQs

How should multifamily operators evaluate ancillary vendors?

Operators should track vendors against a consistent set of metrics that cover revenue, risk, and resident experience  including conversion, revenue per transaction, fulfillment, compliance, and renewal history. Evaluating vendors only on relationship tenure or brand recognition misses the performance data that actually predicts whether a vendor is generating ancillary income and staying within the property’s risk framework.

What should a multifamily vendor scorecard include?

A complete scorecard should track conversion, revenue per transaction, fulfillment, resident satisfaction, complaint rate, geographic coverage, response time, compliance status, ongoing compliance follow-through, and vendor renewal and retention. Weighting revenue and compliance metrics most heavily keeps the scorecard focused on ancillary income and risk exposure, while the remaining metrics capture operational reliability.

How do operators compare resident service vendors?

The clearest comparison method is normalizing each metric against transaction volume, so high-volume vendors aren’t penalized for raw complaint counts and low-volume vendors aren’t overrated for a small number of positive outcomes. Reviewing scorecards at the portfolio level, rather than per property, also helps operators spot vendor performance patterns a single community might not catch on its own.

 

The Conversion Gap: Why Residents See Ancillary Offers but Don’t Buy

Posted on by Daria/SEO

Every resident who moves into a portfolio touches a moment of enormous financial opportunity. Movers, packing, storage, insurance, utilities, and internet setup are all decisions a resident has to make in a narrow window  and property operators are often standing right there with an offer. Yet most of that exposure never turns into revenue. Residents see the offer, scroll past it, and find their own mover, insurance policy, and internet plan. The impression happened. The purchase didn’t.

This is the conversion gap, and for multifamily operators and ownership groups, it’s one of the most underpriced problems in the resident lifecycle. Ancillary income is treated as a line item that should “just happen” once move-related services are surfaced to residents. In practice, exposure and conversion are two entirely different disciplines, and closing the gap between them is where real revenue lives.

Why exposure isn’t the same as conversion

Sending a resident a list of moving services, insurance options, or utility partners counts as exposure. It does not count as conversion. A resident can see an offer for movers or renters insurance and still walk away, because seeing an option and acting on it require very different things from the resident: attention, trust, timing, and a low-friction path actually to complete the purchase.

Operators frequently measure success by whether the offer was delivered  an email sent, a link included in a welcome packet, a mention on move-in day. But delivery is a vanity metric. The metric that actually reflects revenue is offer-to-purchase conversion: of the residents who saw the moving services, insurance, or utility offer, how many actually bought something?

When that number is low, it’s tempting to blame the offer itself  wrong price, wrong partner, wrong messaging. Often the real issue is structural. The offer arrived at the wrong moment, buried among too many competing choices, or required more effort than the resident was willing to spend during an already stressful move.

This distinction matters financially. A property that reports “90% of new residents received a moving services offer” sounds like a strong ancillary program. But if only 8% of those residents actually booked movers, packed with a partner vendor, or verified insurance through the platform, the real revenue capture rate is closer to 8% than 90%. Ownership groups evaluating ancillary income performance across a portfolio need visibility into that second number, not the first, because the first number describes marketing activity and the second describes revenue.

The conversion gap also compounds at scale. A single property missing conversion on movers, packing, and storage might look like a modest shortfall. Across a multifamily portfolio of dozens or hundreds of communities, that same shortfall represents a structural leak in ancillary income and a missed opportunity to reduce liability exposure through consistent insurance verification. Closing the gap isn’t a marginal optimization  it’s the difference between a move workflow that generates revenue and one that merely documents that an offer was made.

Timing problems: the offer arrives at the wrong moment

Move-related purchasing decisions aren’t made on a single day they’re made across a compressed window, and each service has its own natural decision point.

  • Movers and packing are typically decided weeks before move-in, often as soon as a lease is signed.
  • Storage decisions cluster around the move date itself, when residents realize their new unit can’t hold everything.
  • Insurance and utilities are usually finalized in the days immediately before or after move-in, often under deadline pressure from a lease requirement or a utility provider’s connection date.

If a property operator presents movers, packing, and storage after the resident has already booked their own mover, the offer arrives too late to matter  even though it was technically delivered. Insurance offers pushed too early get lost before the resident is thinking about coverage; pushed too late, and the resident has already defaulted to a generic third-party policy just to hit a lease deadline.

ServiceNatural decision windowCommon timing mistake
Movers & packingImmediately after lease signingOffered on move-in day, after the resident has already booked
StorageAround the move date, once space constraints are clearOffered at lease signing, before the resident knows they need it
InsuranceDays before or after move-in, tied to lease requirementOffered too early (ignored) or too late (resident defaults to a generic policy)
Utilities & internet1–2 weeks before move-in, tied to connection datesBundled into a generic welcome packet with no urgency or deadline

Revenue-generating move infrastructure has to track these decision windows and time each offer to when the resident is actually deciding not when it’s administratively convenient for the property team to send it. This is also where automation earns its place in the workflow: not as the headline value proposition, but as the mechanism that makes precise, resident-specific timing possible at portfolio scale. A single leasing team can’t manually track the decision window for every ancillary service across hundreds of units but a centralized move workflow can trigger the right offer at the right moment for every resident, every time.

Too many choices create decision paralysis.

A second driver of the conversion gap is choice overload. Residents mid-move are already managing dozens of decisions: which utilities to activate, which address to update, what to pack first, when to schedule the truck. Handing them a long, undifferentiated list of vendor options for movers, insurance, and internet doesn’t help  it adds another decision to an already overloaded list.

This is where the sequencing of the offer matters as much as the offer itself. Presenting movers, packing, and storage as a structured next step rather than an open-ended menu of every possible vendor reduces cognitive load and increases the odds a resident completes a purchase instead of deferring the decision entirely, which usually means they never come back to it.

Friction in the purchase path

Even a well-timed, well-sequenced offer fails if completing the purchase takes too many steps. If buying a moving services package or verifying insurance means leaving the resident portal, creating a new account on a third-party site, or manually uploading documents, most residents will abandon the process  not because they didn’t want the service, but because the path to “yes” was too long.

Embedded checkout, pre-filled resident information, and one-click insurance verification all reduce this friction. The difference between an offer that converts and one that doesn’t is often not the price or the partner it’s whether the resident can complete the transaction in the same flow where they discovered the offer.

Consider the difference between two versions of the same insurance offer. In the first, a resident receives an email with a link to a third-party insurer’s homepage, where they have to search for the right policy type, create an account, enter their address and lease terms manually, and upload proof of coverage back to the property separately. In the second, the resident sees a pre-populated policy option inside the resident portal they’re already using, with their unit and lease details filled in automatically, and verification happens instantly once they confirm. The service and the price can be identical. The conversion rate won’t be  because every extra click, every new login, and every manually re-entered field is a point where a busy resident gives up and moves on.

The same logic applies to movers, packing, and storage. A booking flow that requires a phone call to a dispatcher converts at a different rate than one where a resident can select a date, see a price, and confirm in the same portal where they’re already tracking their move-in checklist.

Trust and vendor selection

Residents are cautious about who they hand their address, move date, and payment information to  especially for something as high-stakes as movers or insurance. An offer that comes from an unfamiliar third-party brand, with no context on vetting or reliability, reads as a risk rather than a convenience. Residents have all seen stories about moving scams and unreliable movers, and that hesitation doesn’t disappear just because the offer arrived through a property’s official channel  it disappears only when the offer itself signals that the property has done the vetting.

When moving services and insurance are presented as vetted, property-endorsed options rather than generic ads, trust increases and so does conversion. This is also where insurance verification does double duty: it’s not just a risk-mitigation function for the property; it’s a trust signal for the resident that the coverage on offer meets a real standard rather than being the cheapest option a vendor could find.

For ownership groups, this dual function is worth underscoring. A structured, verified vendor network doesn’t just reduce liability exposure and compliance risk on the property side  it’s also the mechanism that gets residents to convert in the first place. Risk mitigation and revenue generation aren’t competing priorities here; a well-vetted vendor network is what makes both possible at once.

Move-event intent is a narrow, high-value window.

Move-in and move-out are two of the highest-intent moments in a resident’s entire tenancy. Residents are already actively purchasing  movers, packing supplies, storage, insurance, and internet are not hypothetical add-ons; they’re near-certain expenditures the resident will make with someone. The only open question is whether that spend happens through the property’s revenue-generating infrastructure or leaks out to an unaffiliated vendor the resident found on their own.

That’s what makes the conversion gap so costly. It isn’t a marketing failure in the traditional sense the resident’s intent to purchase is already there. The gap is entirely about whether the property’s move infrastructure captures that intent at the right time, in the right sequence, with enough trust and low enough friction to close it.

Measuring offer-to-purchase conversion

To close the gap, operators need to measure the right thing. Impressions, emails sent, and portal logins tell you about exposure. They don’t tell you about revenue. The metric that matters is offer-to-purchase conversion, tracked at each stage of the move lifecycle:

  1. Offer delivered — the resident received the moving services, insurance, or utility offer.
  2. Offer engaged — the resident opened, clicked, or otherwise interacted with it.
  3. Offer converted — the resident completed a purchase or verification.

Tracking all three stages  not just the first  shows operators exactly where residents are dropping off. A portfolio with strong delivery and engagement but weak conversion has a friction or trust problem. A portfolio with weak engagement in the first place has a timing or sequencing problem. Without this breakdown, ancillary income initiatives get evaluated on activity instead of results, and the real cause of underperformance stays hidden.

Turning exposure into revenue

Closing the conversion gap comes down to treating ancillary services  movers, packing, storage, insurance, utilities, and internet  as structured revenue infrastructure embedded directly into the resident move workflow, rather than a list of links dropped into a welcome email. That means:

  • Timing offers to each service’s natural decision window
  • Sequencing choices instead of listing every option at once
  • Reducing the number of steps between offer and purchase
  • Presenting vendors as vetted and property-endorsed, not generic third parties
  • Verifying insurance as both a risk control and a trust signal
  • Measuring conversion at every stage, not just delivery

Residential real estate operators who close this gap aren’t just improving a metric they’re capturing ancillary income that’s already there, in the form of purchases residents were going to make regardless. The question is only whether that revenue flows through the property’s infrastructure or out the door to someone else.

Moved was built to close exactly this gap. By embedding movers, packing, storage, insurance, utilities, and internet directly into the resident move workflow timed to each decision window and verified for risk  Moved turns move-event intent into measurable ancillary revenue instead of missed exposure. For multifamily operators and ownership groups looking to scale this across a portfolio, that means fewer leaked transactions and a move process that’s both revenue-generating and risk-managed. Contact the Moved team to see how a structured conversion model compares to your current move-in and move-out process, or read more on the move-in and move-out process and property management revenue and the ultimate guide to resident onboarding automation.

FAQs

What is a good conversion rate for resident services?

There’s no universal benchmark, since conversion depends heavily on timing, offer sequencing, and how much friction exists in the purchase path. Operators get more value from tracking their own offer-to-purchase trend over time  delivered, engaged, converted than from chasing an industry-wide number. Since portfolios with better-timed, lower-friction move infrastructure consistently outperform those relying on a single generic offer sent at move-in.

How can multifamily operators improve ancillary service conversion?

The highest-leverage changes are timing offers to each service’s natural decision window (movers and packing before move-in, storage near the move date, insurance and utilities close to lease deadlines.) Reducing the number of steps between offer and purchase, and presenting vendors as vetted rather than generic. Measuring conversion at each stage  not just whether the offer was sent makes it possible to diagnose exactly where residents are dropping off.

Why do residents ignore property service offers?

Usually not because they don’t need the service, but because the offer arrived at the wrong moment came with too many undifferentiated choices. Required too many steps to complete, or didn’t carry enough trust signals for a high-stakes decision like movers or insurance. Since residents are already going to purchase these services from someone, ignoring the offer typically means the purchase happened elsewhere  not that it didn’t happen at all.

The multifamily ancillary revenue benchmarking problem: what should operators compare?

Posted on by Daria/SEO

Multifamily operators have no shortage of financial benchmarks.

Rent growth. Occupancy. NOI. Operating expenses. Turn costs. Delinquency. Revenue per unit.

But when the conversation shifts to ancillary revenue, the benchmarking becomes less straightforward.

An operator may know that one property generated more ancillary revenue than another. That does not necessarily mean the first property is performing better.

A larger property will naturally generate more revenue. A property with higher turnover may have more opportunities to generate move-related revenue. A community with stronger resident engagement may outperform another even if both properties have similar unit counts.

The real question is not:

“How much ancillary revenue did the property generate?”

It is:

“How efficiently is the property converting its available resident and move-event opportunities into ancillary revenue?”

That distinction is the foundation of effective multifamily ancillary revenue benchmarking.

For asset managers, revenue leaders, and multifamily ownership groups, the objective should be to build an internal benchmarking framework that compares properties using consistent definitions, relevant peer groups, and normalized metrics.

External benchmarks can provide context, but they should not replace portfolio-specific benchmarks.

The National Apartment Association has long emphasized the importance of internal benchmarking, noting that external comparisons can be difficult when data definitions, charts of accounts, and comparison groups differ.

For ancillary revenue specifically, this makes internal benchmarking especially important.

Why ancillary revenue is difficult to benchmark

Traditional multifamily revenue is relatively easy to understand.

If Property A generates more rental revenue than Property B, the comparison can be normalized using metrics such as revenue per unit, occupancy, market characteristics, and other operating factors.

Ancillary revenue is more fragmented.

It can come from multiple services and resident interactions, including:

  • Moving services
  • Packing
  • Storage
  • Insurance
  • Utilities
  • Internet and connectivity
  • Resident services
  • Other embedded service partnerships

The opportunity also depends heavily on resident lifecycle events.

A property with 500 units and 50% annual turnover does not have the same move-event opportunity as a 500-unit property with 30% turnover.

Likewise, two properties with the same number of move-ins can produce different ancillary revenue depending on:

  • Resident engagement
  • Service availability
  • Service placement
  • Conversion
  • Vendor coverage
  • Property adoption
  • Timing
  • Resident demand

This means total ancillary revenue is an incomplete benchmark.

It tells you what happened.

It does not necessarily tell you how efficiently the property performed.

The benchmarking mistake: comparing total dollars

Imagine two properties:

MetricProperty AProperty B
Units1,000500
Annual move events500250
Ancillary revenue$150,000$100,000

At first glance, Property A appears to be the stronger performer because it generated $150,000 versus $100,000.

But the comparison changes when the revenue is normalized.

Revenue per unit

Property A:

$150,000 ÷ 1,000 = $150 per unit

Property B:

$100,000 ÷ 500 = $200 per unit

Property B is generating more ancillary revenue per unit despite producing less total revenue.

That is why operators should avoid using portfolio totals as the primary benchmarking metric.

Total revenue is useful for financial reporting.

Normalized revenue is more useful for performance comparison.

Benchmarking should start with the right denominator

The denominator determines what the benchmark actually tells you.

For ancillary revenue, there are several useful denominators.

Units

Useful for understanding portfolio-scale economics.

Ancillary revenue per unit = Total ancillary revenue ÷ Total units

Occupied units

Useful when comparing properties with different occupancy levels.

Ancillary revenue per occupied unit = Total ancillary revenue ÷ Occupied units

Move events

Useful when the revenue opportunity is directly connected to resident moves.

Revenue per move event = Attributed ancillary revenue ÷ Eligible move events

Qualified engagements

Useful for evaluating service conversion.

Revenue per engagement = Attributed revenue ÷ Qualified engagements

No single metric answers every question.

The strongest benchmarking framework uses multiple metrics together.

1. Revenue per occupied unit

Revenue per occupied unit: is one of the simplest ways to normalize ancillary revenue.

The formula is:

Revenue per occupied unit = Ancillary revenue ÷ Occupied units

Why use occupied units instead of total units?

Because the number of residents occupying the property represents the active resident base from which many ancillary opportunities originate.

For example:

PropertyAncillary revenueOccupied unitsRevenue per occupied unit
A$150,000950$158
B$110,000475$232
C$180,0001,450$124

Property C generates the most total ancillary revenue.

But Property B has the highest revenue per occupied unit.

That tells the asset manager something important.

Scale and efficiency are not the same thing.

Revenue per occupied unit is therefore useful for portfolio comparisons, but it should not be used alone.

It does not explain why one property performs better.

2. Revenue per move event

For Moved’s revenue infrastructure model, the move event deserves special attention.

A move-in, move-out, or transfer creates a concentrated period of resident activity.

Residents may need:

  • Professional movers
  • Packing supplies
  • Storage
  • Insurance
  • Utilities
  • Connectivity
  • Other move-related services

That makes the move event a more specific denominator for measuring move-related ancillary revenue.

Formula

Revenue per move event = Attributed ancillary revenue ÷ Eligible move events

Consider:

PropertyMove eventsRevenueRevenue per move
A400$120,000$300
B300$120,000$400
C600$120,000$200

All three properties generate the same revenue.

But their performance is clearly different when measured against move volume.

Property B is generating twice the revenue per move of Property C.

That makes the benchmark much more actionable.

Moved’s platform is specifically designed around resident move-ins, move-outs, and transfers, with embedded ancillary services and resident workflows.

For operators using a move-event model, this is a critical distinction:

The question is not only how much revenue the portfolio generates. It is how much revenue each qualified resident event produces.

3. Service penetration

Revenue tells you the financial result.

Service penetration helps explain the level of adoption.

A property could have low ancillary revenue because residents are not engaging with available services.

Alternatively, residents may be engaging heavily but purchasing at a low rate.

Those are different problems.

A simple penetration metric is:

Service penetration = Residents using a service ÷ Eligible residents

For example:

  • 1,000 eligible residents
  • 250 residents use a moving or storage service

Service penetration = 25%

Operators can calculate this separately for:

  • Moving
  • Packing
  • Storage
  • Insurance
  • Utilities
  • Connectivity
  • Other services

This creates a service-level view of the portfolio.

4. Conversion rate

Service penetration tells you how many residents use a service.

Conversion rate tells you how effectively engagement turns into a transaction.

For example:

1,000 residents receive an offer

↓

400 engage with the service

↓

100 complete a transaction

The operator can calculate:

Engagement rate = 400 ÷ 1,000 = 40%

Conversion rate = 100 ÷ 400 = 25%

That distinction matters.

Suppose Property A has:

  • 50% engagement
  • 10% conversion

And Property B has:

  • 25% engagement
  • 30% conversion

Which one performs better?

There is no immediate answer.

Property A has stronger engagement.

Property B converts engaged residents more efficiently.

The right response is not to rank one property and ignore the other.

Instead, investigate the two different bottlenecks.

Property A: Why isn’t engagement converting?

Property B: Why is resident engagement lower?

This is the value of a multi-stage benchmark.

5. Revenue by service category

A portfolio-wide ancillary revenue number can conceal important differences in service performance.

Break revenue down by category.

Example

ServiceRevenue% of ancillary revenue
Moving$400,00040%
Storage$250,00025%
Insurance$150,00015%
Utilities$100,00010%
Connectivity$75,0007.5%
Other$25,0002.5%

This tells the operator where the revenue is coming from.

The next step is to combine revenue with volume.

A high-revenue service with very low penetration could represent an expansion opportunity.

A high-penetration service with low revenue per transaction could require a different economic analysis.

This is why service mix should be part of the benchmark, not just total ancillary income.

6. Revenue by move event

Another useful comparison is to separate revenue according to the resident lifecycle event that created the opportunity.

For example:

Move-in revenue

Revenue generated during resident onboarding.

Move-out revenue

Revenue generated during resident offboarding.

Transfer revenue

Revenue generated when residents move between properties within the same portfolio.

This creates an important portfolio-level view.

If move-ins produce strong ancillary revenue but move-outs produce almost none, the operator has identified a potential gap.

The same applies to portfolio transfers.

Moved’s sales materials specifically position portfolio transfers as an opportunity to capture residents within the network and monetize move-outs rather than allowing the resident relationship to end without another revenue opportunity.

Why move-event benchmarking matters

Consider a 10,000-unit portfolio.

If the operator benchmarks only:

Total ancillary revenue

it can see whether revenue increased or decreased.

But if the operator benchmarks:

  • Revenue per occupied unit
  • Revenue per move
  • Service penetration
  • Engagement
  • Conversion
  • Revenue by service
  • Revenue by move type

the operator can begin explaining the change.

For example:

Ancillary revenue increased 15%.

That sounds positive.

But perhaps move volume increased 25%.

In that case, revenue grew more slowly than the opportunity base.

Conversely:

Ancillary revenue increased 10% while move volume remained flat.

That may indicate improved monetization efficiency.

The second scenario could be strategically more interesting.

7. Property cohort benchmarking

Not every property should be compared against every other property.

A Class A urban high-rise should not necessarily be benchmarked directly against a suburban garden community.

Likewise, a newly launched property may not be comparable to a stabilized asset.

This is where property cohort benchmarking becomes important.

Create peer groups based on relevant characteristics.

Potential cohort variables include:

  • Property class
  • Unit count
  • Geographic market
  • Property age
  • Occupancy
  • Resident profile
  • Turnover
  • Move volume
  • Service availability
  • Operating model
  • Portfolio maturity

The objective is simple:

Compare properties against the properties they can reasonably be expected to resemble.

NAA’s benchmarking methodology provides a useful example of why comparison groups matter. Its historical benchmarking work emphasized relevant comparison groups, transparent methodology, consistent data, and apples-to-apples comparisons.

Don’t benchmark a stabilized property against a launch property

This is an easy mistake.

A newly launched property may have:

  • Lower resident volume
  • Different move patterns
  • Lower service adoption
  • Different staffing
  • Limited vendor coverage
  • Incomplete historical data

A stabilized property may have years of operating history.

Their performance should not necessarily be judged against the same benchmark.

Instead, create cohorts such as:

New properties: 0–12 months

Emerging properties: 12–24 months

Stabilized properties: 24+ months

The exact definitions should reflect the operator’s portfolio.

The important principle is comparability.

Internal benchmarks are often more useful than generic industry averages

This is particularly important for ancillary revenue.

There is no single universal number that tells every multifamily operator what ancillary revenue “should” be.

The right benchmark depends on:

  • Portfolio composition
  • Property class
  • Geography
  • Resident demographics
  • Move volume
  • Available services
  • Vendor economics
  • Operating model
  • Resident engagement

Industry benchmarking can provide context.

But internal data can reveal what is realistically achievable within your own operating environment.

NAA has previously highlighted the value of internal benchmarking when external data is difficult to compare because operators may use different definitions, accounting structures, and comparison groups.

That principle is especially relevant to ancillary revenue.

Build a three-level benchmarking model

A strong multifamily ancillary revenue benchmark can operate at three levels.

Level 1: Portfolio benchmark

Measure:

  • Total ancillary revenue
  • Revenue per occupied unit
  • Revenue per move
  • Overall conversion
  • Service penetration

This answers:

“How is the portfolio performing?”

Level 2: Cohort benchmark

Compare similar properties.

Measure:

  • Revenue per occupied unit
  • Revenue per move
  • Engagement
  • Conversion
  • Service mix
  • Move-event performance

This answers:

“Which property groups are outperforming their peers?”

Level 3: Property benchmark

Analyze individual properties.

Measure:

  • Move volume
  • Resident engagement
  • Service penetration
  • Conversion
  • Revenue per transaction
  • Revenue per move
  • Vendor performance

This answers:

“Where should the team take action?”

This three-level structure prevents executives from getting trapped between two extremes:

Too much detail → property-level noise.

Too little detail → portfolio averages that hide the problem.

Create an internal ancillary revenue benchmark

A practical benchmark can be built in six steps.

Step 1: Standardize the data

Define:

  • What counts as ancillary revenue
  • What counts as a resident engagement
  • What counts as a conversion
  • What counts as a move event
  • What counts as an eligible resident

Do this before comparing properties.

Step 2: Normalize revenue

Track at least:

Revenue per occupied unit

and

Revenue per move event

This gives you both a portfolio and lifecycle view.

Step 3: Add the conversion funnel

Track:

Eligible residents → Engagement → Conversion → Revenue

This identifies where performance changes.

Step 4: Create property cohorts

Group comparable properties.

Avoid one portfolio-wide benchmark that treats every asset as identical.

Step 5: Establish a baseline

Use historical internal performance.

For example:

Baseline: trailing 12-month performance

Target: improvement against baseline

Stretch: top-quartile internal performance

This is generally more actionable than selecting an arbitrary external number.

Step 6: Monitor variance

Once the benchmark exists, identify outliers.

For example:

Top quartile

Properties consistently exceeding the internal benchmark.

Middle 50%

Properties performing within the expected range.

Bottom quartile

Properties requiring investigation.

This creates a simple operating cadence for regional and asset-management teams.

What should a multifamily ancillary revenue dashboard include?

A useful dashboard doesn’t need dozens of metrics.

Start with a focused scorecard.

KPIPurpose
Total ancillary revenueMeasures overall financial contribution
Revenue per occupied unitNormalizes portfolio performance
Revenue per moveMeasures move-event economics
Service penetrationMeasures adoption
Engagement rateMeasures resident interaction
Conversion rateMeasures commercial effectiveness
Revenue by serviceShows service mix
Revenue by move typeShows lifecycle contribution
Revenue by propertyIdentifies property variance
Revenue by cohortEnables apples-to-apples comparison

The dashboard should then highlight:

Top performers

Bottom performers

Largest month-over-month changes

Largest cohort variance

Highest opportunity gaps

The role of benchmarking in RevGen optimization

Benchmarking is not the end of the RevGen strategy.

It is the diagnostic layer.

Suppose a property ranks in the bottom quartile for revenue per move.

That does not automatically tell you what to fix.

The operator needs to look deeper.

Scenario 1: Low engagement

Residents are not interacting with available services.

Potential areas to investigate:

  • Workflow placement
  • Communication
  • Timing
  • Resident experience
  • Service relevance

Scenario 2: High engagement, low conversion

Residents are interested but not completing transactions.

Potential areas to investigate:

  • Vendor selection
  • Pricing
  • Friction
  • Availability
  • Service experience

Scenario 3: High conversion, low revenue

The property is converting residents but generating relatively little revenue.

Potential areas to investigate:

  • Service mix
  • Transaction economics
  • Vendor revenue share
  • Product mix
  • Average transaction value

Scenario 4: High revenue but low penetration

A smaller group of residents generates strong revenue.

Potential opportunity:

Expand penetration without damaging resident experience.

Benchmarking tells you where to investigate.

It does not replace the investigation.

Don’t use benchmarking to create arbitrary targets

There is a temptation to create a single number:

“Every property should generate X dollars of ancillary revenue.”

That approach is risky.

A benchmark should represent a meaningful comparison—not an arbitrary quota.

For example, if Property A has twice the move volume of Property B, the same absolute revenue target doesn’t make sense.

Likewise, if Property A has a materially different resident profile or service mix, its expected performance may differ.

Instead, use ranges.

Example internal framework

Below benchmark: Bottom 25%

Expected range: Middle 50%

Leading performance: Top 25%

Then investigate the characteristics of properties in the top quartile.

What are they doing differently?

That question is usually more valuable than simply setting a higher target.

Benchmarking should also account for risk

Ancillary revenue cannot be evaluated only through financial output.

Insurance and compliance are part of the resident move lifecycle.

An operator may generate revenue while still leaving compliance gaps.

That creates an incomplete picture.

For this reason, a mature benchmark should include a risk layer alongside the revenue layer.

Track:

  • Insurance completion
  • Verification status
  • Outstanding compliance tasks
  • Documentation completion
  • Exceptions
  • Escalations

Moved’s platform supports centralized resident tasks and insurance documentation/verification as part of the move workflow.

This matters because the best-performing property isn’t necessarily the one that generates the most ancillary revenue.

It should also be operating within the required risk and compliance framework.

The operational layer matters, but it comes after revenue

The same principle applies to operational efficiency.

Operators can measure:

  • Staff time
  • Manual tasks
  • Outstanding tasks
  • Response times
  • Workflow completion

These metrics are valuable.

But they should support the broader financial objective.

Moved’s stated positioning places revenue generation first, risk mitigation second, and operational efficiency as a supporting layer.

That means the benchmarking framework should follow the same hierarchy:

Revenue

↓

Risk

↓

Operations

This keeps the analysis connected to asset-level financial outcomes.

How Moved can support portfolio-level benchmarking

Moved is designed as a move infrastructure platform that embeds revenue-generating services including movers, packing, storage, insurance, utilities, and connectivity into the resident onboarding workflow.

The platform also supports resident onboarding, offboarding, transfers, ancillary-service activation, resident data reporting, and PMS integrations.

That creates the foundation for measuring the resident move lifecycle as more than an administrative process.

For multifamily operators, Moved’s multifamily platform provides the operator-facing context for connecting resident move workflows with ancillary revenue opportunities.

For the resident-facing experience, Moved’s resident platform shows how the move process can bring required tasks and services into one experience.

This is particularly relevant when benchmarking move-related revenue because the operator can think about the complete lifecycle:

Move event

↓

Resident engagement

↓

Service activation

↓

Conversion

↓

Revenue

↓

Portfolio comparison

That is the difference between simply reporting ancillary revenue and building a RevGen benchmarking system.

Common ancillary revenue benchmarking mistakes

Mistake 1: Benchmarking total dollars

Large properties will naturally generate more revenue.

Better: Normalize revenue.

Mistake 2: Using one benchmark for every property

Different properties have different operating conditions.

Better: Build relevant cohorts.

Mistake 3: Measuring revenue without conversion

Revenue tells you the result, not the funnel.

Better: Track engagement and conversion alongside revenue.

Mistake 4: Ignoring move volume

Move-related services depend on resident lifecycle events.

Better: Track revenue per move.

Mistake 5: Benchmarking only against external data

External data can be useful, but definitions and comparison groups may differ.

Better: Build an internal benchmark first and use external data for context.

Mistake 6: Setting arbitrary revenue targets

A single number doesn’t account for property differences.

Better: Use performance ranges and peer cohorts.

Mistake 7: Ignoring service mix

Two properties can generate the same revenue through very different services.

Better: Benchmark revenue by category.

Mistake 8: Treating compliance as separate

Revenue growth should not come at the expense of risk controls.

Better: Include insurance and compliance metrics in the operating framework.

Frequently asked questions

What is ancillary revenue benchmarking in multifamily?

Ancillary revenue benchmarking is the process of comparing non-rent revenue performance across multifamily properties, cohorts, and portfolios using normalized metrics such as revenue per occupied unit, revenue per move event, service penetration, and conversion rate.

What is a good ancillary revenue benchmark for apartments?

There is no universal ancillary revenue number that applies to every apartment property. The appropriate benchmark depends on property characteristics, resident volume, move activity, available services, geography, and operating model. For that reason, operators should establish internal benchmarks using comparable properties and historical performance.

What is the best metric for benchmarking multifamily ancillary revenue?

There is no single best metric. Revenue per occupied unit is useful for portfolio normalization, while revenue per move event is particularly useful when revenue is generated around resident move-ins, move-outs, and transfers. Conversion and service penetration help explain the underlying performance.

How should multifamily operators compare ancillary revenue across properties?

Operators should compare properties using consistent definitions and relevant cohorts. Useful comparison factors include unit count, occupancy, property class, geography, turnover, move volume, service availability, and portfolio maturity.

Should ancillary revenue be measured per unit?

Yes, revenue per unit can be useful, but it should not be the only benchmark.

Revenue per occupied unit can provide a more relevant normalization when comparing active resident populations.

Why should operators benchmark revenue per move?

Move-related services are tied to resident lifecycle events.

Revenue per move helps determine how effectively a property converts each eligible move event into ancillary revenue, independent of overall property size.

How can operators identify their best-performing properties?

Rank properties using normalized metrics such as revenue per occupied unit, revenue per move, engagement, and conversion.

Then compare properties within relevant cohorts rather than ranking every property against the entire portfolio.

Should insurance be included in ancillary revenue benchmarking?

Insurance-related revenue can be included where applicable, but insurance should also be tracked separately as a compliance and risk-mitigation metric.

Revenue alone does not capture the full value of insurance verification.

How often should multifamily operators benchmark ancillary revenue?

Monthly monitoring is useful for identifying changes and outliers, while quarterly reviews can provide a stronger basis for strategic portfolio decisions.

Operators should also use trailing periods where appropriate to reduce noise from short-term fluctuations.

Final takeaway: Benchmark the opportunity, not just the revenue

Multifamily operators don’t need another dashboard showing a single ancillary revenue number.

They need a framework that explains why properties perform differently.

The strongest ancillary revenue benchmarking model connects:

  • Revenue per occupied unit
  • Revenue per move
  • Service penetration
  • Conversion
  • Service mix
  • Move-event performance
  • Property cohorts
  • Portfolio variance

That creates a much clearer picture of RevGen performance.

It also helps asset managers move from a passive question:

“How much ancillary revenue are we generating?”

to a more valuable one:

“How efficiently is each property converting its available resident and move-event opportunities into revenue?”

That is the benchmark that can drive action.

And for operators managing large portfolios, the objective should not be to find a single industry-wide number and force every property toward it.

The objective is to build a consistent, internally defensible, continuously improving benchmark that accounts for the realities of each property while still giving leadership a clear portfolio-wide view.

Moved approaches the resident move as revenue-generating infrastructure, embedding services such as moving, packing, storage, insurance, utilities, and connectivity into the resident onboarding workflow while supporting risk mitigation and operational consistency.

Operators looking to evaluate their resident move infrastructure can connect with the Moved team.

For additional context, see Moved’s existing resources on the move-in and move-out revenue opportunity and   resident onboarding automation. These should be treated as supporting resources rather than substitutes for the benchmarking framework outlined above.

How to forecast non-rent revenue in multifamily: a practical model for operators

Posted on by Daria/SEO

Ask most multifamily finance teams how they arrive at next year’s rent number, and the answer involves lease expiration curves, renewal conversion assumptions, and concession burn-off modeled by unit group. Ask the same team how they arrive at next year’s ancillary revenue number, and the answer is often a flat percentage applied to the rent line, carried forward from last year with a small adjustment.

That gap is not a data problem so much as a treatment problem. Non-rent revenue gets budgeted like a bonus rather than modeled like a P&L line with its own drivers. This article lays out what a more rigorous forecast requires: which inputs matter, how to build the assumptions, and where the model needs to work differently at the property level than at the portfolio level.

Why ancillary revenue is difficult to forecast

Rent forecasting benefits from decades of shared methodology. Ancillary revenue forecasting does not have the same infrastructure behind it, which is part of why it gets treated as an afterthought.

The Revenue Method’s guide to multifamily forecast accuracy makes the underlying point directly: base rent alone does not tell the full revenue story, because ancillary income, amenity premiums, parking, storage, and fees can create <cite index=”87-1″>meaningful variance between projected and actual performance</cite>. That variance is not random. It comes from treating a revenue stream with its own volume, conversion, and pricing dynamics as if it moves in lockstep with rent.

It does not move in lockstep with rent, and the reasons are structural. Rent forecasting has a small number of well-understood drivers: units, lease terms, renewal rates, market rent growth. Ancillary revenue is driven by move volume, service adoption, and vendor pricing, three variables that behave differently from each other and from rent. A portfolio can hold rent growth flat while move volume climbs, or vice versa, and a forecast that treats non-rent revenue as a fixed percentage of rent will miss both directions.

There is also a discipline gap that is worth naming plainly. Freddie Mac’s 2025 Multifamily Outlook observed that when rent growth and occupancy trade off against each other, <cite index=”104-1″>operators have typically chosen the inverse, maintaining occupancy levels with less rent growth</cite>. That is a deliberate, modeled tradeoff, made because rent forecasting infrastructure exists to support it. Non-rent revenue rarely gets the same deliberate tradeoff analysis, not because it matters less, but because the modeling infrastructure to support that analysis usually is not there.

Historical vs event-based forecasting

Two different forecasting logics are available for ancillary revenue, and most operators default to only one of them.

Historical forecasting extends last year’s ancillary revenue forward, adjusted for a growth rate. It is simple to build and easy to explain, and it is also the method most exposed to the variance problem described above, because it assumes the relationship between revenue and its underlying drivers stayed constant. If move volume shifts, historical forecasting will not see it coming until the actuals already show the miss.

Event-based forecasting starts somewhere else: from the calendar of move-in and move-out events the portfolio actually expects, and builds ancillary revenue up from there. This is closer to how rent forecasting already works. Rentana’s guidance on budget-season revenue forecasting makes the same point about rent: a forecast built only on historical averages can understate risk, while mapping actual lease expiration timing into the model produces a materially more accurate quarterly pattern than smoothing vacancy into one annual percentage. The same logic applies directly to ancillary revenue. A portfolio with a large share of move-outs concentrated in a single quarter, for reasons tied to lease expiration timing that the rent forecast already accounts for, should expect ancillary revenue to follow that same concentration rather than a smooth monthly average.

The strongest forecasts combine both. Historical performance sets the baseline conversion and adoption rates; the event calendar determines when and how much volume those rates get applied to. Neither logic alone is sufficient, in the same way that neither is sufficient for rent.

Volume, conversion, and revenue-per-transaction inputs

A useful way to structure the ancillary revenue forecast is to borrow the three-input structure that sales and revenue operations teams have used for years to forecast pipeline: volume, conversion, and value per transaction.

The pipeline velocity formula used in B2B revenue forecasting multiplies the number of opportunities by the win rate and the average deal size, then divides by the length of the sales cycle, to <cite index=”91-1″>provide a real-time, data-driven revenue forecast</cite>. The specific formula belongs to a different industry, but the three-input structure underneath it, volume, conversion, and value, maps cleanly onto ancillary revenue.

Volume is the number of eligible move events, move-ins and move-outs, expected during the forecast period. This comes directly from the lease expiration schedule and renewal assumptions already built into the rent forecast, which is one reason ancillary revenue forecasting should sit next to rent forecasting rather than in a separate spreadsheet.

Conversion is the share of eligible residents who transact in a given service category, movers, packing, storage, insurance, or connectivity. Conversion should be tracked separately by category, because a resident who books a mover behaves differently from one who adds insurance verification, and blending the two into a single conversion rate obscures which category is actually driving or dragging performance.

Revenue per transaction is the average value of a completed transaction in each category. This is the input most exposed to vendor pricing changes and should be reviewed on a cadence independent of the broader forecast, since a pricing change from a single vendor can move this number without any change in resident behavior at all.

Multiplying these three inputs by category, then summing across categories, produces a forecast built from the same drivers that actually determine the result, rather than a single blended growth rate applied to last year’s total.

Property-level forecasting

A portfolio-level ancillary revenue forecast built from portfolio-level averages will systematically hide the properties that need attention most.

The logic here parallels a point made in utility budget forecasting, a different non-rent revenue category with its own volatility. Billee’s analysis of multifamily utility forecasting describes how portfolio-level data enables <cite index=”76-1″>cross-property benchmarking, identifying which properties are running above or below comparable properties</cite>, along with variance checks that flag properties whose growth rate deviates from the portfolio average. Ancillary revenue forecasting needs the same cross-property discipline. A portfolio average adoption rate of 30 percent could mean every property is converting at 30 percent, or it could mean half the portfolio is converting at 45 percent while the other half is converting at 15 percent. Those are very different operational stories, and only property-level forecasting distinguishes between them.

Property-level forecasting requires the volume, conversion, and revenue-per-transaction inputs described above to be tracked at the property level, not just the portfolio level. A property with an unusually high concentration of move-outs in a single month should show that in its forecast; a property with historically strong mover adoption but weak insurance adoption should carry different category-level conversion assumptions than a property with the opposite pattern. Rolling these differences up into a single portfolio number before the forecast is built erases the information a revenue leader would actually use to act.

Portfolio aggregation

Once property-level forecasts exist, aggregating them into a portfolio number is largely mechanical, but two decisions determine whether the aggregate is useful.

The first is whether the aggregation preserves category-level detail or collapses it. A portfolio forecast that reports a single ancillary revenue number tells a CFO less than one that reports movers, packing, storage, insurance, and connectivity separately, summed across properties. The category breakdown is what makes the forecast actionable, because different categories respond to different levers, pricing, vendor selection, resident communication timing, and a blended total obscures which lever to pull.

The second is scale. The NAA, IREM, and BOMA 2024 Income/Expense IQ benchmarking report covered financial data for <cite index=”21-1″>over 1 million multifamily units across more than 4,600 properties in 109 metropolitan markets</cite>, illustrating the range of property sizes and market conditions a single portfolio-level forecast is often asked to represent. A portfolio spanning that kind of range in submarket conditions, asset age, and resident demographics should not expect a single conversion rate or a single revenue-per-transaction figure to hold across every property. Aggregation should sum property-level forecasts built from property-level assumptions, not apply one assumption set across a portfolio and call the result an aggregate.

Forecast variance analysis

A forecast that is never checked against actuals is a projection, not a forecast. Rentana’s guidance on revenue forecasting is direct on this point: a single-point estimate can imply more certainty than the underlying assumptions support, which is why the strongest practice is to build a base case alongside upside and downside scenarios rather than anchoring to one number.

For ancillary revenue, variance analysis should run at the same three-input level used to build the forecast. If actual revenue misses the forecast, the first question is not whether the total was wrong, but which input was wrong: did fewer move events occur than expected, did conversion in a specific category come in below assumption, or did revenue per transaction shift because of a vendor pricing change. Each of those misses points to a different fix. A volume miss is a leasing and retention issue. A conversion miss is an adoption and resident-communication issue. A revenue-per-transaction miss is a vendor and pricing issue.

This is also where property-level detail earns its keep. A portfolio-level miss that looks modest in aggregate can be masking a large miss at a handful of properties offset by overperformance elsewhere. Reviewing variance at the property level, by category, on the same cadence used for rent variance review, is what turns a forecast into a management tool rather than a once-a-year budgeting exercise.

CFO dashboard

A CFO does not need every input in the model surfaced on a dashboard. Four numbers, reviewed on a consistent cadence, give a complete picture without requiring a finance team to rebuild the underlying model every time someone asks a question.

Forecast vs actual, by category. Movers, packing, storage, insurance, and connectivity, shown separately, not blended into a single ancillary revenue line. This is the single fastest way to see which category is driving a portfolio-level miss.

Variance by input. For any category showing meaningful variance, a breakdown of whether the miss came from volume, conversion, or revenue per transaction. This turns a variance number into a diagnosis rather than just a flag.

Property-level range. The spread between the highest- and lowest-performing properties on forecast accuracy, not just the portfolio average. A wide range signals that property-level assumptions need review even when the portfolio total looks close to plan.

Scenario bands. Base, upside, and downside cases for the current forecast period, so the dashboard shows a range rather than a single point estimate that implies more certainty than the assumptions support.

None of these require new source systems. They require the volume, conversion, and revenue-per-transaction inputs described above to already be tracked by category and by property, which is the same underlying requirement that makes the forecast itself possible.

Frequently asked questions

Can ancillary revenue really be forecast with the same rigor as rent?

Not with identical inputs, since ancillary revenue is driven by move volume, service adoption, and vendor pricing rather than lease terms and market rent growth. But the same discipline applies: build the forecast from its actual drivers rather than a flat percentage of rent, and review variance by input rather than only by total.

What is the biggest mistake operators make in ancillary revenue forecasting?

Treating it as a fixed percentage of the rent line rather than a revenue stream with its own volume, conversion, and pricing inputs. That approach hides which lever actually moved when the forecast misses, and it means the forecast has no mechanism for catching a shift in move volume or vendor pricing until the actuals already show the damage.

Should ancillary revenue be forecast at the property level or the portfolio level?

Both, but the property level comes first. A portfolio forecast built by aggregating property-level forecasts, each with its own volume, conversion, and revenue-per-transaction assumptions, preserves the operational detail that a single portfolio-wide assumption set erases.

How often should the forecast be reviewed against actuals?

On the same cadence used for rent variance review, tied to the same lease expiration and budget milestones. Ancillary revenue variance that goes unreviewed for a full budget cycle means a full year of misallocated attention before anyone catches which input actually moved.

Closing

Rent gets forecast with lease-level precision because the infrastructure to do that has existed for decades. Non-rent revenue can get the same treatment, but only if it is modeled from its actual drivers, move volume, service adoption by category, and revenue per transaction, rather than carried forward as a flat percentage of rent. Property-level forecasting, honest portfolio aggregation, and variance analysis that points to a specific input rather than a vague miss are what turn ancillary revenue from a budgeting afterthought into a forecastable P&L line.

If you manage 10,000 units or more and want to see what a category-level, property-level ancillary revenue forecast would look like for your portfolio, reach out to our team.

Related reading: how the move-in and move-out workflow produces revenue for property managers, and the complete guide to resident onboarding automation. See also Moved for multifamily operators and the resident experience.

The attribution gap: why multifamily operators can’t prove which resident touchpoints generate revenue

Posted on by Daria/SEO

Ask a revenue leader how much ancillary income a portfolio generated last quarter, and the answer arrives quickly. Ask which resident touchpoints produced that income, whether it was the move-in checklist, a renewal offer, or a maintenance visit, and the answer usually does not arrive at all.

That gap matters more than it looks. Other income is not a mystery in most portfolios; it shows up on the operating statement every month. What is missing is the connective tissue between a dollar of that revenue and the specific resident interaction, channel, or property system that generated it. Without that connection, revenue leaders cannot tell which programs to expand, which properties are underperforming, or which vendor relationships are actually working.

This article is about that connective tissue: why it is missing, what it would take to build it, and which KPIs are worth tracking once it exists.

Why revenue attribution breaks in multifamily

The property management system was not built to answer this question, and it was never supposed to be.

Funnel Leasing describes the major PMS platforms, Yardi, RealPage, and Entrata, as the operational backbone of multifamily, noting that they function as “systems of record, ensuring data integrity for mission-critical functions like rent collection and financial reporting.” That framing is accurate and also the source of the problem. A system of record for rent collection has no native reason to track which resident touchpoint led to a storage rental or an insurance signup, because that was never its job.

Writing for Thesis Driven, Propexo co-founder Remen Okoruwa put the underlying issue directly: the PMS, maintenance platform, and CRM each know their own slice of the resident relationship, but “none of them know about the resident as a whole person whose history spans all three.” Revenue attribution requires exactly that whole-person view, and it is precisely what the current generation of point solutions was not designed to provide.

The consequence shows up first in marketing and leasing, before it ever reaches ancillary revenue. Okoruwa’s account of a former Bozzuto marketing leader is instructive: a renter who clicked an ad, toured the property, and applied the following week showed up as three separate leads across three separate tools, and the operator had “almost no visibility into which channels were actually driving signed leases.” Ancillary revenue attribution is the same structural problem one step further down the resident lifecycle. If a lead cannot be tracked consistently across three systems before signing a lease, a service transaction is even less likely to be tracked consistently across the systems that touch a move.

PMS data vs service transaction data

Two different kinds of data sit inside a multifamily operator’s stack, and they were built with two different purposes in mind.

PMS data describes the lease. Move-in and move-out dates, unit assignments, rent ledgers, and renewal status all live in Yardi, RealPage, or Entrata, structured around the unit and the lease term. Service transaction data describes something else: which resident purchased a mover, packing service, storage unit, insurance verification, or connectivity plan, and when. That data is often generated by a separate vendor, on a separate schedule, with no shared identifier connecting it back to the lease record.

The result is what a SurfaceAI analysis of multifamily technology stacks called a fragmented environment where information “trapped in separate tools, the PMS, spreadsheets, cloud storage, email threads, creates blind spots.” The same analysis pointed to a cross-industry benchmark worth noting here: 68% of organizations cite data silos as their top data management concern. Multifamily is not an outlier on this point. It is a straightforward case of an industry where the core operating system was designed for accounting, not for tracing revenue across vendor boundaries.

Okoruwa’s reporting on the current state of PMS openness reinforces the scale of the gap. Even as major platforms have opened up their APIs, a recent industry survey found that “no platform scored above 6.5 out of a 10-point scale, and the lowest averaged just over 3” on openness, and the editorial verdict was that none of the recent improvements had meaningfully changed how the industry experiences these platforms day to day. Getting data out of a system is not the same as being able to connect it to a resident record elsewhere in the stack.

For an operator managing 10,000 units or more across a mixed Yardi, RealPage, and Entrata estate, this means service transaction data and PMS data typically exist in parallel, reconciled manually if they are reconciled at all.

Mapping resident touchpoints to revenue

A useful way to think about this problem is to borrow, carefully, from how marketing measurement handles a similar challenge.

Marketers have spent two decades building attribution models because a customer rarely converts on a single interaction. Adobe’s overview of the practice describes the two simplest approaches: a first-touch model that “prioritizes the first touchpoint in the customer journey,” and a last-touch model that credits whichever interaction happened right before conversion. Both are easy to build and both are incomplete, which is why more sophisticated multi-touch models exist to distribute credit for a conversion “across every touchpoint in the customer journey, rather than handing all of it to a single click.”

The resident lifecycle has its own version of this same journey. A resident encounters a mover recommendation during the move-in checklist, a packing offer during a reminder email, a storage upsell during a maintenance visit, and an insurance verification requirement at lease signing. Each of those is a touchpoint. Revenue that lands in other income was generated by one or more of them, and right now, most operators can only see the total, not the path.

Mapping touchpoints to revenue does not require the full sophistication of a multi-channel marketing attribution model. It requires something more basic first: a consistent identifier that ties a resident to a unit, a move event, and every service transaction associated with that move, regardless of which vendor processed it. Without that identifier, no attribution model, however sophisticated, has anything to work from.

Attribution by property, service, and move event

Once a consistent identifier exists, attribution can be organized along three axes that map to how revenue leaders actually make decisions.

By property. Which communities are converting move events into ancillary revenue at a meaningfully higher rate than the portfolio average, and which are lagging? Property-level attribution surfaces execution differences that a portfolio-wide number hides entirely. A regional average can look healthy while individual properties are leaving revenue on the table.

By service category. Movers, packing, and storage behave differently from insurance and from connectivity, both in adoption pattern and in how the offer reaches the resident. A single blended attribution number obscures which category is actually driving performance and which is riding on the others.

By move event. Move-in and move-out are not the same commercial moment. A move-in is an onboarding sequence with multiple scheduled touchpoints; a move-out is a shorter, more compressed window with less runway to convert a resident into a service transaction. Attribution that does not separate the two will consistently overweight whichever event happens to generate more transaction volume, without explaining why.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow, which is what makes property-level, service-level, and move-event-level attribution possible in the first place, because the transaction and the resident record originate in the same system rather than being reconciled after the fact.

 

KPIs executives should track

Four metrics give a revenue leader a working view of attribution without requiring a full marketing-grade measurement stack.

Attribution coverage rate. The share of total other income that can be traced to a specific resident, property, and service category, as opposed to sitting in an undifferentiated other income line. This is the single number that tells a revenue leader how much of the portfolio’s ancillary revenue is actually explainable.

Revenue per move event. Ancillary revenue divided by completed move-ins and move-outs over a period, tracked separately for each event type. This normalizes for occupancy and turnover volume, so a property is not penalized or credited simply for having more or fewer moves in a given month.

Service category adoption rate. The percentage of eligible residents who transact in each category, movers, packing, storage, insurance, and connectivity, tracked at the property level. Adoption rate differences between properties running the same program are usually the clearest signal of an execution gap rather than a demand gap.

Property-level variance. The spread between the highest- and lowest-performing properties on attribution coverage and adoption rate. A wide variance across otherwise comparable properties is usually the fastest way to find where a program is breaking down operationally, before it shows up as a portfolio-wide number that looks merely average.

None of these metrics require inventing new infrastructure. They require the underlying transaction data to already carry a property, service category, and move-event identifier, which is the same requirement that underpins property-level attribution in the first place.

Building an attribution framework

A working attribution framework rests on four requirements, in order.

First, a shared identifier. Every service transaction needs to resolve to the same resident and unit record that the PMS uses, not a separate identifier maintained by whichever vendor processed the transaction. This is the single highest-leverage change, because every other requirement depends on it.

Second, category-level coding. Revenue needs to be tagged by service category at the point of transaction, not reconstructed later from vendor invoices. Movers, packing, storage, insurance, and connectivity should each be a distinct, queryable field, not a line item buried inside a combined other income total.

Third, move-event tagging. Every transaction should be associated with a specific move-in or move-out event, not just a date range. This is what makes it possible to calculate revenue per move event and to separate the two commercial moments described above.

Fourth, a system of record that is actually queried, not just reported. A dashboard that a regional manager checks quarterly is not the same as a data layer that a revenue leader can query on demand. Okoruwa’s reporting on operators who have solved this problem points to the same underlying shift: firms that treat their data as infrastructure they own, rather than a report their vendor produces for them, are the ones who can answer attribution questions on demand instead of assembling them from scratch each time a board asks.

These four requirements do not require replacing the PMS. They require a layer that sits alongside it, purpose-built to originate resident-linked, category-coded, move-event-tagged transaction data rather than reconstructing it after the fact.

Frequently asked questions

Why can’t we just pull this from our PMS reports?

Because the PMS was built to track leases and rent collection, not service transactions from third-party vendors. Funnel Leasing’s description of Yardi, RealPage, and Entrata as systems built for accounting and lease administration explains why: revenue attribution requires a resident-level view spanning multiple systems, which is not what those platforms were designed to produce.

Is this the same problem as lead attribution in marketing?

It is a related version of the same structural problem. The Bozzuto example above shows a prospect fragmenting into multiple leads across systems before ever signing a lease. Ancillary revenue attribution is the continuation of that fragmentation further down the resident lifecycle, after the lease is signed and the move begins.

How many properties need this before it is worth building?

Attribution coverage rate and property-level variance both become more useful as the number of comparable properties grows, since the whole point is to compare performance across communities. Portfolios of 10,000 units or more are large enough that even a modest gap between well-attributed and poorly-attributed properties represents a material amount of unexplained revenue.

What is the single highest-value change to make first?

Establish a shared identifier linking every service transaction to the same resident and unit record used by the PMS. Every other part of the framework, category coding, move-event tagging, and the KPIs built on top of them, depends on that identifier existing first.

Closing

Ancillary revenue is not hard to see. It shows up in other income every month. What is hard is tracing any single dollar of it back to the resident touchpoint, property, or move event that produced it, because the systems that generate that revenue were never built to talk to each other. Closing that gap does not require a new PMS. It requires a shared identifier, category-level coding, move-event tagging, and a small set of KPIs built on top of them.

If you manage 10,000 units or more and want to see what property-level and service-level revenue attribution would look like for your portfolio, reach out to our team.

Related reading: how the move-in and move-out workflow produces revenue for property managers, and the complete guide to resident onboarding automation. See also Moved for multifamily operators and the resident experience.

What non-rent revenue does to your exit cap

Posted on by Daria/SEO

Ancillary revenue conversations in multifamily usually stop at the operating statement. The program produces income, the income lands in other income, other income rolls into net operating income, and the discussion moves on.

The part that gets skipped is the one that matters most to an owner. At disposition, an underwriter decides how much of that other income is real. Some of it is accepted into the underwritten figure. Some of it is discarded. The tests are published, they are specific, and most operators have never read them.

This article is about those tests. It does not estimate what any portfolio’s non-rent revenue is worth, because that number depends on your own audited figures and your own market. What it does is explain what determines whether the number counts at all.

Why this question got more important

The rent side has been doing very little of the work.

Yardi Matrix reported that the average United States advertised rent “rose $4 to $1,771” in its most recent monthly release, describing “a 1.3% year-to-date increase in advertised rates over the past five months” and “year-over-year rent growth remaining weak amid a record number of apartment deliveries.” RealPage Analytics characterized the longer arc as “rent growth running below 1% year-over-year for nearly 30 months,” alongside average concessions reaching “the equivalent of 36 days of free rent.”

The expense side has not been as accommodating. The National Apartment Association reported that “average annual rent reached $21,502 per unit in 2024, rising just 1.2% from 2023, following growth of 2.9% in 2023 and 11.4% in 2022,” and that “since 2021, repairs and maintenance costs have risen nearly 28%, while Net Operating Income (NOI) has increased just 10% during the same period.”

When rent growth is flat and expenses are not, the composition of net operating income becomes a live question rather than an accounting detail.

How value is actually set

The mechanism is simple and worth stating precisely, because the precision is where the operational requirements come from.

CBRE defines it directly in its cap rate survey work: “stabilized cap rates are the ratio of stabilized net operating income (NOI) to the acquisition price of the asset.” The Freddie Mac Multifamily Seller/Servicer Guide sets out the same approach in its valuation chapter, noting that “the Property’s value can be developed with either a multiplier analysis or direct capitalization analysis,” and that the “capitalization Rate must be based on factors reflecting the investment characteristics of knowledgeable investors for properties similar to the Property.”

So value follows underwritten net operating income. Which means the operational question is narrow and answerable: how much of your non-rent revenue survives into the underwritten figure.

On where cap rates currently sit, CBRE reported core multifamily going-in cap rates at 4.75% and exit cap rates at 4.95% in its Q4 2025 survey, with value-add going-in at 5.26% and value-add exit at 5.38%. Note that the exit cap is published separately from the going-in cap, which is the whole point of this discussion. The exit assumption is where a buyer’s view of durable income shows up.

What the agencies actually require

Both agencies publish their treatment of other income, and the language is unusually clear.

The Freddie Mac Multifamily Seller/Servicer Guide, at Section 60.17(e), states that “the appraiser may include income from sources other than residential units when calculating total gross income if such income is supported by at least three years’ historical operations, is common in the market and is expected to continue in the future.” The Guide lists examples including “commercial space, laundry, parking, cable television, vending and application fees.”

The Fannie Mae Multifamily Selling and Servicing Guide, at Section 203.01, applies comparable tests to underwritten net cash flow. Other income must “be stable” and “be supported by prior years,” and the underwriter must “exclude one-time extraordinary non-recurring items.” The Guide requires an assessment of “the individual month’s other income within the prior full-year operating statement or, at a minimum, an operating statement covering at least the trailing 6 months (annualized),” and constrains how fluctuating income can be used: “if there are fluctuations, you may use other income that exceeds the trailing 3-month other income (annualized), provided it does not exceed the highest 1-month other income used in the trailing 3-month other income calculation.”

Read together, four tests emerge. The income has to recur. It has to be documented across periods. It has to be normal for the market. And anything one-time gets stripped out.

Translating the tests into operations

Those four tests are underwriting language. Each has an operational equivalent that an operations team can act on.

Recurrence means the revenue has to be produced by a process rather than by an effort. If the income exists because a particular regional manager runs a good program, it will show gaps the moment that person changes roles, and gaps show up as fluctuation in exactly the trailing-period tests the agencies apply.

Documentation means the transactions have to live in a system of record, attributable to a property and a period. Revenue reconstructed from vendor statements at diligence is revenue an underwriter will discount, because it cannot be tied to the property’s own books cleanly.

Market normalcy means the services should be ones a buyer recognizes. Movers, packing, storage, insurance, utilities and connectivity are services residents in residential real estate buy during every move. Their presence in other income reads as ordinary rather than as an aggressive assumption.

Excluding one-time items means promotional pushes and one-off campaigns should be understood for what they are. They may be good business. They will not carry into an underwritten figure, and treating them as if they will produces a valuation conversation that goes badly.

Where most programs fail

Four patterns account for most of the gap between reported non-rent revenue and underwritten non-rent revenue.

The revenue sits in a single undifferentiated other income line. When a buyer asks what is inside it, the answer takes weeks to assemble and arrives incomplete. A category nobody can decompose is a category a buyer discounts.

The program varies across the portfolio. Different offer sets by region produce a consolidated number that fluctuates for reasons unrelated to demand, and fluctuation is precisely what the agency trailing-period tests penalize.

Attribution is missing. Vendor-side reporting shows totals. Property-level, period-level attribution is what an underwriter needs, and it has to come from the operator’s own records.

And the revenue depends on human memory at the point of the move. Any process that requires a leasing associate to remember an offer during a busy move-in and move-out period will produce inconsistent results, which reads as instability in the numbers regardless of the underlying demand.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow.

The reporting standard worth holding

An operator who wants non-rent revenue to count at disposition should be able to produce, on request, four things.

A breakdown of other income by service category rather than a single line. Monthly figures across a multi-year history, matching the periods the agencies test. Property-level attribution for every dollar. And a written description of the process that generates the revenue, showing it does not depend on any individual.

That package is what turns a program into an underwritable income stream. Without it, the revenue is real in the operating statement and absent from the valuation.

Frequently asked questions

Does other income really affect valuation, or does the buyer just look at rent?

Both agencies explicitly permit other income in the underwritten figure when it meets their tests, and CBRE’s definition ties value directly to net operating income. The constraint is on quality of evidence rather than on the category itself.

How many years of history do we need?

Freddie Mac’s appraisal guidance references “at least three years’ historical operations” for other income sources. Fannie Mae’s underwriting tests work off the prior full year or, at minimum, a trailing 6-month operating statement annualized, with additional constraints on fluctuating income. Building the record early is the practical takeaway.

We are not selling for years. Does this matter now?

The history requirement is the reason it matters now. A three-year record cannot be created retroactively at the point of sale. The operators who benefit are the ones who instrumented the revenue several years before anyone opened a data room.

What is the single highest-value change to make first?

Move the revenue into a system of record with property-level and category-level attribution. Every other test becomes answerable once the data exists, and none of them are answerable until it does.

Closing

Non-rent revenue reaches valuation through net operating income, and only the portion an underwriter accepts makes the trip. The tests are published by both agencies and they reward the same things: recurrence, documentation, market normalcy, and the absence of one-time items. Those are operational properties. They are built into how the revenue is generated and recorded, years before the exit cap is ever negotiated.

If you manage 10,000 units or more and want to review whether your non-rent revenue would survive an underwriter’s tests, reach out to our team.

Related reading: how the move-in and move-out workflow produces revenue for property managers, and the complete guide to resident onboarding automation. See also Moved for multifamily operators and the resident experience.

Why free move-in platforms are not free

Posted on by Daria/SEO

Every operator evaluating move-in technology eventually meets a product that costs nothing. No licence fee, no per-unit charge, no implementation invoice. For an operations team under budget pressure, that is a compelling opening.

It is also incomplete. Software has a cost structure whether or not the operator sees an invoice. In a model where the operator pays nothing, the revenue is coming from the resident, either through what the resident buys or through access to the resident. That is a legitimate way to build a business. It is also a set of decisions the operator is making on the resident’s behalf, usually without examining them.

Three questions surface what is actually being agreed to.

Question one: who is paying, and for what

Ask the vendor to describe the full revenue model in plain language. Which counterparties pay them, for what, and on what basis.

There is a real distinction between two models that can look identical in a demo. In the first, the vendor earns from services the resident genuinely needs and would otherwise buy elsewhere. Movers, packing, storage, and insurance fall into this category. The resident wanted the service, the vendor delivered it, and the economics follow the delivery.

In the second, the vendor earns from access to the resident. The product is the resident’s attention or the resident’s data, sold to third parties who want to reach a household at a moment of high purchasing intent. The move-in workflow becomes a distribution channel.

Both models can be run well. They carry different risks for the operator, and only one of them keeps the operator’s interests and the resident’s interests pointing the same direction.

The FCC has already ruled on one version of this

This is not an abstract concern. Regulators examined a specific form of it in residential real estate and prohibited it.

In its 2022 order on competitive broadband access to multiple tenant environments, the Federal Communications Commission stated: “We prohibit a provider from entering into or enforcing an exclusive revenue sharing agreement with an MTE owner.” The Commission found such agreements “anti-competitive” and said they “amount to de facto exclusive access agreements.”

The order went further and addressed graduated arrangements as well: “We also prohibit providers from entering into or enforcing graduated revenue sharing agreements with MTE owners.” Under those arrangements, “a provider pays an MTE owner a greater percentage of revenue as its penetration in the building increases,” which the Commission found “discourage competitive entry to MTEs.”

The reasoning is worth holding onto beyond broadband. When a vendor’s payment to the owner rises with how many residents the vendor captures, the owner acquires a financial interest in limiting the resident’s alternatives. That structure attracts regulatory attention wherever it appears.

Question two: what happens to the resident’s data

A move-in platform sees a household at its most exposed. Names, forwarding addresses, move dates, service selections, sometimes payment details and identity documents. Ask three specific things.

Who owns that data contractually. Where it can be sent. And what happens to it when the agreement ends.

The regulatory floor here is not theoretical for large operators. Under the California Consumer Privacy Act, as the California Apartment Association set out for its members, a business is covered if it has “gross annual revenues in excess of $25 million,” or “buys, receives, or sells the personal information of 50,000 or more consumers, households, or devices,” or “derives 50 percent or more of annual revenues from selling consumers’ personal information.” Residents covered by the law have the right to “opt-out of sale of personal information,” and a right “to non-discrimination in terms of price or service when a consumer exercises a privacy right under CCPA.”

The National Multifamily Housing Council flagged the same territory for the industry, publishing guidance that “identifies 14 specific steps firms should take to prepare for existing and forthcoming legislation” and advising that firms “can prepare by proactively accounting for data privacy and security considerations in business operations.”

Most operators sign move-in vendor agreements without answering the three questions above. The exposure sits with the operator regardless, because the resident handed over the information believing they were dealing with their apartment community.

Question three: whose name is on it when something goes wrong

A mover damages furniture. A service the resident selected inside your portal never shows up. An insurance policy the resident believed was in place turns out not to be.

The resident does not call the vendor. They call the leasing office, because the offer appeared inside your workflow, under your brand, at your community. Whatever the contract says about liability, the reputational cost lands on the operator.

This is where free becomes expensive in a way that never appears in the software budget. The operator has outsourced the resident experience to a party whose commercial incentive is transaction volume, while retaining the reputational consequences of how those transactions go.

Resident-facing surveys suggest operators already misjudge what residents notice. Reporting Zego’s 2025 Resident Experience Management Report, NAA found that “apartment operators ranked a technology-enabled lifestyle as being the most important to renters. Renters disagree and rank this as a much lower priority.” The same research found that according to renters, the top three reasons they are not going to renew are “rent is too expensive; poor maintenance response; security issues,” and concluded that “many properties are losing good residents for preventable reasons.”

The gap between what operators believe residents value and what residents report valuing is the gap a poorly governed vendor relationship widens.

The regulatory floor is rising

Disclosure standards in rental housing are tightening, which raises the cost of an unexamined arrangement.

In March 2026 the Federal Trade Commission opened an advance notice of proposed rulemaking on rental housing fee practices. Christopher Mufarrige, Director of the FTC’s Bureau of Consumer Protection, stated that “rental pricing practices that are neither clear nor transparent undermine competition and harm consumers.” The Commission noted that “the failure to advertise the true total rent limits consumers’ ability to make informed financial decisions, increasing their search costs.”

Enforcement preceded the rulemaking. The FTC noted that Invitation Homes agreed to pay $48 million over allegedly “excluding mandatory monthly fees from the advertised rent,” and that Greystar Real Estate Partners was ordered to pay $23 million for allegedly having “misrepresented the true cost of renting a property and excluded mandatory fees from the advertised rent.”

None of that speaks directly to move-in platforms. It establishes the direction of travel. An operator who can explain exactly what every party earns, and can show that residents were told plainly, is in a materially better position than one who cannot.

What a defensible arrangement looks like

A few characteristics distinguish a vendor relationship an operator can stand behind.

The revenue model is disclosed in full and the operator can restate it from memory. If explaining how the vendor makes money requires the vendor in the room, the operator does not understand what they have signed.

The monetized services are services the resident actually needs. Movers, packing, storage, and insurance are purchases the household is making regardless. Insurance in particular belongs in the workflow as financial risk mitigation, verified before keys change hands rather than chased afterwards.

Resident choice is real. The resident can decline any service and still complete their move-in and move-out without friction or penalty.

Data ownership sits with the operator, with defined limits on where information travels and a clear deletion path at termination.

Commercial terms are structured rather than hidden. Flexible commercial structures are normal in this category and there is nothing wrong with them, provided the operator can see the whole picture and it does not create an incentive to narrow the resident’s options.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow.

Frequently asked questions

Is there anything wrong with a vendor earning from resident services?

No. Residents buy movers, packing, storage, and insurance during every move. A vendor earning by delivering those services well is aligned with both the operator and the resident. The concern is a model where the earnings come from access to the resident rather than from service delivery, because that decouples the vendor’s incentive from the resident’s outcome.

How do we evaluate this without a procurement team?

Three documents answer most of it: the full revenue model in writing, the data processing terms, and the service level commitments with named remedies. If a vendor will not put the revenue model in writing, that is the finding.

Does paying for software actually change the incentive?

It changes who the vendor answers to. When the operator is the paying customer, the operator sets the service standard and can enforce it. That is the practical difference, and it is why the question of who pays is worth asking before the demo rather than after.

We are mid-contract. What can we do now?

Ask for the revenue model in writing and review your data terms at the next renewal window. Most agreements have a notice period that makes this a planning question rather than an emergency.

Closing

Free software is a pricing decision the vendor made, and it tells you where their revenue comes from. For an operator managing 10,000 units or more, the real test is whether the arrangement keeps the operator, the vendor, and the resident pointed in the same direction, and whether the operator can explain it plainly if a regulator, an owner, or a resident asks.

If you want a structured review of what your current move-in vendor arrangement actually commits you to, reach out to our team.

Related reading: how the move-in and move-out process generates revenue for property managers, and the complete guide to resident onboarding automation. See also Moved for multifamily operators and the resident experience.

The notice-to-vacate window most operators never monetize

Posted on by Daria/SEO

A resident submits notice to vacate. Inside most multifamily operating platforms, that single action sets off a well-instrumented cost sequence. The unit enters the make-ready queue. Turn vendors are scheduled. The revenue management system starts pricing the vacancy. Someone begins counting days.

What almost never starts is a revenue process.

This is the one moment in the entire resident lifecycle where an operator knows, with near certainty, that a household is about to spend money on moving services. The resident is going to hire movers. They are going to buy packing materials. Some of them will need storage. Most of them will need insurance at the next address. All of that purchasing happens inside a window the operator opened and can see, and almost all of it happens somewhere the operator cannot see.

The window is already the most instrumented moment in your portfolio

Operators measure this period closely, because the costs are severe and well understood.

Turn costs have been climbing. The National Apartment Association reported that leasing expenses reached $292 per unit in 2024, “largely driven by a 17.5% increase in turnover costs year-over-year” (NAA Income/Expense IQ 2024 National Summary). On the individual turn, Zego’s Resident Experience Management Report, published through NAA, put the cost at “$4,000 per unit, which includes lost rent, concessions and maintenance.”

The vacancy side has moved against operators as well. RealPage Analytics found that “nationwide, average vacant days hovered at 34.4 at the end of 2024, compared to about 30 in early 2020,” and noted that “with more than half a million stabilized units unoccupied, the additional impact to property operations quickly adds up.”

So the window is not an unknown. Every operator at 10,000 units and above already has dashboards pointed at it. The instrumentation exists. It is pointed exclusively at cost.

Why the revenue side stays invisible

Three things make this window commercially blind for most operators in residential real estate.

The first is timing. Notice arrives through a portal, an email, or a conversation with a leasing associate. It creates a task. It does not create an offer. By the time anyone in the organization is thinking commercially about that household, the household has already booked a mover.

The second is ownership. Move-out sits between departments. Leasing owns the new lease. Maintenance owns the turn. Accounting owns the deposit. Nobody owns the departing resident as a customer, so nobody is accountable for what that customer buys.

The third is measurement. If revenue in this window is never captured in a system of record, it never appears in a report, and a category that never appears in a report never gets a target. The absence becomes self-sustaining.

What the departing household is actually buying

The commercial content of this window is concrete, and it is dominated by moving services.

Movers come first. This is the largest single purchase most households make during a move and the one with the tightest booking window. Packing services and materials attach directly to it. Storage attaches for the subset of households whose move-out date and move-in date do not line up, which is a common pattern in urban portfolios.

Insurance sits alongside those services as a financial risk mitigation item rather than a convenience. A departing resident needs coverage at the next address, and the operator receiving that resident needs verified coverage in place before keys change hands. Handled as an afterthought, this becomes a compliance chase after occupancy. Handled inside the move workflow, it becomes a condition of the move itself.

Utilities and connectivity follow the same pattern. Both are service decisions the resident has to make anyway, on a schedule the operator already controls.

None of these are new services. They are purchases that already happen on a predictable schedule, inside a window the operator opens. The question is whether the operator participates in them or watches them leave.

The retention argument runs through the same window

Retention is unusually strong right now, which changes the economics of every move that does happen. RealPage Analytics reported that “just over 54% of renters in market-rate apartments renewed their leases in the year-ending October 2024, amounting to a 120 basis point (bps) climb over last year.”

Large operators are seeing the same pattern in their own portfolios. Multifamily Dive reported Essex Property Trust’s CEO describing “a notably low turnover rate of 35%, while achieving positive new lease rate growth and stable occupancy levels,” MAA “reported improving turnover at 41.5% in Q1,” and Camden’s Keith Oden saying “our first quarter 2025 annualized net turnover rate of 31% was one of the lowest in our company’s history.”

Fewer moves means each remaining move carries more weight. It also means the quality of the move-out experience feeds directly back into reputation and referral, which feed back into the next lease-up.

This is also where resident-facing programs belong in the conversation. Paylode, which became a Moved company through an acquisition in November 2025, exists to make resident perks and offers a structured part of the operator’s relationship with the household rather than a scattering of one-off discounts. In the move-out window, that structure is what turns a service offer into something a resident actually accepts.

 

What this looks like when it is built properly

At 10,000 units and above, this has to be a system rather than a set of instructions to site teams. A few design requirements follow from that.

Notice has to trigger an offer, automatically, in the same motion that it triggers the make-ready task. If the trigger depends on a leasing associate remembering, the program will work at some communities and fail at others, and the portfolio-level number will never move.

The offer has to be the same everywhere. Portfolio-wide consistency is what makes the revenue measurable and what makes vendor economics work. A different arrangement at every region produces a number nobody can report on.

Every transaction has to land in a system of record, attributed to the property and the move event. Revenue that cannot be attributed cannot be reported, and revenue that cannot be reported has no standing with an asset management team.

And the move-in and move-out sides have to be treated as one workflow rather than two, because the household leaving one of your communities is frequently the household arriving at another, and the same services apply at both ends.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow.

What to measure

Four things tell you whether the window is actually working.

Offer rate: the share of notices that produced a service offer inside the window. This is the honest test of whether the trigger is automated. Anything materially below full coverage means the process still depends on memory.

Time from notice to first offer. The mover booking decision happens early. An offer that arrives a week after notice is competing against a decision the household has already made.

Attach rate by service, tracked separately for movers, packing, storage, insurance, utilities and connectivity. A single blended number hides which part of the workflow is failing.

Consistency across the portfolio. Compare the spread between your best-performing region and your worst. A wide spread is a process problem rather than a market problem.

Where to start

Pull one quarter of notices across the portfolio and answer a single question for each: what did this household buy, and did we see any of it. Most operators cannot answer for the majority of records, and the size of that blind spot is the finding.

From there the sequence is straightforward. Automate the trigger off the notice event. Standardize the offer set across every region. Put the transactions into a system of record. Then measure the four numbers above and hold them at the portfolio level rather than the property level.

Frequently asked questions

Is this the same as charging residents more fees?

No. The services described here are purchases the household is already making with an outside provider. The change is that the operator participates in a transaction that is happening anyway and takes responsibility for its quality. Regulatory attention on rental fee disclosure is increasing, which makes the distinction between a mandatory charge and an optional service the resident chooses more important, not less.

Does this slow down the turn?

Handled inside the workflow, it does the opposite. Coordinated move-out scheduling, confirmed key return, and booked elevator or loading dock time all reduce the resident-driven delays that push vacant days up.

We already offer some of this at a few communities. Why change anything?

Property-level programs produce property-level results. The reason to systematize is that a portfolio number only exists when the trigger, the offer set, and the reporting are identical everywhere. Without that, there is nothing for an asset management team to underwrite.

What about residents who do not want to be sold anything?

The offer should be genuinely optional and clearly presented. The service quality standard matters here as well, because the operator’s name is attached to whoever shows up on moving day.

Closing

The notice-to-vacate window is already the most closely watched period in the resident lifecycle. The instrumentation exists. The dates are known. The household’s purchasing intent is as clear as it will ever be. What is missing is a commercial process pointed at the same window the cost process already occupies.

If you manage 10,000 units or more and want to see what your notice-to-vacate window currently produces, reach out to our team to walk through it with your own data.

Related reading: how operators turn the move-in and move-out process into a revenue workflow, and the complete guide to resident onboarding automation. For how this shows up on the resident side, see Moved for residents, and for the operator view, see Moved for multifamily.

The FTC rental fee rulemaking: what operators must disclose on move-in charges

Posted on by Daria/SEO

  For 10,000+ unit operators, the move-in moment is where a large share of non-rent revenue is created. Application fees, administrative fees, amenity charges, package and utility setup, insurance verification, and the paid moving services a resident selects all land in the same window. That window is now the subject of a federal rulemaking, and the way charges are disclosed at move-in is about to move from a matter of preference to a matter of compliance.

On March 12, 2026, the Federal Trade Commission announced an Advance Notice of Proposed Rulemaking on unfair or deceptive rental housing fee practices, published in the Federal Register on March 13, 2026. The notice asks whether the FTC should require full, upfront disclosure of every mandatory charge before a renter applies for or commits to a lease, and it covers the entire rental lifecycle from application through move-out. Public comments were due April 13, 2026. This article explains what the rulemaking means for the charges you process at move-in, and how to keep that revenue while staying on the right side of the disclosure standard.

What the FTC is actually proposing

The rulemaking targets charges that are not clearly disclosed upfront or that bear no reasonable relationship to the underlying cost of the service. According to the law firm Katten Muchin Rosenman, the notice specifically names application fees, administrative fees, convenience charges, and amenity fees as categories under review, and it contemplates a federal framework for rental fee transparency across the transaction. The full analysis is set out in Katten’s client alert on the proposed rule.

The intent is consumer protection. As the law firm Covington summarized in its Inside Privacy review of the ANPRM, the FTC is evaluating whether hidden or poorly explained charges constitute deceptive practices, as part of a wider federal campaign against so-called junk fees. The direction of travel is clear even before a final rule exists.

The pressure is not federal alone. In April 2026, a bipartisan coalition of state attorneys general, led by New York Attorney General Letitia James, urged the FTC to act on deceptive rental fees. Operators face a converging federal and state expectation that every charge is named, explained, and shown before a resident is asked to commit.

Why this lands hardest at the move-in moment

Disclosure obligations are easy to state and hard to operationalize when charges are scattered across a leasing team, a payments processor, an insurance vendor, and a moving partner. The move-in window is where those charges converge, so it is also where a disclosure gap is most likely to appear. A resident who sees an amenity fee or a utility activation charge for the first time on move-in day is exactly the scenario the rulemaking is written to address.

This is a revenue question before it is a compliance question. Non-rent charges at move-in are a core part of how operators in residential real estate build income beyond rent, and the move-in and move-out revenue workflow is where that income is captured. The risk is not that disclosure rules eliminate these charges. The risk is that a disorganized move-in process forces you to defend a charge you could have simply disclosed cleanly. Protecting the revenue and meeting the standard are the same project.

The compliance exposure, framed as financial risk

Undisclosed or poorly documented fees create measurable financial risk. An enforcement action, a state attorney general inquiry, or a class claim over a single fee type repeated across a 10,000+ unit portfolio is a liability that scales with the size of the book. Renters insurance sits inside this same risk picture. Requiring coverage protects the asset from resident-caused loss, and verifying that coverage at move-in is the point where enforcement is frictionless. A move-in process that captures insurance verification and discloses every charge in one flow turns two separate liabilities into one controlled step.

The paid services a resident chooses during move-in, including movers, packing, and storage, belong on the same disclosed ledger. When these are presented as clearly optional resident selections with transparent terms, they support the resident experience and stay well clear of the mandatory-fee definitions the FTC is scrutinizing. Clean separation of mandatory charges from optional services is one of the strongest protections available under the proposed standard.

What a disclosure-ready move-in looks like

Operators that will adapt fastest share one trait: their charges live inside a single move-in and move-out workflow rather than across disconnected tools. A disclosure-ready process presents every mandatory charge before the resident commits, separates optional services from required fees, timestamps what was shown and when, and produces a record an operator can stand behind if a charge is ever questioned.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow, which is what makes clean disclosure possible at scale. When the charge, the disclosure, and the record are one system rather than three, compliance stops being a manual audit and becomes a property of the process. For operators standardizing this across a portfolio, the guide to resident onboarding automation covers how the workflow is built.

A practical checklist for portfolio operators

Ahead of any final rule, four moves reduce exposure now. First, inventory every charge a resident can incur from application through move-out and label each as mandatory or optional. Second, confirm each mandatory charge is disclosed before the resident commits, not on move-in day. Third, verify that the amount of each fee has a documented relationship to the cost of the service it covers. Fourth, keep a durable record of what was disclosed to whom and when. A move infrastructure built for multifamily operators produces that record automatically as part of the move-in and move-out flow.

Frequently asked questions

Is the FTC rule final?

No. As of the April 13, 2026 comment deadline it is an Advance Notice of Proposed Rulemaking. The FTC may proceed to a proposed rule or take no further action, but the disclosure expectation is already being reinforced by state attorneys general.

Does this ban move-in fees?

No. The rulemaking targets charges that are hidden, unexplained, or unrelated to the cost of the service. Clearly disclosed charges tied to a real service are the intended safe path.

What about optional services like movers, packing, and storage?

furthermore optional resident selections with transparent terms are treated differently from mandatory fees. The key is presenting them as genuine choices and keeping them separate from required charges.

How does insurance verification fit in?

Requiring and verifying renters insurance at move-in is risk mitigation for the asset, and doing it inside the move-in and move-out workflow keeps enforcement clean and documented.

Get ahead of the standard

The operators who will handle this rulemaking comfortably are ones who disclose cleanly because their move-in and move-out charges already run through one workflow. If you want to see how  single move infrastructure captures every charge, verifies insurance, and produces a defensible disclosure record across a 10,000+ unit portfolio, contact Moved to walk through it.

Resident-side turn delay the move-out days your vendor scorecard never sees

Posted on by Daria/SEO

Every large operator measures turn. Days to make ready, vendor speed, cost per turn, and quality scores are tracked closely because turn time is one of the most expensive variables in the portfolio. Apartment turnover costs have held steady at about $3,872 per turn, according to Zego’s Resident Experience Management Report as covered by Multifamily Dive, a figure drawn from 630 property managers of communities with 250 or more units. That number captures the vendor side of turn well. It misses a second source of delay entirely.

There is a stretch of the turn that no vendor scorecard measures, because no vendor controls it. It is the resident-driven half: how quickly notice is processed, how the move-out is scheduled, whether keys and fobs come back on time, and whether the dock and elevator were booked so the outgoing move and the incoming move do not collide. Call it resident-side turn delay. It sits before your make-ready crew ever gets the unit, and for most operators it is invisible.

Why the resident side of turn is unmeasured

Turn measurement starts when maintenance takes possession of an empty unit. Everything that happens before that point is treated as a fixed input rather than a managed process. But the days between a resident giving notice and maintenance actually starting are real vacancy days, and they are just as expensive as the days your crew is painting.

The reason this half goes unmeasured is structural. Notice handling lives in the property management system. Move-out scheduling lives in an email thread or a leasing office conversation. Key return lives on a hook behind the front desk. Dock and elevator booking, where it exists at all, lives in a building calendar. Because the resident side of turn is spread across four disconnected places, no single number ever adds it up. What is not measured does not get managed, and what is not managed drifts.

Where the delay actually accumulates

Resident-side turn delay compounds in a few predictable places. Notice that arrives by phone or email and is entered late starts the clock late. A move-out that is never formally scheduled leaves the outbound date uncertain, so the make-ready plan cannot be sequenced. Keys and access fobs that come back a day or two after the resident has physically gone leave the unit legally occupied and untouchable. And in buildings with a single freight elevator, an unbooked move-out can block the move-in of the next resident, adding days that appear nowhere in a vendor report.

None of these are maintenance failures. They are coordination failures, and coordination is exactly the part of the move that operators have historically left to chance. This is the resident-driven mirror of the well-run move-in and move-out revenue workflow: the same window that generates non-rent revenue also determines how fast a unit turns.

The revenue view comes first

Before the efficiency story, there is a revenue story. The move-out is not only a cost event to be minimized. It is a revenue event to be captured. A resident who schedules a move-out through a guided flow is a resident you can offer movers, packing, and storage to at the exact moment those services are relevant, which supports both the resident experience and the operator’s non-rent income. The same coordinated flow that shortens the turn also opens the paid-services window. Treating move-out purely as a maintenance trigger leaves that revenue on the table.

This is the difference between managing turn as a cost and managing the move as an asset. When the resident side of the move-out is a real workflow, it earns revenue and shortens vacancy in the same motion. 

Naming the metric so you can manage it

A category gets managed once it has a name and a number. Resident-side turn delay can be measured as the elapsed time between notice received and unit ready for make-ready, broken into its parts: notice-to-entry lag, scheduling lag, key-return lag, and access-booking lag. Once those four are visible, they can be targeted the same way vendor turn time already is.

The metric matters most at scale. Across a 10,000+ unit portfolio, a two-day average resident-side delay is thousands of avoidable vacancy days a year that never appear on a single vendor scorecard. Operators in residential real estate already accept that turn time drives rent growth. Extending that discipline to the resident-driven half is the next available gain, and it is one competitors have not named.

How the coordination gets closed

Closing resident-side turn delay means putting the four scattered pieces into one flow. Notice is captured digitally and starts the clock immediately. Move-out is scheduled by the resident inside a guided process. Key and fob return is tracked against that schedule. Dock and elevator booking is part of the same step, so the outbound and inbound moves are sequenced rather than colliding. Insurance status is confirmed in the same flow, which keeps the asset protected through the move-out and mitigates the financial risk of an uninsured resident-caused loss on the way out.

Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow, which is why the same system that captures move-out revenue also produces the timing data that makes resident-side delay visible. Operators standardizing this across a portfolio can see how the flow is built in the guide to resident onboarding automation, and how a move infrastructure built for multifamily operators unifies the pieces.

Frequently asked questions

Is resident-side turn delay a standard industry metric?

Not yet. Most operators measure only the vendor and make-ready side of turn. The resident-driven days before make-ready begins are real vacancy days that typically go uncounted.

How is it different from normal turn time?

Normal turn time starts when maintenance takes an empty unit. Resident-side turn delay measures the coordination lag before that point: notice handling, move-out scheduling, key return, and dock or elevator booking.

Does fixing it really move the number at portfolio scale?

Yes. Small per-move delays multiply across thousands of turns a year, so even a one or two day average reduction removes a large block of avoidable vacancy days.

How does move-out revenue fit into turn?

A guided move-out lets you offer movers, packing, and storage when they are relevant, so the same coordinated flow that shortens the turn also captures non-rent revenue.

See the half of turn you are missing

If your turn reporting stops at the vendor scorecard, the resident-driven days are still costing you and you cannot see them. To measure resident-side turn delay across your portfolio and close it inside a single move-in and move-out workflow, contact Moved.

 

Turning resident perks into a measurable revenue line

Posted on by Daria/SEO

Most operators run some form of resident perks. Discounts on local services, partner offers, rewards for on-time payment, and renewal incentives show up across the portfolio in one form or another. Almost none of it is measured as revenue. Perks are treated as a soft retention gesture, funded out of a marketing line, and reported as goodwill rather than a number that moves net operating income. That is the missed opportunity. A perks program that is instrumented correctly is a measurable revenue line, and it sits directly on top of the move-in and move-out moments operators already control.

This matters more in a market where rent alone will not carry the year. With rent growth decelerating and operating costs still climbing, the revenue that closes the gap is increasingly the non-rent kind. Retention is part of that math too. Apartment turnover costs have held steady at about $3,872 per turn, according to Zego’s Resident Experience Management Report as covered by Multifamily Dive. Every renewal a perks program earns is a turn cost you do not pay, and every partner offer a resident redeems can be a revenue event you can count.

Paylode is a Moved company

Moved acquired Paylode in November 2025, and Paylode is now a Moved company. That matters here because Paylode is a resident perks and loyalty platform built for exactly this problem: turning everyday resident engagement and partner redemptions into a structured, trackable program rather than a scattered set of one-off discounts. The Paylode loyalty rewards platform for multifamily is designed to recognize resident actions such as on-time payment, renewals, and community engagement, and to make the resulting value visible. Combining that perks engine with Moved’s move-in and move-out infrastructure gives operators a first-party path from the move itself to a measured perks line that no single-service vendor can match.

Why perks stay invisible as revenue

Perks fail to register as revenue for a simple reason: they are not connected to a transaction record. A discount handed out at the leasing office, an offer emailed to residents, or a reward mentioned at renewal has no structured trail. Nobody can say how many residents redeemed it, what it drove, or what it returned. Without that trail, finance has no choice but to treat perks as a cost of goodwill.

The fix is to attach perks to moments that are already instrumented. The move-in and move-out window is the most instrumented moment in the resident lifecycle, and it is where perks become measurable. A partner offer presented during move-in, a reward tied to an on-time renewal, or a redemption captured inside the resident flow all produce a record. Once there is a record, there is a number, and once there is a number, perks become a revenue line the CFO can underwrite.

The move is where perks get their record

The move-in and move-out flow is the natural home for a perks program because the resident is already transacting. During move-in a resident is selecting services, confirming details, and setting up their new home, so a relevant partner offer lands in context rather than as noise. The same is true at renewal and at move-out. The move-in and move-out revenue workflow already captures the moment; adding perks to it means every redemption is tied to a resident, a date, and an outcome.

This is also where paid services and perks reinforce each other. A resident choosing movers, packing, or storage during the move can be met with a partner reward that improves the resident experience and encourages the next action. The perk is no longer a standalone discount. It is part of a flow that already generates non-rent revenue, and it is measured the same way.

What a measurable perks line requires

Turning perks into a revenue line takes four things. First, a single catalog of offers and rewards so residents see a consistent program rather than a patchwork. Second, redemption tracking so every use is recorded against a resident. Third, attribution to the moment, so you can tell which perks earned renewals or drove service uptake. Fourth, ownership by one team that reports the number, the same way any other income line is owned. A perks program with those four properties reports like revenue because it is revenue.

Insurance belongs in this picture as risk mitigation. Verifying renters insurance inside the same resident flow protects the asset from resident-caused loss, and doing it alongside perks keeps the entire relationship inside one instrumented workflow. Operators in residential real estate that unify perks, paid services, and insurance verification in one flow get a resident experience that is both richer and fully accountable.

Standardizing it across the portfolio

The value shows up at scale. A perks program that is run property by property produces inconsistent offers and no portfolio number. Run as one catalog across a 10,000+ unit book, it produces a single measurable line and a consistent resident experience everywhere. Traditional tools focus on task tracking and administrative coordination. Moved embeds revenue-generating services and insurance verification directly into the workflow, and with Paylode inside that workflow the perks program becomes part of the same measured system. Operators can see how the underlying flow is built in the guide to resident onboarding automation, and how a move infrastructure built for multifamily operators ties perks to the move.

Frequently asked questions

Are resident perks really a revenue line, or just retention? 

They are both. Redeemed partner offers can be counted as revenue events, and the renewals perks drive avoid turn costs that hold near $3,872 per turn. Instrumented correctly, perks show up in both places.

What is Paylode and how does it relate to Moved? 

Paylode is a resident perks and loyalty platform, and it is a Moved company following the November 2025 acquisition. It provides the perks engine that pairs with Moved’s move-in and move-out infrastructure.

Why tie perks to the move-in and move-out moment? 

Because that moment is already instrumented. Attaching perks to it produces a record for every redemption, which is what turns perks from goodwill into a measured number.

How do perks and paid services work together?  

During the move a resident is already choosing services like movers, packing, and storage, so a relevant reward lands in context and can be measured alongside those selections.

Make your perks program count

If your perks are funded like a cost and reported like goodwill, you are running a revenue line without measuring it. To turn resident perks into a tracked, portfolio-wide number using Paylode inside Moved’s move-in and move-out workflow, contact Moved.