Property Management

Multifamily Centralization Models: Which One Fits You

Swara - Property Management Technology Consultant September 17, 2026

Multifamily centralization is the reorganisation of property operations so that work that does not need to happen at the property (lead response, application processing, rent collection, accounts payable, maintenance dispatch, renewals) is done by a shared team for many properties, while the work that does need to happen on site (tours, inspections, repairs, resident relationships) stays with a smaller on-site team. It exists because the traditional model, a complete office and maintenance staff at every property regardless of size, cannot be staffed at current wages and cannot answer a lead at 9pm.

The word has been in every conference session for four years, and most operators have done something under its name. The trouble is that "centralization" describes at least four different operating models, they suit different portfolios, and one of them fails far more often than the others. This guide sets out the four, what to centralise first regardless of model, how staffing ratios move, the technology that has to be in place before the org chart changes, and how to tell whether it worked. RIOO's earlier post on how centralized property management improves efficiency covers the general case; this one is about choosing a model.

Why now

Three things changed at once. Labour: on-site leasing and maintenance roles turn over at rates that make a fully staffed office at every 150-unit property a permanent recruiting exercise, and wage growth has outrun rent growth in most markets since 2022. Residents: the majority of leads now arrive online outside office hours, tours are booked and increasingly self-guided through smart locks, and rent is paid through a portal, so the office desk is no longer where the work is. And technology: the systems that make remote work on a property possible (CRM with automated lead response, self-guided tour scheduling, online applications and screening, resident portals, mobile work orders, centralised AP) exist and are affordable, which they were not a decade ago.

The result is that a property no longer needs a person at a desk to lease, collect and dispatch, and the operator that keeps one there is paying for capacity it does not use. That is the case for centralization. The case against a particular model is what follows.

The four models

	Functional centralization	Pod (cluster) model	Hub-and-spoke	Fully virtual
How it is organised	One function at a time is pulled into a shared services team serving the whole portfolio (leasing, then AR, then AP, then dispatch), while properties keep a reduced on-site team	Properties are grouped into pods of 3 to 8 by geography; each pod has one shared team (community manager, leasing, maintenance lead) that covers all properties in it, with floating staff	A regional hub office holds leasing, AR, dispatch and administration for the region; each property keeps a small on-site presence (a resident services associate, a maintenance technician)	No on-site office; leasing, resident services and administration are remote or in a national centre, with self-guided tours, smart access and vendor-based maintenance
Fits	Portfolios of any size that want to move gradually; operators with strong central finance already	Dense portfolios with several properties within 15 to 30 minutes of each other, especially smaller assets (40 to 150 units) that cannot each justify a full team; this is the pod model property management firms adopt most often	Regional operators with 1,000 to 10,000 units in a few metros; mid-size assets (150 to 350 units)	Small assets, scattered-site and single-family portfolios, lease-ups with low traffic; operators with a strong technology stack and vendor network
Staffing effect	Central team grows as each function moves; on-site headcount falls by the roles centralised	On-site headcount per property falls sharply; pod team is sized to the pod's total units, not per property	Regional hub absorbs leasing and administration; on-site falls to 1 to 3 people per property	On-site falls to zero or a part-time presence; maintenance often outsourced
Where it works well	Leasing lead response, collections, AP, renewals: high-volume, rule-based, off-site by nature	Maintenance (technicians route between properties), leasing (one team knows all the availability), management oversight	Leasing and resident services at scale with local knowledge kept in the hub; consistent process across a region	Cost, for the right asset; 24/7 lead response; portfolios where on-site presence was never economic
Where it fails	Half-centralised functions with unclear hand-offs between site and centre; site staff who still do the work "to be safe"	Pods drawn on a map without regard to drive time or asset type; the pod manager becomes a full-time driver	Hub too far from the properties to know them; on-site person becomes a receptionist for the hub	Resident experience on larger assets; maintenance response; anything that needs a person on site in the next hour
The one that fails most often				Fully virtual on a conventional mid-size or large asset

