Impact level of Business Modeler

@zach_davis or @darkknight have experience with both, and I believe also took an organization through the transition into Relationships.

@kendra_mcclanahan may also have great input here.

I try to avoid it unless there is no other solution available as I have found it clunky and confusing for end users.

It’s a great question! Over the past several years, Gainsight has made it pretty simple to manage relationships from an admin standpoint. You can share assets across relationship types, including setting multiple scorecards at once, applying CTA Types/Success Plans, and developing shared sections on the 360. 

We recently moved all 4 of our products down to the relationship level so that CSMs can dig into individual usage of each product, track the key decision makers & influencers, and score the health of the relationship for each product (which rolls up to overall account). This also lets us easily break out the lifecycle stages by product since customers might purchase them at different times.

I will note, for a majority of our customers, we have more than 1 CSM managing the account based on purchased products. Relationships help give each CSM their own “workspace”. However, we do have some customers where a single CSM managing the relationship. From Company-level, they are able to associate activities, etc, to each product without overcomplicating the process. They can then still leverage relationships when they need to dig in on a specific product.

Hope this helps & happy to share more insights!

@kendra_mcclanahan I’ll admit it’s been a minute since I’ve really done anything with relationships. Last I recall, rolling up scorecards required building and managing additional rules because relationship scorecards didn’t automatically roll up to the parent. Has that changed?  Also, objectives at a Relationship Success Plan level could not be viewed/accessed through the Company Success Plan. Has that changed?  Do Relationship Contacts roll up now as well?

I also have heard about challenges attempting to reparent/merge relationships.

I also see a lot of recent threads in our Gainsight Admin Slack community with a negative slant towards relationships both from an administrative and end-user perspective related to implementation and ongoing use/maintenance.  I can say when I had previously attempted to leverage relationships, CSMs were confused between the C360 vs R360, when to log what where, understanding reporting between the laters, etc. Also, if you don’t have the right data structure/support it can be a near impossible hurdle to overcome. 

It’s not my intent to speak out of turn, but Gainsight’s internal implementation is probably a “best-case-scenario” and likely works because there is internal cross-functional backing all the way up to the CEO level to make it work - and I would assume (which, yes, I know what that means 😂) available resources to build and support the effort as compared to probably the majority of one-admin shops out there where getting that kind of support is often an up-mountain battle.

Not to denigrate the feature - I know there are valid use cases for it, but IMO it does come with not insignificant complications.

Very intriguing discussion.

@tboyette , this article also includes some debate and pros/cons.

Being part of a multi-product organization where different CSMs are assigned per product and the CS approach (and Customer Journey) differs from product to product, Relationships help us to clearly separate and structure things in Gainsight CS. We are doing almost anything on the Relationship level instead of Company. As an admin who has always been focused on 1 (or 2) of those products, it also helps me build efficiently, as changes I make to the Relationship360 layout for 1 product will not impact the other.

I’ll say I sort of land in between @darkknight and @kendra_mcclanahan on this one:

From a conceptual perspective, Relationships aka Business Modeler is pretty handy, and the new R360 (both user and admin side) make managing them easier than before that rollout. Being able to assign products to relationships and have that extra layer of detail can add a key layer of data enrichment for your business if your organization can effectively support it.

That is a big If. Like most platform features (not specific to Gainsight either) you need the data and business operations alignment to support the creation and maintenance of a product level hierarchy. If you have 4 SKUs that rarely change, and if they do it’s because you added a 5th, then you’ll probably have an easy time*.

If you have a complicated product structure, maybe your SFDC team uses CPQ and you also have to deal with complicated customer hierarchies in addition to product, then that becomes a bigger challenge. Do you have alignment to support a unified answer to “what is a product?” Does everyone in your Gainsight instance look at it the same way? Does that align with other systems/teams? If not what is your plan when executives or end users ask “Why does our CRM not match Gainsight?”.

You need to have good data AND good processes for it to work well. Constant (or even regular) change in product structure is going to make managing something like Product level Relationships challenging.

This is where the asterisk* from earlier comes in: Merging companies happens from time to time, and Gainsight has a feature to handle this. Merging relationships is more of a challenge: https://communities.gainsight.com/ideas/merge-relationships-9888/index2.html

what about record reparenting?

Even if you have a pretty straightforward use case, you still have an increase in overhead because you’re not just managing X number of C360 layouts, Company level dependencies on Scorecards, CTAs etc., but you now have to manage another layer of R360 Layouts, Scorecard dependencies, CTA attributes across Y number of products as well. And that’s if you only have one relationship type.

Not saying it’s impossible or that even the simplest use case is an insurmountable amount of admin overhead, but it’s not a one dimensional question:

• Do you know what you’re trying to do with it?
• Why you’re trying to do it? 
• Does your business have the existing data, processes and buy-in to support it? If not, are they able or willing to make changes or do you have to “shoe horn” in a solution?
• Do you have the resources on the Admin side to support the level of complexity your deployment would require? There will be extra rules, assets, layouts, dependencies and feature updates to maintain and deploy. 

There’s probably other questions still out there, but I have yet to work in an instance, even one without using Business Modeler, where nothing changes once it’s deployed requiring no upkeep.