Skip to main content

Hi - we are trying to make a decision whether to use business modeler or not and are looking for other companies like ours that can offer some advice. Our company has a single product. Our SFDC implementation includes both parent and child accounts, but CSMs are most closely centered on product instances / contracts. On any account, a customer may have multiple product instances/environments with multiple CPQ contracts, which have different stakeholders, may have different buyers, etc. The majority of our customers (90-95%) have a single instance/contract per account, but for a lot of our largest global, high ARR customers, they have different teams/regions/child companies using different instances and contracts that we treat largely separately although it’s important to consider them together as well. Although we try to maintain a strict 1:1 relationships between Contracts and Instances, there are a few cases where folks have sold multiple instances under one contract (which makes tying seats purchased : seats used challenging).

Our question is - how should we think through deciding whether to implement business modeler with all its overhead and complexity vs. just doing a flat implementation looking at the instances as separate customers. If we go with Business Modeler, is it going to be more difficult for our end users to manage the 90-95% of accounts that are just 1:1? If we don’t go with Business Modeler, is there any other way to get insight into the larger accounts as a whole? What other questions should we consider?

Thanks for your input!

Hi @sarahatmiro - how are your customers represented in your CRM for the 10% that are complex? If the distinct entities in the parent child relationships is tied to its own CRM account record, then you might prefer to use Account Hierarchy to show the relationships between companies and to aggregate any number of account specific measures like ARR. 

 

Here is some more information on the Account Hierarchy functionality. Your Gainsight CSM can advise you more specifically based on a deeper discussion of your use case and needs. https://support.gainsight.com/Gainsight_NXT/07360/03User_Guides/View_Company_Hierarchy

Thanks Dan! We have Accounts that have Parent <> Child relationships in the hierarchy, and then Instances which are custom objects related to the Account object - each account may have one or multiple Instances which each have their own Contract. On any Account hierarchy, each account level may have separate single or multiple Instances. Our most complex accounts have both parent<>child accounts and then each type may have several instances. I think we would use the hierarchy functionality to represent Account parent<>child relationships, but are thinking we may want to use Relationships for the individual instances.

 

We will speak further with our solution engineer, I just was curious to see if there are other Gainsight customers who had a similar setup to ours that could advise.

@sarahatmiro - A few career stops ago, I administered a Gainsight instance where a similar question arose: Should we dive into Business Modeler (ie, Relationships). I spent a lot of time with my CS leaders explaining pros and cons, and eventually we decided not to deploy Relationships, based on these 2 criteria:

  • About 50% of our customers fit into the “multiple products / multiple instances” bucket (compared to your 10%). Even at 50%, we decided against taking on the additional administration and complexity of Relationships. In hindsight, that did mean we passed on some small pieces of beneficial Relationship functionality, but we did decide the increased value of Business Modeler was less than the increased effort to deploy it.
  • More importantly, CS leadership decided that even in the “multiple products / multiple instances” scenarios, they would continue to manage the Customer as a unit. Yes, we might occasionally have specific Playbooks to a Product, but as a whole a Company would always be served by a single CSM, would always have a single set of strategic goals, would always be surveyed as a Company. Because CS decided their most critical ‘unit of measure’ was a Customer (rather than an instance), the Company-centric model was the better fit.

Reply


Terms & ConditionsCookie settings