Acknowledged

Relationship within a Relationship

  • 13 August 2020
  • 6 replies
  • 81 views

Userlevel 5
Badge

Very pleased with relationships. To make it even better would be to have relationships within a relationships (a tree data structure). Our customers are provisioned application environments (relationship level 1) and those applications have various modules and feature (level 2 relationships to the application level 1 relationship).

 

Maybe there is another way others have found helpful to manage, track and act on “sub-relationship”-type features/modules? 


6 replies

Userlevel 5
Badge

With relationships, you get all the features (scorecards, CTAs, timeline, etc). Do you manage accounts at all 3 levels (account, relationship, sub-relationship)? 

I have helped clients build out different levels of their data to show that kind of structure: 

  • Account
    • Product (Relationship)
      • Modules and/or Features

But typically what I have seen is that they just wanted to be able to report certain data elements against the Modules or Features. For example, they wanted to see Cases and Usages attributed to each module or feature. We solved this with tagging the data and creating multiple filtered reports on the Relationship.

For CTAs or Scorecards, you could track the feature/module as well. For example, if you have an onboarding playbook for each future, you could specify that in the CTA name on the Relationship. And you could have scorecard measures for each feature under a category called Features. 

I don’t know if that helps but I just wanted to point out that it might create a lot of complexity if you truly could do Account > Relationship > Sub-Relationship. It could end up requiring a lot more rules and a lot more structure in setting up all their other features like CTAs and Scorecards. 

Userlevel 5
Badge

Thanks that was very helpful. I like the idea of simply tagging the data and creating filtered reports. 

 

We want to monitor usage around a specific module within the product, but then assign specific attributes based on the usage+contextual knowledge about the customer. Eg. Customer is power user on the feature and loves it → would be great reference for a prospect who is interested in this specific use-case (rather than any old customer who uses the same product and loves it, but for entirely different use-case). I want to be able to match prospects to customers who have the exact same pain point. 

 

Having tons of attributes related to a single relationship for each sub-feature/module would get sloppy I think, which is why I thought a sub-relationship might be preferable. 

Userlevel 5
Badge

That makes sense. I would recommend looking into tagging the data. It’s a workaround for now but may also be an easier long term solution for you to maintain.

Userlevel 4

Hi @jlicciardello, most of the customers go about the way @CurtisValentine suggested. 

From the product per se, we do have plans to work on relationship hierarchy. However, it is a part of our long term roadmap. We may not work on it in the immediate future. 

If possible, please explore the approach suggested by @CurtisValentine and let us know if it would work for you. 

Userlevel 5
Badge

@muralikrishnagopu  Yes the tagging has been working fine for us. I don’t think we need  a relationship hierarchy any more.

Userlevel 4

@jlicciardello - Glad it worked for you!

Reply