Single Company w/ Multiple locations, separate from contacts
Apr 4, 2017 8:52 PM
My business has many brick-and-mortar retailers that sell our products. Some of these companies have more than one location. Some of them have a different contact for each location, some have a single contact for all locations, and some are a mix of both.
Right now, the workaround is to create a company for each location (which doesn't work well in "single contact for multiple locations" scenarios). Ideally, there would be a mechanism to attach some sort of "location object" to companies and, then, be able to attach one or more contacts to those location objects. I can't really speak for anyone else but this sure seems like it would be a desirable behavior for many use cases beyond our own.
In a perfect CRM (much like perfect bookkeeping software) I think the ultimate goal is to have the structural components of the software be able to mirror the real world relationships as closely as possible. Unlike object-oriented software design, abstraction is very much the enemy in this endeavor. I would like to have one of my retailers (represented by a company) which operates one or more physical locations (represented by the proposed "location object") to which I can attach the people that we actually call on the phone (represented by contacts). I think we can safely assume that every company has at least one location but a location could have any number of contacts (including zero contacts) and any contact could be our POC for any number of locations, potentially even locations across more than one company. (This structure has the added benefit of allowing us to, for example, easily pull up a report of "everybody I need to contact to run some sort of promotional rate or in-store marketing campaign in Concord, CA, regardless of company or physical location of the contact.")
If the structure was implemented in this way, we would use companies only to represent actual companies, incorporated entities. They could still have parent and children companies, as they do now. We would add "locations" that would each be attached to a single company and then contacts would attach to one or more locations, instead of to a company, itself. The attachment of a contact to a location is, itself, still a bit of an abstraction (as it could represent either "where that guy's desk is" or "what that guy is in charge of") but I don't think this particular abstraction is going to cost us anything in usability or efficacy. If the ambiguity of that attachment proves troublesome, a boolean flag could be included with the attachment to indicate "contact's physical location" or something along those lines. Again, this assumes that any contact can be attached to any number of locations, potentially across companies.
Imagine this scenario: We have Company A with subsidiaries Company B and C. (A is the parent company of B and C in HotSpot CRM, so far so good.) Now imagine that I have a contact: an account manager who works for A (and is physically located at A's headquarters) but manages multiple retail locations for B and multiple retail locations for C. Ok, it's already a ludicrous mess in HotSpot CRM. How do I tell what address to use to ship something to the account manager, versus to one of the stores he reps? Let's make it worse. Imagine that I have another account manager that handles pilot store locations for B and C. (HotSpot CRM is now actively working against my attempts to organize and describe these relationships.) I need to talk to the account manager in charge of B's Fort Worth, TX pilot store (as opposed to B's (or C's) Fort Worth, TX mainline store). This scenario illustrates a scenario where I would actually be better off keeping this information in a spreadsheet...all because the structure of the CRM is abstracted too far away from the real world relationships.
If you've kept reading this far, I thank you for your time. Truly. (This post has gone on way longer than I intended!)