Overcoming Account Hierarchy Challenges for Segmentation
Learn about how to get a handle on managing Account Hierarchy in Salesforce. You have invested a lot of money and time enriching data from multiple data sources and now need to map all of that to align with your Go-to-Market Strategy.
Introduction
Bala: Hello everyone, we are happy to be here again! My name is Bala Balabaskaran and I’m the co-founder of Fullcast. I’m playing the role that Darmesh usually plays on these chats.
Today, we’re going to talk to Tyler Simons, who works at Fullcast and heads up our customer success team. He has been involved with today’s topic, account hierarchy challenges, for quite some time. We’ve worked on some epic projects related to account hierarchy, so it’ll be an interesting discussion. We’re going to dive into the specifics of some of the practical problems that we encounter in sales, which is mostly exception-driven and there’s a lot of edge cases that come about as it relates to account hierarchy. We want to dive into that and look at why it’s such a challenging topic and why there is no simple answer to this.
Tyler, before we jump in do you want to do a quick introduction?
Tyler: Sure! My name is Tyler, I head up the customer success team at Fullcast. My background is pretty wide ranging; account manager, account executive, managing SDR teams, and being an SDR. I’ve had a wide range of sales jobs — I was a real estate agent at one point. I’ve been doing sales ops at Fullcast for the last two or three years now and helping our customers out with a wide range of problems in either Salesforce or on the sales strategy side.
[2:56] What makes account hierarchy so challenging?
Bala: Cool, let’s get into the topic of account hierarchy or account families. What we mean by that is a group of entities that are related to each other because of their relationship either from a legal perspective, an ownership perspective, or even a relationship standpoint… How you might want to think about a family or a group of accounts in the same way when you’re thinking about segmentation, hierarchy, routing, everything that we do from a revenue operations perspective.
From your perspective, what have you seen that makes this problem hard? When we talk to people, they say, “I’m just going to go to a data provider like D&B and they’re going to give me the hierarchy and life’s good.” But it doesn’t quite turn out that way all the time! We wanted to get your perspective on why you see this as a challenging topic.
Tyler: I say the number one reason why it’s challenging is all this stuff is dynamic, it is always changing, and it comes back to keeping data up to date and clean. Companies are merging, getting acquired, divesting, their information is updating constantly. You think about these changes being constant…it’s very hard to keep that stuff up to date in the CRM. That’s one way to look at it.
Another problem that you usually see arise is inconsistent matching. This goes back to the data problem, but D&B or any of the other sources, like ZoomInfo, all of them out there rely on matching to data in your account. If that data is not there, then they’re making a guess or they’re even matching to the wrong entity. If that’s incorrect then your hierarchies are going to be built incorrectly because you’re just matching the wrong data.
Some of the other things that don’t really pertain to data per se, but also cause issues is how you think about accounts. You could be selling to franchise locations or branch locations, — like the Bank of America down the street — and thinking, well, do we sell to that? Do we not sell to that? A great question would be: Is it a sellable entity? Defining accounts, and if that definition isn’t locked down and you have a lot of different accounts in your system that could be sellable entities and could not be sellable entities, that plays into that fact.
Bala: The other challenge we always hear about is that there are there are different types of relationships between entities in the corporate group. The clean definition is 51% ownership of an entity makes it part of the family in a sense, but then you encounter all kinds of other relationships. Coca-Cola and bottling companies, for example. The bottling companies are not necessarily owned by Coca-Cola but have a strong relationship in terms of the technology buying or some buying pattern that may be associated with that. Advertising agencies and car dealerships… these are all interesting relationships, just like you brought up with Bank of America. Are these sellable entities we would sell to? And if we did sell to them what is the relationship? Is it an agency relationship? Is it a dealership relationship? While they may not be legally related, they could be related from your point of view.
The other great example is government. The way that you organize government is not necessarily how the data providers would. That’s an interesting challenge.
[8:02] At what levels in a corporation do you make relationships?
Bala: Now, when you talk about relationships, do you get down to departmental levels? Let’s say, take a large corporation, do you create an account within the CRM for departments or divisions within a large corporation? How have you seen that tackled? Do you stop at the at the legal entity?
Tyler: Both ways! It comes back to this question that you’ll have to ask yourself a million times when you go through setting up some sort of account hierarchy policy: How do we sell? Who do we sell to? Who is that?
We have customers that have sold to that department level. Microsoft is a great example. Between Microsoft Office and the Xbox division… they are all different divisions that we created accounts for. They are in the Microsoft hierarchy because they sold to each of those departments or divisions. A normal SAS business probably isn’t going to sell into each of those departments because they’re not the main buying center. They’re not going to need to create accounts there and have them in the hierarchy. They can have the one main Microsoft location or some of its subsidiaries as well.
Bala: You brought up an interesting point about buying centers. That’s another dimension that people look at from an account hierarchy standpoint: You may have a large bank, but the procurement centers for, say, IT services or the procurement center for HR services may actually be in specific locations. It might not be at the headquarters, but it might be in other places, so reorganizing the hierarchy to support that buying center notion is another pattern that we’ve seen.
[10:15] Can account hierarchy maintenance be automated?
Bala: I guess the reason for calling out all these scenarios is that there’s not a slam dunk answer. You can’t just go out there and buy the account hierarchy — you have to adapt it to the way you sell and how you reach out. And of course, what we’ve seen with our customers is that a lot of them simply have to maintain this in the CRM manually. And that is super painful! It’s painful because it’s very volatile and you could make mistakes.
What is an approach to automation? How can we automate this creation and maintenance of account hierarchy? Can you talk to me ideas around that? (And, of course, here is a shameless plug for Fullcast; we do have an automation that does this.) But what are some of the options that are available?
Tyler: Yeah, the majority of people manually do this. They say, “Hey, can you link these two accounts together?” I’ll go in and edit the Parent ID field in Salesforce find the right account, link them up. Usually when that becomes a real burden is when everyone moves to the first step of automation maturity, I guess. We’ll make a maturity model for this. And that is really implementing some process builder or flow in which an account is edited or created and has core information that you can use to build the hierarchy and then you go to find matches. There are a lot of inherent problems in keeping that hierarchy up to date, but that’s the first level of automation that gets put in place and a lot of people go that route because then it offloads all that manual lookup.
Some of those problems that come up are mergers and acquisitions, what happens when an account is deleted… there is a really big scenario where you have multiple levels of hierarchies and if you have the global ultimate, which is the topmost company at the tippy-top, and then you’ve got the next level down and then another level down… If that account exists but you’re still missing the one in the middle, if you use this this half step of automation, they will always link up to account A, the global ultimate, even when you insert B.
It’s important to think when you take the next step in maturity, every time you insert an account or update an account that’s in a corporate family, you actually need to completely blow up the entire hierarchy and rebuild it again. It’s got to get the right structure in place.
[13:24] Why is it important to have accurate hierarchies?
Bala: Why is not having the right structure a problem? In your example, you might have a company that has a global headquarters, regional headquarters, and then you might have subsidiaries or branches or something that that rolls up under each regional headquarters. If you don’t have the regional headquarters account in your system, you will end up linking branches in Europe with the headquarters account. Why is that a problem? It’s related to the account, it’s related to the family, so we solved that problem. Why is not having the right hierarchy a challenge?
Tyler: The real reason that you’re going to care about this, and the real reason you have hierarchies, is so that you can assign an entire corporate family to one strategic rep or enterprise rep. “Here, Mr. or Mrs. Enterprise Rep, you are going to work the Adobe corporate family.” But in some cases, you might make a decision where the US corporate family belongs to a US strategic rep and the Europe corporate family of the same “thing” belongs to a European rep. If you have all these accounts linking up to the global ultimate, whoever gets the global ultimate is probably going to get all of the accounts. If you have the global ultimate in AMER and all of these EMEA branches and subsidiaries are linked to the AMER account, you’re going to assign all those to the AMER rep.
The example I love to use is the Adobe one: Adobe owns Marketo, and Marketo owns ToutApp. (ToutApp is kind of part of Marketo now, but I still like to use the example because it’s pretty clear.) If ToutApp is attached to Adobe, and let’s say you didn’t have Marketo in the system at the time, you’ve now got this hierarchy of Adobe and ToutApp underneath. Marketo enters the system and links to Adobe, but ToutApp, in your first maturity example, still stays linked to Adobe. Do you assign Adobe to a strategic rep to handle, including all of its corporate subsidiaries? That’s fine. But what happens when you want to break out Marketo and assign it to somebody that’s based in San Jose? You want them to work and go deep into Marketo while Adobe belongs to somebody else. Well, when you assign that Marketo corporate family over to that person, guess where ToutApp is going? Not with Marketo! It’s going with Adobe, and that creates a problem. Who works what? The data will be inconsistent.
Bala: That’s definitely the case, and we talked about some examples of bottling companies, franchises, and scenarios like that. In those kinds of situations, you almost have to create a custom definition of a hierarchy in the way that you are selling. Because, say you’re selling an IT solution to McDonald’s. Every branch of every franchisee is not going to buy separately from you; you’re going to sell to the corporate office. When you do that, of course, you don’t want to treat all of the franchise accounts as separate entities in the system. You want to link them all to McDonald’s and create a family even though legally they’re not owned by McDonald’s.
That hierarchical structure we talked about, the example with government, and typically most ways that you sell, you divide it by local, state, and federal. But that’s not how the hierarchy shows up from most providers, so you have to create it. When you do these custom hierarchies that are set up to for the way that you sell, you would have to do that manually. But is there automation that can be used for that purpose? Or is it all manual?
Tyler: It’s always manual! No, sure, you can automate it if you can figure out the core information to use to link it. A great example would be, let’s say they all have the same URL, same domain name, you could use the domain name as a way to link all of these franchises, all of these locations up to a headquarter location. Even though you go into whatever data source you have, and because they’re based on the legal structure, they’re not having them all linked together. They’re all separate entities and you don’t see them in the corporate family.
[18:54] How do you think about segmentation in mergers and acquisitions?
Bala: The other interesting example that we’ve seen, and this is again a challenge from a segmentation perspective as well, is mergers and acquisitions. Mergers and acquisitions can occur any time during the year.
Let’s say company A is acquiring company B and you have them assigned to two different reps. When a merger occurs, there are a couple of challenges putting that information into your system. The first one is an announced merger between two companies takes a whole bunch of time before it actually materializes, but companies want to start getting discounts, family discounts, the customers want to be treated a certain way. Even though the legal hierarchy things haven’t settled yet, because maybe the government hasn’t approved it or whatever the case is, when you’re selling to it you might sell to it as a group. That’s what I’ve seen custom-created for those kinds of scenarios. The opposite of that, even though a merger has occurred, like your Adobe and Marketo example, you might still want to treat them as two separate families.
In terms of in terms of your setup within the CRM, as well as how you think about segmentation, is it important to make sure that your segmentation is always reflected in the data? Or could you have the hierarchy of Adobe-Marketo-ToutApp in the system but then your assignment rules are configurable enough that you can break them apart without having to have that be reflected in the hierarchy?
Tyler: Yeah, you would need Fullcast to do that!
Bala: I mean, do you bring Marketo to the tippy-top? Or do you still keep the hierarchy… from a reporting perspective, you have it, right? But from an implementation perspective you can think about it differently. The reason why I bring it up is because I see a lot of people merging the two ideas and that causes problems from a reporting perspective as well as from a segmentation perspective. I just wanted to get your thoughts on where you’ve seen that being done correctly.
Tyler: It’s always good to have it all linked, to your point, because from a reporting perspective you can report on many different things; what’s the total ARR in this entire corporate family in Salesforce or if you’ve got a BI tool and all that stuff. But if you’re keeping that decision separate, that’s really going to be dependent on your go-to-market plan. And you’re going to need to make a decision at that point: Do I want that for all strategic or enterprise accounts? Do I want to just only bring over the corporate family for strategic and enterprise? Or if it’s both of these accounts, Adobe and Marketo are both enterprise-level accounts. Do we separate them? That’s a planning decision and your planning tool should be able to accommodate the hierarchy within that, be able to break those apart, and put them into the appropriate territories based on how you treat them. It’s a decision that needs to be made at the go-to-market planning time.
Bala: And it’s important to separate these two things, because if you if you merge them then your reporting gets impacted. It becomes a little bit more rigid, makes sense.
Tyler: The decision that really needs to be made is when you want to think about breaking up a corporate family in your CRM not related to territories. Or thinking about holding companies and entities that sit at the top that aren’t really entities that you would sell to. You would actually want to report on things broken up. The classic example is Berkshire Hathaway… they own a bunch of different accounts, and you probably don’t want to see BNSF as a part of some other entity that that Berkshire owns. You would want to see those as two separate entities in your CRM as you are reporting on it. But that’s the decision; do I break this hierarchy up or not? It’s not a planning decision in terms of pointing things to different territories.
[24:06] What are pros and cons of data sources available today?
Bala: I know a lot of people ask us this question: What’s the best data source to get a starting point in terms of hierarchies? What are some of the pros and cons of different data sources you have seen on the market today?
Tyler: I would start with figuring out where you’re selling – are you selling in the US or globally – and finding a third-party data source that supports it. If you’re just selling to the US, find somebody that’s really strong in the US. If you’re going global, then find a source that has got global coverage.
The one question I would ask your third-party data company is: Do you have hierarchy keys? Like at D&B, they have these nine-digit ID called the D-U-N-S Number and they all relate to each other in terms of hierarchy. One account will have its own nine-digit ID, and its parent account will have a nine-digit ID that points to another one in D&B’s instance.
Those are the two things I would start with. Now, where do we usually see customers go? I know that a lot of people that sell in the US have ZoomInfo, which now has hierarchy keys that you can use to build hierarchical structures on. However, as you see people go on a more global basis, they point more towards D&B. The reason you would want to look really deep into that would be D&B’s partner networks that are separate data networks, say in Japan, where they plug D-U-N-S Numbers into their data so you can build one consistent corporate hierarchy.
[26:51] What challenges are involved with database matching?
Bala: We talked a bit about the matching problem; how does the third-party data company identify an account in your CRM and link it to the specific entity that it might relate to in their database. We’re essentially matching what’s in your database with what’s in the data provider’s database. Can you talk through what that process is, why it fails quite often, and what are some of the challenges there?
Tyler: The reason that the process fails is that you’re having accounts being created with terrible data. A lot of these providers will match based on name, some by country, and then one other piece of information, whether that’s domain or city. Those are the core pieces of information. Let’s say you don’t have Picklists turned on in Salesforce and you misspelled “United States” — it could match to the wrong account. Or you’re just straight-up missing the domain; it’s not going to match at all. Or it’s misspelled and those are the problems where you see mismatching between your source and data that’s in the account, and then once it’s matched and it enriches your account, that account is very wrong. Then it’ll just continue to make things worse in terms of building your hierarchy incorrectly. It might not match to a global ultimate; it might match to a different corporate family because it’s matched differently… there’s a lot of different situations there.
Bala: Yeah, and sometimes when you create these accounts, especially if you have automation that comes directly from a lead form and you’re basically creating an account without filling in these basic pieces of information that’s needed for matching, what tends to happen is either the account is not matched and ends up in the wrong territory with the wrong rep or it’s linked to the wrong place in the hierarchy. Those kinds of challenges make it really hard to build the automation if the matching is not done correctly. Matching is one of the main reasons why I see automations fail. How do you handle situations where the accounts are not linked? Ideally you want to put some process in place to identify it and fix it; what are some of the things that you’ve seen that people use to catch these exceptions and fix them in a timely manner?
Tyler: The best method I’ve seen today is a little system called “flag for review”. (I’ve made that name up.) Essentially, your reps are in the CRM day in and day out, and trust me, they’re paying attention to this stuff. When it’s incorrect, they know about it. Just giving them the simple option to click a button to flag the account for review, to bring that to somebody’s attention so they can dig in and go “What’s the problem here? Did it match incorrectly? Is the information incomplete?”
It’s manual — you’re never going to get away from doing any manual work, it’s never going to be fully automated — but at least you’re leveraging somebody out there seeing this stuff and winnowing down into specifics so you’re not looking at all 400,000 accounts in your system to determine what’s really the issue there.
[32:11] How do you decide to handle segmentation changes?
Bala: Let’s say a company A acquires company B, but you decide you don’t want to disturb the territory or the coverage that you have on those accounts. You want to keep it the same way for the current fiscal year. Is it a good choice to keep your segmentation intact in some cases? Or do you want to update that data right away and move the accounts? How have you seen that play out and what are some of the pitfalls that you’ve seen?
Tyler: This comes back to the earlier conversation where we talk about conflating the hierarchy and the CRM, or your plan around segments. I am of the opinion to update the data as soon as it’s available. That means update the corporate family, whatever there is to update, just get it up to date in the CRM. But the plan should stay in place unless you’ve made a policy decision around that being an exception. That’s a conversation that sales ops and sales need to have around what is acceptable for to update. Everyone’s policy on that’s going to be different and it’s a conversation you’ll need to have. Once you have that policy in place, and let’s say it’s every quarter you’ll review mergers and acquisitions (which your CRM is already up to date with), you can review those quickly and make decisions around it. Stuff may need to move, stuff may need to be split up, whatever that the changes need to be made.
Bala: Any other advice that you would give to folks that are looking to get this account hierarchy problem in order? What are some of the successful things that people have done, other than automation and the tools that exist around this? From a process practice policy perspective, what are some of the things that you’ve seen successfully done there?
Tyler: Start by going back and watching the chat we had about building an account data policy. Get an idea of who you sell to and what needs to exist in the system. You need to get a grasp on how you’re creating account data, how it’s being enriched, and so on. Start there before you start automating or anything else.
Bala: The fundamentals.
Tyler: Yeah, fundamentals are important! Back when I was playing baseball, I would hit 200-300 balls off a tee. The fundamentals are really important. You start with that policy, then you need to make a decision around how you will build the hierarchies. Do we want holding companies to be included? Do we not want them to be included? Things like that. Then you go from there and you can build either your own automation, you can continue to do it manually, or you can look at other solutions, like Fullcast, to do it for you.
That’s where you end in terms of just getting your data right in CRM, but the follow-up to that is asking how you use this hierarchy, or these corporate families, in your planning process. That’s a whole discussion that you have either every year, every quarter, however often you do your planning.
Bala: The other thing I want to call out is that we have a whitepaper that goes into quite a bit of detail on all the stuff that we talked about. People find that useful if you are watching this and you want to get ahold of that whitepaper, feel free to ping us. Just send an email to sales@fullcast.io and we’ll get that white paper to you. It goes into quite a bit of detail on all the use cases that we just talked about. If you’re in need of a good read and you enjoy that kind of thing, feel free to email us.
Tyler, thank you for chatting about this area that challenges a lot of sales ops organizations. There is no silver bullet answer, there’s just proper structure and maturity that you can build, automation that you can build, to deal with this. I appreciate you taking the time to walk us through it again. Tyler, Darmesh and I are available if you have any questions or want us to share some of the experiences that we’ve had dealing with this problem. Thank you and take care!
