Real-World Relationships Between Companies, Contacts, and Locations
In a theoretically ideal/perfect CRM, the data that the CRM contains would be a perfect mirror of the relationships/events that exist/take place in the real world. That is to say, the CRM's data/structure would be abstracted from the real world as little as possible or, in the case of an idyllic CRM, would not be abstracted at all.
Of course, No CRM is ever going to be perfect for every use case (as every business's use case is going to be at least slightly different) but there is one major abstraction present that, if removed, would enable HubSpot CRM to serve the vast majority of use cases much better than it currently does or, in some cases, serve those use cases at all.
IMHO, HubSpot CRM needs to treat companies, contacts, and locations as three completely independent top-level objects that all have many-to-many relationships.
- A company should represent an incorporated entity in the real world. In HubSpot, any company should be able to have any number of child companies and any child company should be able to have any number of parent companies. A company should be able to define any number of contacts as POCs for that company.
- A contact should represent a human being in the real world. In HubSpot, any contact should be able to have any number of companies for which he is listed as a point of contact and (independently of who he is a contact for) have any number of companies defined as employing him (every contact doesn't actually work for the company/companies he reps!).
- A location should represent a real-world physical place. Any location should exist as a top-level object (as opposed to being an attribute of a company). Any location should be able to define any contact(s) as POCs for that location (and any number of contacts. Any location should also be able to define any number of companies as its owners/controllers.
This would be reasonably trivial to implement from scratch (make ALL the junction tables!) but, I imagine, it will be significantly harder to modify the existing code. That said, the existing structure should map to the new structure perfectly, so it should be entirely possible to migrate existing accounts to the new structure without user input.
My Use Case
Like many other others, my business manufactures products that we wholesale to retailers. Our relationships with these retailers varies from simple (single incorporated entity/single location/single contact) to complex (multiple incorporated entities/multiple locations/multiple contacts) and, right now, there is no practical way to implement my business's sales operations in HubSpot CRM.
(I am aware of the Parent Company/Child Company "workaround". That workaround does not provide the functionality my business needs.)
As an example, my business sells product to an LLC that has four retail locations around Texas. We have a single point of contact (the LLC's owner) that we go through to get product into three of those stores. Each of those three stores also have a store manager that we talk to for setting up in-store events. For the fourth store, we go through the store manager for sales and in-store events. If I was going to try to implement that in HubSpot CRM, my sales people would have to check all five of those companies for communication history every time we want to interact with this one LLC and there's no way for me to make crystal clear what person they should be contacting. That's bonkers and, more importantly, far too messy for day to day use. We just aren't going to do that. My sales guys are fantastic...but that workflow is not reliable enough for me to use it for my business. This isn't even an uncommon use case for my business. Off the top of my head, I have at least ten companies that are set up like this.
Simpler use cases don't really even need "companies". A lot of small business really only deal in locations and contacts, like a residential landscaping company or an independent residential snow removal service might, this new structure would work fantastically for that use case, as well.
When implementing this new structure, please consider that any of these top-level objects could have their own unique properties. Companies, Contacts, and Locations could ALL have their own websites, phone numbers, etcetera regardless of their relationships.