If you haven’t had a chance to read about our action-packed Q3 release, I strongly urge you to go through this blog post by Karl, our VP of Products. But if you have, I’m sure you are just as excited as we are about all the steps we are taking to help you manage your customers better.
The main purpose of this post is to double click on the differences between Gainsight Relationships (a major feature of the Q3 release) and Account hierarchy set-ups. In the process of doing so, I’ll talk through how Relationships can fit your existing structure and improve the success you can deliver to your customers.
Are Relationships just an extension of Account hierarchy? The short answer is, “No.”
We see Account hierarchy as a more vertical problem, where you might want to capture how different companies you do business with relate to each other in the real world. Here are a couple of examples:
- Gainsight US and Gainsight India roll into Gainsight Global
- Gainsight Enterprise and Gainsight Consumer roll into Gainsight Inc.
Now, within each of these entities, you also might have a more horizontal problem of managing multiple relationships. Some examples of this are:
- You sold the same product twice — to two different teams or Business Units at Gainsight US.
- You sold multiple products to the same team at Gainsight US — each of these products has its owns complexities and data, and needs to be managed slightly differently.
- You have multiple deployment projects within Gainsight US — each has to be managed uniquely, and perhaps even scored differently.
- You have multiple teams using the same product instance, and you want to create and manage some higher grouping of these teams.
Technically, it is possible to spin up more and more Accounts to somewhat create this structure but we wanted to give you something better; something more purpose-built to manage such complexities. With Relationships plugging into your existing Account structure, you get a much more robust view of what all’s happening with any given customer. These concepts are compatible and complementary.
Why We Built Relationships for Flexibility
We understand and appreciate the varying nature of your engagements with your customers and how important it is to capture all the nuances needed to truly keep your customers happy and engaged. We, therefore, intentionally gave the Relationships construct a ton of flexibility, so that you can more effectively model how your business creates and manages these relationships. What I’m referring to here is the ability to create different *types* of Relationships.
Let’s say you have two products in your company’s portfolio — Product A and Product B — that you sold to Gainsight US. Based on the discussion thus far, you’d manage these two relationships separately, with a CSM dedicated to owning each product. But should the two products be managed the same way? Do they have the same data being captured? Should they have the same health scoring scheme?
Perhaps not. And this is the difference that Relationship Types capture. It’s possible to create different types of Relationships in Gainsight, and each type brings with it its own layout and its own specific data-set. It could be that it’s useful to track clickstream data for Product A, but not for Product B. Product B could be all about CSAT and proprietary benchmark metrics. Capturing these differences is extremely important.
We are the leaders in what we do not because “we just know this stuff,” but because we have awesome customers with whom we engage regularly to learn, understand, brainstorm, and iterate. Relationships is the perfect example of how we build products around our customers at Gainsight, and how we strive to solve actual Customer Success problems.