The fully virtual model is the one that fails most often, and it fails in a predictable way. It is chosen for its cost line, applied to a 250-unit garden asset with a mixed resident profile, and within a year the review scores fall, the maintenance backlog grows because there is nobody to triage, and the leasing team that sits 900 miles away cannot answer "what is the neighbourhood like". The model is sound for scattered-site, single-family and small assets, where an on-site office never made sense; it is not a cost-cutting tool for assets that were built around one.

The pod model fails in a different way: pods drawn as circles on a map. A pod of six properties that are 45 minutes apart in traffic is not a pod; it is six under-staffed properties and a manager in a car. Pods are drawn by drive time and by asset type (a 60-unit walk-up and a 300-unit high-rise in the same pod share nothing), and they are re-drawn when acquisitions change the map. Hub and spoke property management has the same failure at regional scale: a hub placed for the regional manager's convenience rather than for the properties' drive times.

Most operators of scale end up with a combination: functional centralization of leasing response, AR and AP across the whole portfolio, with pod or hub-and-spoke on-site structures depending on how dense each region is. That is a reasonable answer, provided each property has exactly one model applied to it and everyone on it knows which.

What to centralise first

Whatever the model, the order in which functions move matters, and the same three go first.

Centralized leasing, starting with lead response: Every lead from every channel routes to one team that responds in minutes, seven days a week, qualifies, and books the tour (self-guided, agent-led or virtual) into the property's calendar. The application, screening, guarantor and lease signing steps follow into the same team. On-site staff conduct tours and meet residents; they do not sit by an inbox. This is first because it is the function where the traditional model measurably loses money (unanswered leads) and where the centralised version measurably wins (response time, conversion by channel).
Accounts receivable and collections: Rent posting, payment plans, delinquency follow-up, late fees, notices and the hand-off to legal are rule-based and better run by a team that does them all day across the portfolio than by a community manager between tours. It also removes cash handling from the site. The metrics to run it by are in our multifamily rent collection KPIs guide.
Maintenance dispatch, not maintenance: The technicians stay local; the intake, triage, scheduling, parts ordering and vendor assignment move to a central desk that sees every open work order across the portfolio. Centralized maintenance means the dispatcher decides that the technician at Property A, who is fifteen minutes from Property B and has the part on the van, takes B's water heater call, rather than B's resident waiting for B's technician to come back from leave. It is third because it depends on mobile work orders and a shared vendor panel being in place first.

After those three: accounts payable and vendor management (often already central in operators with an ERP), renewals and rent pricing, resident communications, and finally the community manager role itself, which in the pod and hub models becomes a multi-property role.

Staffing ratios before and after

The numbers below are illustrative ranges for a conventional, stabilised garden or mid-rise portfolio in the US; they vary by asset class, age and market, and an operator should benchmark its own before designing the target.

Role	Traditional on-site model	After centralization (functional + pod or hub)	What moved
Community manager	1 per property	1 per 2 to 4 properties (pod) or 1 per property at 300+ units	Administration, AR and reporting to the centre
Assistant manager / bookkeeper	1 per property above ~150 units	Central AR team at roughly 1 per 1,500 to 2,500 units	Rent posting, collections, ledgers
Leasing consultant	1 per 100 to 150 units	Central leasing team at roughly 1 per 400 to 600 units for response and processing; on-site tour capacity shared across the pod	Lead response, applications, screening, signing
Maintenance supervisor	1 per property above ~200 units	1 per pod or region	Scheduling, vendor coordination, parts
Maintenance technician	1 per 60 to 100 units	1 per 80 to 120 units, routed across the pod by central dispatch	Nothing moves; utilisation rises
Total on-site FTE per 100 units	Roughly 1.8 to 2.2	Roughly 1.0 to 1.4, plus central team

