Running Amenities Across Multiple Buildings
How small portfolios can share a single amenity system without merging resident lists or losing per-building control.
One System, Many Buildings
You manage three buildings in the same neighborhood. Each has a gym. Two have rooftops. One has a party room that everyone keeps asking about.
Do you run three separate booking systems? Do you give residents in Building A access to Building C's amenities? And how do you keep the reporting clean when someone's new owner wants to see usage by building?
Most small portfolios get this wrong. They either run everything as one big mess — or they run three completely separate systems and spend hours reconciling.
What "Shared Amenities" Actually Means
A shared amenity is one that residents from multiple buildings can book. A per-building amenity stays locked to residents of that specific building.
Most portfolios end up with a mix:
Per-building (the default). Gyms, laundry rooms, small common areas. Residents of Building A book Building A's gym. Nothing fancy.
Shared across the portfolio. High-value amenities that one building has and others don't — the rooftop bar, the party room, the guest suite. Residents across all your buildings can book these.
The trick is letting residents *see* the shared amenities without accidentally exposing private ones.
When to Share, When to Keep Separate
Share an amenity when: - Only one building has it, and you want residents of other buildings to benefit - Utilization is low in the building that owns it - The amenity was always intended to serve the portfolio (a central event space, for example)
Keep an amenity per-building when: - Residents pay a premium for that building specifically because of the amenity - Capacity is already tight — sharing makes it worse - Access control (keys, fobs, cameras) is tied to that building only
Ask the question: "If a resident of the other building shows up to use this, does it feel normal or does it feel like they're stepping outside their building?" That answer tells you whether to share it.
Keeping Resident Lists Separate
Sharing an amenity shouldn't mean merging resident databases. In a properly configured system, residents of Building A still belong to Building A — they just get permission to see and book a specific subset of amenities elsewhere.
This matters because:
Move-outs don't cross-contaminate. When someone leaves Building A, they lose access to everything — including the shared rooftop. You don't have to remember to revoke it manually.
Notifications stay local. A maintenance alert for Building B doesn't go to Building A residents.
Reporting stays clean. You can still pull usage stats per building, per amenity, per resident.
Reporting Across a Portfolio
When you're running one amenity system across multiple buildings, you want two views:
Per-building view. How often is Building A's gym being used? How many residents in Building B booked the rooftop this month? This is your operational report — the one you use to spot problems.
Portfolio view. Across the full portfolio, which amenities get the most use? Where are we charging for amenities and how much has come in? Which buildings generate the most bookings per unit?
The portfolio view is what you show owners or asset managers. The per-building view is what you use every day.
Billing Across Buildings
If you charge for any shared amenities, the question becomes: which building's revenue is it?
Two defensible answers: 1. **Revenue goes to the building that owns the amenity.** The rooftop bar is on Building C — Building C's P&L gets the booking fee. 2. **Revenue is split proportionally.** If Building A residents booked 40% of the slots and Building B booked 30% and Building C 30%, split the revenue that way.
Either works. Pick one, document it, and stay consistent.
When to Split Back Into Separate Systems
Sometimes a portfolio gets big enough that one system stops making sense. Signs you've outgrown the shared setup:
- - You're managing more than ~10 buildings with wildly different amenity sets
- - Buildings have different owners who need clean operational separation
- - You're spending more time configuring the shared system than it saves you
For most small portfolios (2–10 buildings), a single system with shared + per-building amenities is the right answer.
The goal is one place to run amenity booking across your portfolio — without the operational mess of one big shared database.
About AmenityResy
AmenityResy is the smart scheduling platform for apartment amenity booking. We help property managers reduce conflicts, improve resident satisfaction, and simplify building operations.