How should we structure records for a property manager with fifty buildings?

Two ways to flatten, both painful

Flatten to addresses and every property becomes an independent customer. You cannot see that one relationship produces a large share of your commercial revenue, you cannot tell when that relationship is eroding, and fifty separate records get fifty separate marketing touches.

Flatten to the company and every job piles onto one record. Equipment history, access notes and site-specific pricing become an undifferentiated mass, and technicians stop trusting the record because it never matches the building they are standing in.

Both mistakes are usually made by accident, because the software offered one obvious shape and nobody asked whether it fit the customer. Commercial and managed portfolios are the case where that default costs the most, since they are typically the largest and least replaceable relationships on the book.

Decide where each fact lives

• Account level. Contract terms, negotiated rates, payment terms, billing contact, insurance requirements, the relationship owner.
• Location level. Equipment inventory, service history, access and key information, on-site contact, site hazards, gate codes.
• Job level. Approvals, purchase order number, who authorized the work, the technician's notes for that visit.

What the structure buys you

Once accounts roll up, questions that were impossible become routine: revenue by account across all properties, which accounts have declining job volume, which properties within a healthy account have gone quiet, and what a portfolio is worth when a management company is up for renewal.

It also changes how you handle churn. Losing one property is noise; losing the account is a material event, and it usually shows up first as a slow decline across several properties rather than a cancellation. That signal only exists if the rollup exists, which is why account hierarchy is a prerequisite for useful revenue intelligence in commercial work.

When your software will not do it

Many residential-first field service platforms support a customer with multiple locations but not a true account above that. The practical workaround is a mapping table maintained in the integration layer: a list of which customer or location records belong to which account, with an owner responsible for keeping it current.

It is less elegant than native support and it works. The reporting layer joins through the mapping table, so account rollups are correct even though the source system has no idea accounts exist. This is a common shape for custom reporting built on top of a platform that was designed for a different kind of customer.