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?
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:
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.
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.
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.
Hi
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
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