Two cautions on the ratios. The central team is not free; a portfolio that cuts 30% of on-site headcount and adds a central team of half that size has saved 15%, not 30%, and should plan on that. And the ratios only hold if the technology below is in place; an operator that removes the on-site leasing consultant before the CRM and self-guided tours are live has removed capacity, not centralised it.

Technology prerequisites

Centralization is an org-chart change that only works on top of a system change, and the sequence is system first. The prerequisites, in the order they are needed:

One CRM for all leads from all channels, with automated first response, lead scoring and a shared calendar for every property's tours, so the central leasing team can work any property. Self-guided or virtual tour capability with smart-lock access, so a tour does not require an on-site agent to be free. Online application, screening and lease signing, with the guarantor step included, so the central team can take a lead to a signed lease without a site visit. A resident portal for payments, requests and communication, so residents do not need the office. Mobile work orders with photo capture, parts and time, so dispatch can be central and technicians can be routed. A shared vendor panel with insurance tracking and central AP, so vendors can be assigned to any property. One data model across all properties, so a central team sees the same fields, statuses and reports everywhere. And dashboards by pod, region and function, so the centralised work can be measured rather than assumed; our post on why centralised dashboards matter covers the reporting side, and centralize decisions, not just data covers the governance side.

RIOO on NetSuite is built for the last three prerequisites. Every property, unit, lease, resident, work order and vendor sits in one NetSuite instance with one data model, so a central leasing, AR or dispatch team works from the same records as the site; the tenant portal handles payments and requests; service request and task management runs mobile work orders and central dispatch; and vendor management and AP runs the shared vendor panel. How a multifamily portfolio is structured in the system is in our guide to managing multifamily properties in NetSuite.

Measuring it

Centralization is judged on three sets of numbers, and the mistake is to report only the first.

Cost: on-site payroll per unit, central team payroll per unit, total operating payroll per unit, and the net change against the pre-centralization baseline. Report it net of the central team, and report it twelve months after the change, not three, because the transition period carries both teams.
Service: lead response time, lead-to-tour and tour-to-lease conversion by channel, application processing time, work order response and completion times by priority, resident satisfaction and review scores, and renewal rate. These are the numbers that tell you whether the model chosen fits the asset; a cost saving with a falling renewal rate is a loss.
Financial outcome: occupancy, delinquency and bad debt, controllable expenses per unit, and net operating income per unit against the pre-centralization run rate and against comparable properties still on the traditional model, if the operator has kept any as a control group. Keeping a control group for the first year is the single most useful thing an operator can do to know whether the change worked.

Report all three by pod, region and function, monthly, on the same dashboard the operations team uses, and revisit the model for any property where service falls while cost improves.

Frequently asked questions

Q1. What is multifamily centralization?
Reorganising property operations so that off-site work (lead response, applications, rent collection, AP, maintenance dispatch, renewals) is done by shared teams for many properties, while on-site teams are reduced to the work that must happen at the property: tours, inspections, repairs and resident relationships.

Q2. What are the main centralization models?
Functional centralization (one function at a time moved to a shared team), the pod or cluster model (a shared team covering a group of nearby properties), hub-and-spoke (a regional hub with a small on-site presence at each property), and fully virtual (no on-site office, with self-guided tours and remote resident services). Most operators of scale combine functional centralization with pod or hub structures.

Q3. Which functions should be centralised first?
Leasing lead response and processing, then accounts receivable and collections, then maintenance dispatch. These are high-volume, rule-based and do not need to happen on site, and each has a measurable before-and-after.

Q4. How do staffing ratios change with centralization?
Illustratively, total on-site staff falls from roughly 1.8 to 2.2 per 100 units to roughly 1.0 to 1.4, with a central team added for leasing, AR and dispatch. The net saving is smaller than the on-site reduction alone, because the central team is real headcount.

Q5. What is the pod model in property management?
Grouping three to eight nearby properties into a pod served by one shared team (community manager, leasing, maintenance lead) with floating staff, instead of a full team at each. It works when the properties are within a short drive of each other and of similar type; it fails when pods are drawn by map rather than drive time.