|
|
|||
|
|||
|
From the documentation:
Matching Email to Account - Note that the matching is performed based on the full email address of the Account, and not by the domain name alone. This is because clients may be using generic email addresses (such as Yahoo®, Gmail®, etc.) and the system cannot rely on the domain name itself. If one of your clients has many possible email addresses, you should add each as a secondary contact record (in the Account Contacts tab). This has the added benefit of ensuring that your CommitCRM Contacts are more complete. Just wanted to throw in my $0.02 on this... we need to be able to set up a default contact for each CommitCRM account which will be used if there is no exact match on the email address of the incoming email/ticket (this option should be selectable at the account level). In fact, we should be able to tell the system no matter who generates the ticket, all communication should be redirected to a specific contact (if Sue is the IT manager and Joe creates a ticket, Sue should be notified of the ticket process in case she wants to act on it specifically). My suggestion is simply to add the functionality to tell CommitCRM that if a ticket is generated though email and the contact does not already exist, use a default contact (this should be selectable at the account level). There are a number of benefits to being able to assign a default contact including accountability, ease of ticket tracking and simplicity. Under the current setup, if the client has 30 users in their environment, we need to add and manage every user in our database just so we can properly track tickets. Also, given that CommitCRM does not map very well to outlook/exchange contacts fields (this is a big problem that really needs to be addressed soon -- we are losing phone #'s, email addresses, etc. due to the incompatibility of fields between CommitCRM and outlook...), using multiple contacts in CRM causes problems in the sync process. On this last point, we should also be able to select which accounts are exempt from syncing with outlook (I don't want a list of ALL the users in EACH environment in my outlook contacts...). OK-- thanks for reading! //ray |
|
|
|||
|
|||
|
Ray,
When you setup the email connector you specify an address that CommitCRM will default to in the event it can't match up a user in your CommitCRM records. For example, if you're asking clients to email requests to Support @ then when the email hits the 'Commit' email queue and can't find a matching record it will then be redirected to a secondary address of your choosing. Commit, and I, advise a distribution group email to all your support staff i.e. support-internal@commitcrm.com. This way when a support email fails to auto-generate a ticket it will get directed to all your team or those you specify in the distribution list. We find that the matching of phone number fields in CommitCRM can use some improvement, but with that said here's what works for us: For the account record we use the company decision maker and in this we input the main company phone and main company fax, domain name, address and that's it! Why, because when it syncs to Outlook it syncs as the company name, if I'm on my PDA and want to dial the decision maker I want to start typing their name, not the company name. So we ALWAYS create a secondary contact for the decision maker with their direct dial phone, mobile and email...we also create secondary contacts for each and every contact at the company with the same information. The above solution works very well for us. We never tell our clients you must contact us via phone, or via email, or via CommitCRM interface or via an email to support@xyz.com we always tell them whatever way is comfortable to you please contact us that way. So if a client has an AOL address, a Hotmail address, a Google address etc. etc. then I'd advise they call or use the web interface. We have integrated the new MSP interface with our SPAM platform and have yet to start testing on our MSP solution, this will be next week. Hope this helps Ray, Brian Williams Advantech NW |
|
|
|||
|
|||
|
Hi Guys,
Just wanted to point out that RangerMSP Email Connector uses an "exact email" identification. This allows you to add also "generic" email address (such as yahoo, gmail, etc.) to the customer's account or to any of its secondary contacts. Customers can then send an email from any of those email address, including the free ones (gmail and the like) and RangerMSP Email Connector will still find the correct account and will automatically create a new service ticket linked to account record that was found. My 2c Sherry |
|
|
|||
|
|||
|
>> In CommitCRM you can choose to NOT sync secondary contacts.
The problem is that this setting is an all or nothing deal. Not sure how you do it without having your secondary contacts in your outlook/phone... personally, I don't know how I could function without having the detailed contact info (i.e. cell phone #'s, email addresses, etc.) for key employees with me in the field... The only way I could see this working is if we kept the secondary contacts in CommitCRM completely separate from the outlook contacts... in just typing this, it has occurred to me that maybe this is the best solution anyhow given that the sync of contact details between CommitCRM and exchange/outlook is pretty horrible (mainly due to the fact that the fields don't match up very well between the two). That said, we SHOULD be able to individually exempt specific accounts/contacts from sync-ing. >> Just wanted to point out that CommitCRM Email Connector uses an "exact email" identification This wouldn't be a problem if CommitCRM would allow us to add multiple email addresses to secondary contacts. Couple of points: 1) None of our users use generic email addresses (i.e. yahoo, gmail, etc.) -- we deal strictly with businesses and they ALL have their own domains. 2) If a user does want to have the ability to send from different email addresses (even yahoo, gmail, etc.) then we currently need to set up multiple secondary accounts for the same person which then gets sync-ed to exchange/outlook as separate contacts for the same person... very ugly! On this, we should be able to add multiple email addresses in each contact (outlook currently allows 3). 3) We have clients with as many as 100 persons.... does this mean we need to add ALL 100 persons to the secondary contacts list (currently, yes) if each person is allowed to open a ticket (which will happen with clients that have full help desk support contracts) -- how much time are we going to waste managing this list... this process is supposed to save us time, not make us work harder! From my perspective, the connector should pull in the email, see if there is an exact match (including accounts with yahoo, gmail, etc. addresses), if there is, proceed from there. If there isn't an exact match then it should select a default contact (maybe even the account itself?) under the domain and proceed from there. We should also be able to "black list" certain domains (i.e. yahoo, gmail, etc.) which will not be processed (as the system currently does). These should be simple changes that would yield great benefits! thanks -- //ray |
|
|
|||
|
|||
|
Hi ray,
Thanks for the additional feedback on this. You have raised some very interesting points and suggestions. Moving from "exact email" matching to a domain based email matching has its benefits and also some weaknesses. I can tell you that we have considered various solutions for the domain issue at the time, and for different reasons and considerations we decided to go with the current solution of forwarding un-recognized emails to your internal support email address. This assures that no email is missed, and it prevents spam emails from opening numerous tickets in the system. As we do receive customer feedback requesting to fine-tune the email identification engine we may update it in the future. I agree that this can yield great benefits, on top of the already great benefits the current email-to-ticket feature provides. Sherry |
|
|
|||
|
|||
|
We have tried and tried to make the email connector useful but have finally come to the conclusion that in its current format, it is useless to us.
From the documentation -- "New Tickets are ONLY created when the sender's email address matches an Account or Secondary Contact in your CommitCRM database". Simply put, it is not possible (or worth our time) to track and enter each and every email address from each and every contact at each and every client... to ask us to do this is simply insane. We need a system that is consistent and saves us time. The thing is, the solution is quite simple: the connector should pull in the email and see if there is an exact match (including accounts with yahoo, gmail, etc. addresses), if there is then proceed from there. If there isn't an exact match then match the domain name on accounts. This may require an added field which lists all (unique) domains that the account is responsible for (clients may have multiple domains). If there still is no match then there should be the option to set the connector to either delete the email, forward it to an internal email address (as it currenly does although we have yet to get this part to work) or process it under a specified default account. Finally, we should be able to "black list" domains at the connector level as needed. Sorry to be so strong in this email however, we have wasted time on this and it just seems that this would be so easy to fix... thanks -- //ray |
|
|
|||
|
|||
|
ray,
The way we see it is that the entire idea of using a central CRM system such a RangerMSP is that you have every piece of information logged into the system. You don't need to track secondary contacts only for the email connector, you should use them so you can track, assign and link secondary contacts to trouble tickets, link them to assets, charges, history notes, documents - everything. A secondary contact is not just an email address, it's much more than this. Using secondary contacts lets you track your entire activity at a much more personal level and not just at the customer company level. Using secondary contacts you'll know who said what - who complained about each issue, who did your technician talk to, who is responsible for what at your customer company etc.. This provides numerous benefits and this is the recommended way to go and to gain competitive advantage and build personal relations with your customers. The fact that you need to log secondary contacts for the email connector to identify the customer is true. Thank you for the input on this and we may add some more flexibility to this in a future release as we can understand how it may help. Just remember that there are many benefits for tracking and logging secondary contacts for your customers inRangerMSP. Neta |
|
|
|||
|
|||
|
An opportunity to make this product better (i.e. usable) is being missed here. I get that you want CommitCRM to be the central place where everything client related is tracked yet the way the connector works, it’s causing us (and I’m sure other CommitCRM users) to do quite the opposite.
We are a tiny outfit with about 30 clients and all told, interface with about 900 users. What makes people think that we have the resources (or the desire) to track each and every email address for each and every user at each and every client site just because if we don’t, CommitCRM will not accept a request for service/assistance? This is just crazy… on top of that, what happens when a request for service comes from the CEO but they use an unknown gmail or hotmail account that they have. How do we expain to them that we didn't get their request for assistance becuase they didn't use an email account that our system recognized.... that is most certainly NOT a conversation I ever want to have! Again, the way the connector behaves makes it useless for us because we don’t have a way to track 100% of all the requests in ONE PLACE! I can tell you first hand, when you introduce exceptions into a system, things get lost/dropped… if you do that enough times, you start dropping clients – quite the opposite of what a CRM system is supposed to do! Why this is even an issue is beyond me. The proposed modifications do nothing to stop anyone from using the system the way you propose (i.e. tracking each and every contact). The edits would probably take someone less than a day or two to implement and the benefits are enormous. Simple solution: 1) Incoming email is checked for an exact match if there is then proceed from there using the exact match 2) If there is no exact match then match the domain name on accounts. This will require an added field which lists all (unique) domains that the account is responsible for (clients may have multiple domains or no domain at all) 3) If there still is no match using domain name, then there needs to be the option to have the connector either: a. Delete the email b. Forward the email to an external system (as it currently does) c. Process it under a specified default account. 4) Allow us to "black list" certain domains as needed Again, the point is that all requests need to be accepted by CommitCRM and acted upon regardless of the status of the requestors email and we should not be required to keep our database 100% accurate/current, which is simply impossible to do anyhow. //ray |
|
|
|||
|
|||
|
ray,
Thank you for the additional feedback. As I mentioned earlier, what you suggest makes sense and will probably help others. It has already been logged for further evaluation. I can understand why you don't always want to or can create secondary contacts for all of your customers' employees. It's just better to have as many secondary contacts as possible to keep your CRM database as accurate as possible. Neta |