Object Relationships for Modeling Energy & Utility Customers

Learn about best practices for modeling customer accounts in the Energy & Utilities data model.

For B2B customers, Salesforce recommends:

• One business account per business entity or customer, organized into a hierarchy to reflect the structure of the company

• One or more billing accounts to reflect the billing relationships of the customer, depending on the level in the customer hierarchy at which bills are issued

• One service account per premises

• One asset per service point or product

A B2C customer might have only a consumer account that includes billing and location data.

Although one asset per service point is most common, assets can be mapped to each business or consumer account or premises. Large B2B customers might have one asset per product bundle or per commodity unit rate (child product).

In the following B2C variations, billing information is included in the consumer account, but service accounts are separate:

• One customer owns one house — one consumer account has one contact

  

• Two customers own one house — one consumer account has two contacts

  

• One customer owns two houses — two service accounts share one consumer account

  

• One customer is the owner of one house and the authorized contact for another customer who is a family member — two consumer accounts share one contact

  

For small-to-medium B2B customers, similar variations for business accounts are possible. For example, as with houses, a person can own more than one business and a business can be owned by more than one person.

A multisite B2B customer might have:

• More than one business account 

• Hierarchies of business, billing, or service accounts

• Numerous contacts for various accounts

• Multiple assets per service point, such as one asset per product bundle or per commodity unit rate (child product)

• Contracts instead of or in addition to assets

With those exceptions, the same basic structure usually works. Variations depend on the business scenario or focus (for example, sales vs. service) that the provider wants to implement.

The advantages of this basic data architecture are:

• Different views of the customer are directly accessible, including an overview of the locations at which a customer is serviced.

• A relationship with one customer at a location can be different from the relationship with another customer at the same location.

• There is flexibility for combining parties.

• Context-dependent data (commercial, service, billing) is available.

• Master data (locations where a customer is serviced) facilitates the creation of and is independent of transactional data (such as opportunities, quotes, and orders).