Accounts vs. Service Locations vs. Assets

Three things in Suprata can answer the question "where?":

• An Account is the billable entity — who pays.
• A Service Location is where the work happens — a geocoded address tied to an account.
• An Asset is a physical thing the customer owns or rents that gets serviced or rented out.

These three layers exist for a reason. If you collapse them — treating every customer as just "an account with one address" — the system feels fine for a few months and then breaks the moment you have a customer with multiple properties, a property manager handling several houses, or any equipment that gets serviced separately from the address it sits at.

This article explains the distinction and shows where each concept earns its keep.

The mental model

Picture a layered diagram:

Account ───── billable, the entity you invoice
   │
   ├── Service Location 1 ── address, geocoded
   │      │
   │      ├── Asset A (HVAC unit at this address)
   │      └── Asset B (water heater at this address)
   │
   └── Service Location 2 ── another address, geocoded
          │
          └── Asset C (boat at this slip)

An account can have many service locations. A service location can have many assets. Most residential customers are simple — one location, maybe a couple of assets. But multi-property and commercial customers regularly have all three layers populated, and the system lets that work cleanly.

What each one actually is

Account

The billable entity. This is who the invoice goes to, who the credit-card-on-file belongs to, who the account-level credits accrue to, and whose payment history Stripe / QuickBooks know about. An account has a billing address, primary contact, balance, terms, and any number of associated contacts (people).

Residential accounts are usually named after the head of household or the family ("Bob Jim"). Commercial accounts are usually named after the organization. The display name is computed automatically — for residential, it pulls the primary contact's name; for organizations, it uses the organization name.

The billing address on the account is where the bill goes. It doesn't have to be the same as where the work happens.

Service Location

A geocoded address tied to an account. This is where the work happens. The geocoding lets the routing engine cluster jobs geographically and the dispatcher see addresses on a map.

Why service locations are separate from accounts:

• A residential customer with a vacation home has one account, two service locations. The bill goes to one address. The HVAC service might be at the other.
• A commercial customer with multiple stores has one account, ten or fifteen service locations.
• A property manager managing rentals has one account per property (more on that pattern below), but each account itself has its primary service location.

Service locations carry their own notes, contact preferences ("call Joe before showing up"), and access info (gate codes, lockbox combinations). When a job is created, you pick which service location applies.

Asset

A physical thing the customer cares about. Assets are a layer below service locations because they sit at a location.

Examples by industry:

• HVAC: each indoor unit, each outdoor unit, each thermostat — separate assets so service history attaches per unit.
• Marine service: each boat, each engine, each generator.
• IT services: each server, each workstation, each network switch.
• Property management: each appliance worth tracking (water heater, fridge, washer/dryer).
• Equipment rental: every piece of equipment that gets rented out is an asset (and in the reservations system, a bookable asset).

Assets accumulate service history over time — every job done on a specific asset is linked to it, so when the customer asks "when did you last replace this compressor?", you can answer.

The two kinds of assets

A confusing detail: there are two kinds of asset in Suprata, and they show up in different parts of the product.

• Service assets — the physical things at a customer site that get serviced. The HVAC unit on the customer's roof, the boat in their slip, the network gear in their server closet. Each job you do is linked back to the specific asset it was performed on.
• Reservation assets — the bookable things at your property that customers rent. Slips, campsites, RV spaces, rental tools. These live in the Reservations area.

They're conceptually similar (both are "physical things") but they answer different questions:

A boatyard often has both: a customer's boat is a service asset (you do work on it) AND that same boat is occupying a slip, which is a reservation asset (the customer is renting from you). One physical boat shows up under two different systems for two different reasons.

When you'd use each

Use just an account when

• The customer is residential, has one address, and you don't track equipment at the unit level.
• Most one-off-job customers — first-time service calls, walk-ins, single-shot jobs.

You can absolutely operate a small service business on accounts alone, no service locations, no assets. The account's billing address is also the service address by default.

Add service locations when

• A customer has more than one property.
• You're a commercial-heavy business and most customers have multiple locations.
• You want geocoding-based route optimization.
• Different sites need different access notes / gate codes.
• You want clean per-site service-history reporting.

If most of your customers are single-location, don't force service-location tracking on every new account — it's overhead. Add the second location when it actually exists.

Add assets when

• You're tracking maintenance history on specific equipment ("when was this unit last serviced?").
• You sell warranty or extended-service contracts that need to know which unit is covered.
• You're an HVAC, marine, IT, or generator-service company — these industries practically require asset tracking.
• A customer might have multiple of the same kind of equipment at one site (two HVAC units, three boats, twelve workstations).
• You're running a reservations property — every bookable thing must be an asset.

The "one account, one service location, one asset" trap

A common mistake on first setup: creating every new customer as one account with one service location and one asset, all named the same thing, regardless of what's actually true. You end up with three layers of redundant data that should just be the account.

Rule of thumb: don't create the layer until you actually need the layer. Don't create a service location for a customer until they have a property at a different address from billing. Don't create an asset until there's a piece of equipment that has its own service history (or a piece of bookable inventory).

Property managers — a special case worth knowing

Property managers don't fit cleanly. A property management company manages 30 houses on behalf of 30 owners. Each property gets a separate account (because billing details differ — owners pay separately, or the management company pays and rebills). Each owner is a contact attached to their account. The property manager themselves is a contact who's attached to all 30 accounts.

That way:

• The bill goes to whoever's right (owner or management).
• The property manager can be reached for scheduling on any of them.
• Service history is per-property.

There's a separate, longer guide for this: Setting up Suprata for a property management company.

Common mistakes

Putting the service address into the billing address field for a customer with multiple properties. Now your invoice goes to the wrong place. Set up a service location for each property; keep the billing address on the account stable.

Creating a separate account per service location. This is the inverse mistake. The customer is the same person — same payment method, same balance, same statement. Don't fragment them across accounts. Put the locations under one account.

Tracking assets when you don't need to. If you've never once looked up "what did we do at this unit last year?", asset tracking is overhead with no payoff. Skip it until you actually have a use case.

Confusing reservation assets and service assets. They look similar but live in different parts of the product. The slip your customer rents is a reservation asset. The boat they own is a service asset. The link between them is the customer, not the asset itself.

Forgetting to verify the service location's address. A service location whose address didn't fully resolve to a real place won't sit on the map correctly, which means route optimization will send your techs the long way around. After saving a new location, glance at the map preview to confirm the pin is where it should be. Fix any oddballs (typos, missing unit numbers, mis-spelled streets) before they cost you a service call.

Letting old service locations linger after a customer moves. Dispatch will offer them as options on new jobs and someone will pick the wrong one. Mark old service locations inactive or delete them.

Related articles

• The anatomy of an account vs. a contact
• Creating your first job
• Setting up Suprata for a property management company
• Setting up Suprata for a marine service company
• Jobs vs. appointments vs. reservations