Totango allows you to create an account structure that best supports your customer data and engagement models.

• A "flat" hierarchy refers to a 1-customer level. In flat models, a single account record houses all of the relevant customer data; your teams log all engagements to this account. This model is easy to navigate and very common.
• A "multi-level" hierarchy refers to anything more than 1 level.

For guided training, check out our self-paced course: Planning Account Hierarchies in Totango. 

How do I know if I need a multi-level hierarchy?

You may need a multi-level hierarchy structure for any of these scenarios:

1. Your customer base is typically organized by different levels—where each level has its own contract / renewal dates
2. Your company sells multiple products

How many levels can I have?

Although Totango supports unlimited levels, hierarchy doesn't have to be complex. Avoid unnecessary levels and keep it as simple as possible. It's easier to add a level to your hierarchy than it is to remove a level later as you may lose data from the removed records. Also, keep in mind each hierarchy level requires additional configuration and has considerations in relation to your customer health modeling.

What is my team's "working level?"

Each level of your hierarchy becomes an account type in Totango. The "working level" refers to the level in the hierarchy where your teams log their tasks and touchpoints, and it's typically the level where contract and renewal information is handled. Your teams can work in other levels in the hierarchy, or data can be sent to Totango via integration. Numerical data and health can also be rolled up from lower levels.

SuccessPlays can use usage data to trigger tasks on the immediate parent account (if that is your working level), but users cannot be rolled-up to parent levels, so campaigns should typically be set up to trigger on the working level.

What are common hierarchy structures?

Flat structures are the most common. Multi-level with 3 or more levels is typically done only in large enterprise businesses.

What is the purpose of a product level?

If you have only one product (or no product at all), you may have a flat hierarchy. However, if you have multiple products, representing products as their own account type in the hierarchy structure gives you the ability to segment customers that own (or do not own) individual products. You can also segment via product usage data per product.

Including a product level is generally best practice if you have multiple products and your customers' contracts are based on products (i.e., you have a price or licenses per product and not fixed). If used, products are always the last level in the hierarchy.

What level should include usage data?

Usage data comes into Totango at the lowest account level (ultimate child). For multi-product structures, the lowest level is the product account.

What level should include contract value?

For most cases, we recommend that account attributes (e.g., contract value, create date, contract renewal date, etc.) come in at the lowest account level (ultimate child). This structure allows you to see health composition and revenue from the parent account.

For use cases where the parent level has contract value, you will see the health composition at the parent level but not the revenue composition.

In either case, we require that all attributes you bring into Totango are at the same level that you bring in data for contract value.

How do I implement a multi-level hierarchy?

Use the following attributes to implement multi-level hierarchy.

Refer to this video for more details. See upload account hierarchy for bulk import. 

• Parent ID: All levels except the "ultimate parent" should have a Parent ID. The Parent ID on a child account is the Account ID of its parent. A parent account can have multiple child accounts, but the child can only have one parent.
• Account Type: Use a different account type at every level (e.g., Company, Region, Product). Each account profile (per type) is its own record. If you want to see particular data in each level of the hierarchy, it must be added for each. Data doe not automatically "flow down" or "flow up" between parent-child accounts.
• Product ID: If you have a multi-product structure, the product account references the Product ID.
• Account Layout: Every parent level must be configured as a "Parent" in the account profile layout. The ultimate child level must be configured as the Ultimate Child in the layout.

Once assigned, you can view account types from Settings > Data Management > Hierarchy Types. You can also manage product information.

2 Customer Levels

GHQ is a company that owns Protractor and TradeSmart. Protractor and TradeSmart are the ultimate child nodes.

2+ Customer Levels

GHQ is a company that owns Protractor and TradeSmart.

TradeSmart has two branches: Financial and Investors. TradeSmart is a parent and a child (but not an ultimate child). Protractor is an ultimate child.

Customer usage data enters Totango at the ultimate child level in the account hierarchy. In this scenario, usage data would come in at Protractor, Financial, and Investors. The usage data from Financial and Investors will aggregate in the TradeSmart account. Aggregate data from the TradeSmart account and usage data from the Protractor account will aggregate in GHQ.

2 Customer Levels + Products

GHQ is a company that owns Protractor and TradeSmart. TradeSmart has two products: Product A and Product B. Protractor has Product A only. All product accounts are ultimate child nodes.

In multi-product structures, usage data enters at the product account level. Protractor will display the aggregate data of its product account, and TradeSmart will display the aggregate data of its product accounts. GHQ will show the aggregate data coming up through its child accounts.

FAQs

Question: Can I configure child accounts under product accounts?

Answer: Yes; however, they will not be viewable in the hierarchy navigation. You may instead consider adding any child accounts of product accounts at the same level of the product, and refer to the account type for delineation.