The account that doesn't fit one address
Most field-service software, and most of the habits built around it, assumes a customer is a person at an address. That model works fine for the homeowner with a furnace. It falls apart the moment you land the account that's actually worth having: the property manager with forty buildings, the restaurant group with a dozen kitchens, the school district with eight campuses, the facilities company that hands you a list of sites. These accounts are a single billing and decision-making relationship spread across many physical locations — and they're usually your highest-value, most durable revenue, the recurring relationships that a one-furnace customer never becomes.
The trap is modeling them wrong. The fast, lazy way is to create a new "customer" for every location — "Westside Apartments Bldg A," "Westside Apartments Bldg B," and so on. It works for exactly one job. Then the relationship fractures: the service history scatters across a dozen unrelated records, you can't see that "Westside" as a whole is a $40k-a-year account, billing turns into a dozen separate threads, and the contact who actually makes decisions is buried under buildings. You've taken your best customer and shredded them into your CRM as strangers.
Model it as one customer with many sites
The right model is the one the relationship actually has: a single customer record that carries multiple service locations under it. One account for the property manager; many sites beneath it for the buildings. The decision-maker, the billing relationship, and the rollup all live at the customer level. The addresses, the equipment, and the per-location job history live at the site level. That structure mirrors reality, and reality is what makes everything downstream work.
Hosting Field is built around exactly this shape: a customer carries contact, company, and address, and supports multiple service sites beneath it, so a single account can hold many locations without fragmenting. A job is booked against a specific site, but it rolls up to the parent customer — so you keep both the granular "what happened at Building C" and the whole-account "what is this relationship worth" views at the same time. You're not choosing between location detail and account context; the model gives you both because it's structured the way the account is.
Get this right and a pile of consequences fall into place:
- History lives where you need it. The service history for one building is right there when a tech rolls up to it — what was done last time, what broke before — while the account-level view shows the whole relationship at once.
- Billing matches the relationship. One customer means one coherent billing thread, even when the work spans ten addresses. How you actually invoice — consolidated or per-site — becomes a choice you can make, not a mess the data structure forced on you.
- The account becomes visible as an account. You can finally see that the property manager is worth $40k a year across all their buildings, which is the number that justifies how you treat them — and the foundation for measuring customer lifetime value on the accounts that actually have a big one.
Dispatching across an account's sites
Multi-site accounts change how the work hits your board, and a couple of disciplines keep them from creating chaos:
- Route the sites, not just the jobs. When one account has several buildings clustered in an area, batching their work into one trip is a windshield-time win the single-address model never surfaces — because you can see the sites belong together. A tech doing three buildings for the same property manager in one swing beats three separate trips on three different days.
- Pin the site-specific knowledge to the site. Gate codes, which unit the shutoff is in, who to call at that building, the equipment that lives there — that's site-level context, and it has to travel with the site so the tech who's never been to Building F isn't calling the office for the door code. This is also where tracking equipment and assets at customer sites earns its keep across a multi-location account.
- Keep the decision-maker at the account level. The person who approves the work and gets the invoice usually isn't on site at all. Booking against a site is right; routing approvals and communication to the building's front desk instead of the property manager is how you annoy the person who controls the contract.
The mistake to avoid is over-fragmenting in the other direction — spinning up a site for every visit instead of every location, so the same building exists three times. A site is a place, not an event. One physical location, one site record, however many jobs it accumulates.
Why this is a retention and growth lever, not just tidiness
It's tempting to file this under data hygiene, but the multi-site model is really a revenue lever. Multi-location accounts are sticky — switching vendors across forty buildings is painful, so a property manager who's happy stays for years — and they grow: today's twelve sites become fifteen, and the operation that already has the account is the obvious one to take the new buildings. But you can only capitalize on that if you can see the account as a whole. An operation that's flattened it into disconnected records can't tell its anchor accounts from its one-offs, can't spot that a big multi-site customer's job volume is quietly slipping before they churn, and can't walk into the renewal with "here's everything we did across all your locations this year." The model that keeps the account intact is the same model that lets you grow and defend it.
What to measure
- Revenue per account, rolled up across sites — the number that tells you which relationships are actually your biggest, which the per-address model hides entirely. It's how you know who deserves the white-glove treatment and the proactive call.
- Site coverage within an account — of a multi-location customer's locations, how many you actually service. The gap is your most qualified pipeline: the buildings you're not yet doing for an account that already trusts you are the easiest upsell you'll ever find.
- Account-level job trend — whether a multi-site customer's volume across all locations is rising or quietly falling. A single building going quiet is noise; the whole account trending down is a churn warning you want long before the renewal conversation, and you can only see it if the sites roll up to one account.
Your best customers don't live at one address, and the software habit of treating every location as a separate stranger quietly costs you the history, the billing coherence, and the growth those accounts are made of. Model the account the way it really is — one customer, many sites, work booked at the site and rolled up to the relationship — and the property manager with forty buildings stops being forty headaches in your system and becomes what they actually are: the single most valuable relationship on your books.