PDA

View Full Version : Clients in different locations


Product User
January 21st, 2008, 02:50 PM
I have one client that has 3 different locations. We have set up 3 accounts in RangerMSP to reflect each location. All 3 of these locations are under one monthly contract with the client.

Is there a way to get labor charges for each office to reflect (update) under one contract inRangerMSP.



* We received this message directly and published it here for the benefit of our community users.

Support Team
January 21st, 2008, 02:53 PM
Each Contract in RangerMSP can be linked to a single Account, so in order for the Charges to be logged under the same contract for all 3 locations, they should all belong to the same Account.

You can do this by managing this client as a single Account in RangerMSP, where each location is represented as a Secondary Contact of the Account. This will allow you to keep information per location (such as name, address, phone numbers and more). You can add as many Contacts you need to each Account. To do this, go to the Account's Contacts tab, and click the "New" button.

When logging in Charges for this Account, you can select the secondary Contact which should be linked to the Charges (next to the Account selection field). This way you can link any Charge to the relevant location (and use this for reports, etc.), and still keep all Charges linked to the same Account, and use the same Contract.

Doron

FunctionOne
February 6th, 2009, 09:08 AM
The logic here is only good if you're not already using Secondary Contacts to represent all of the employees you support within any given company. We add all the employees as secondary contacts - this way we can easily link them to any asset or to any ticket when providing support.

This allows us to track which contact is in possession of a particular asset and also to see who is generating more issues within a company - or simply to be able to quickly identify who to contact regarding a project or issue.

This also points to a stickier issue - some companies do indeed have multiple locations - and the online services doesn't take this into account when assigning a secondary contact (with a different location) to a ticket. The online services link - using Google Maps as an example - only pulls from the primary address.

I think we might want to consider having the ability for multiple locations within a single account - and probably basing this off contacts isn't going to solve all the use cases out there.

Anyone have any ideas on this one?

AN-Tech
February 6th, 2009, 09:18 AM
FunctionOne,

I just posted a similar question about a half hour earlier then you. Might want to follow this thread also.

Support Team
February 6th, 2009, 09:47 AM
Hi guys,

Thanks for your feedback.

I'd like to start by explaining that basically, in RangerMSP each Contract serves a single account. Sharing contracts between different accounts is not possible, so the way to do this is using a single account, and managing secondary contacts. This allows the system to manage both a single-account contract and provides you the ability to manage different people and locations for this customer, since keeping information for each person in the company so you will be able to link them personally to tickets, assets, etc. is definitely useful.

I see your point regarding managing some kind of a new "Location" object which will perhaps allow some kind of hierarchy in order to group contacts under a "location". I have logged your suggestion to our system for further consideration. Thanks for your interesting input.

At the moment, I'd like to suggest a way to do this with the current secondary contacts implementation, which can work quite well for you after all. In order to manage few employees for each location you can still use the secondary contacts, and have the person's name together with the location name. For example, a person called John Smith, working at the New Jersey branch of the company, can be called "NJ - John Smith" or "John Smith (NJ)", or the like. You should copy the location's address to each of these secondary contacts, which is not ideal, however, this will do the trick.

This way you can keep track of both the location + the person name in the same contact record. I believe this should cover the use cases you have mentioned.

As for Online Services - actually as far as I know this does take the secondary contact information when using Online Services. You should just make sure the secondary contact actually has an address defined for it, and also make sure you are using the correct option. For example, when in the Dispatcher window, you can highlight one of the tickets in the list which is linked to a secondary contact, then click the Online Services icon (on the bottom part of the tickets list) - this will open a popup menu suggesting "Account" or "Contact" - you should select the Contact option in order to open the contact's address using the Online Service. I hope this makes more sense now.

Thanks again for your input!

Dina

FunctionOne
February 6th, 2009, 07:58 PM
Thanks Dina, - Just caught the online services aspect for secondary contacts today during a tech training session.

And the Location - Username format is something we currently use in our Mgmt Platform as well so it is a serviceable alternative.

IN the long term having a proper location hierarchy added would be useful.

cforger
February 10th, 2009, 09:46 AM
For consideration: The way we handled this in the past with our custom made CRM/PSA was a fully object oriented entity - An entity could be a person or a company, and you could attach any person/company to any person/company, allowing unlimited hierarchy. . contracts could then be attached to whatever - even contracts within a group of people attached to one location of a company.

We also allowed for "address" type objects to be attached to any of these entities, so you could attach as many phone numbers, fax numbers, email address, etc. as you needed to each entity.

It allowed for nearly unlimited growth of each contact, because you could always plug another entity into the relationship, or another address object, or other object classes. It was always fluid, and a contact record was only as big as it had to be, so it was very efficient in terms of storage, and you didn't have to add fields to a record in a static way - it was just a matter of linking a new object to this current entity, and you had more information storage.

Everything was controlled through a Master Record Table, stringing objects together with linked lists. It's weakness was that database corruption could orphan an entity or object, but with a good transactional DB backend and proper maintenance tools to watch for orphans or corruption, it wasn't an issue for us in 8 years of using it.

Obviously CommitCRM is designed in a different manner, but you may want to give some thought to such a database design for far future expansion - it will allow you to offer an extremely flexible package, and in the end we're all techies who like to have that ability to customize from time to time.

FunctionOne
February 10th, 2009, 09:58 AM
Good points cforger - a relationship system as opposed to a fixed heirarchy would also better allow for things like asset transfer between accounts as well.

We did a similar database approach with an online CMS we put together a few years back in order to support have various entities related to each other in complex fashion.

Good stuff! :)

cforger
February 10th, 2009, 10:03 AM
Yes, but I notice both you and I are here running boxed 3rd party software now, so it's not all that simple. :-)

Ah, if I could afford a programming team again, and have the time to manage them... :-)

lpopejoy
February 17th, 2009, 08:22 PM
cforger, sounds like you should have boxed up your solution and went to market! Sounds cool.

racassel
January 29th, 2012, 10:24 AM
This workaround doesn't seem practical. We track by location, contacts, assets, tickets are assigned to a location. Each location has a seperate contact record. It is a mess for techs and dispatchers to have to remember to log tickets under the primary account with a contract. Seperate contracts on seperate records means seperate bills for the clients and they don't want that. Yikes. We have a restaurant with six locations, six computers and a server at each location and a dozen or more employees each location.

Is there another way to handle this? Any plans in the works? I can't see one huge record with six locations and 50 assets and 100 contacts in one record.

Support Team
January 30th, 2012, 06:43 AM
Hi racassel,

Thank you for you post.

When you want to bill the customer as a single billing entity as you have mentioned, you need all locations to be grouped under a single Account. This Account will be linked to the QuickBooks billing customer. The only way to achieve this is using a single Account with secondary contacts. There is no other way to workaround this at the moment.

I can tell you that RangerMSP has no problem managing many contacts and assets for a single Account. I believe that after the initial setup which may seem cumbersome, once you have all the contacts in place, each containing the branch name in their name, it can become pretty easy to manage. You can always filter the list of Assets and contacts in reports to show only a certain branch, and it's generally easier to manage than it sounds.

I suggest that you give it a try with a branch or two and see how it works for you. The main benefit is that you can still define separate contracts and billing terms for each branch, and they will all be sent to the main customer for billing purposes.

I hope this helps. While nothing is perfect I do believe that once you give it a try you will find it's quite easy to use.

Sheli