One of the things I asked SF about early on was how we get customer emails into the system. They said we needed to copy-paste the contents of the email into SF. After realising they weren't joking (!), I was pleased to hear about the Outlook plugin, which deals with many of my concerns.
But.. this still relies on a human being to shove an incoming email into the system. So if for example a customer emails us, and we're short-staffed, and the email doesn't get dragged into SF for a few hours, it negates a lot of the benefits of the queuing and auto-escalation systems.
So my curiosity is whether anyone has put together, or is considering putting together, an app that will poll a mail server (for us, it would need to be via IMAP), pull incoming emails into SF, and then file them in another folder. The benefit then is that emails go directly and almost immediately into SF to be handled appropriately.
Is this feasible given the way SF works? How would emails be pulled in? How can we ensure emails that are pulled in are dealt with appropriately by support and sales personnel? My sense is that for this to work all emails would need to be shoved into SF as Cases, to ensure they were seen and handled by customer service people. Would that cause problems?
One of the things I asked SF about early on was how we get customer emails into the system. They said we needed to copy-paste the contents of the email into SF. After realising they weren't joking (!), I was pleased to hear about the Outlook plugin, which deals with many of my concerns.
But.. this still relies on a human being to shove an incoming email into the system. So if for example a customer emails us, and we're short-staffed, and the email doesn't get dragged into SF for a few hours, it negates a lot of the benefits of the queuing and auto-escalation systems.
So my curiosity is whether anyone has put together, or is considering putting together, an app that will poll a mail server (for us, it would need to be via IMAP), pull incoming emails into SF, and then file them in another folder. The benefit then is that emails go directly and almost immediately into SF to be handled appropriately.
Is this feasible given the way SF works? How would emails be pulled in? How can we ensure emails that are pulled in are dealt with appropriately by support and sales personnel? My sense is that for this to work all emails would need to be shoved into SF as Cases, to ensure they were seen and handled by customer service people. Would that cause problems?
We have an issue with duplicates in SF.com, primarily with leads & contacts. For those of you that purchase big lists and mail to them (in which case some of the names you purchase MAY already be in SF.com as leads or contacts), how do you go about getting that information into SF.com without creating tons of duplicates?
Does anyone else have an issue with the way the Leads module is set up?
Let me start by saying that i am not a developer, but i'm trying to help our team figure out something. Basically, we'd like to roll out Price Books to our sales team, but we want to be able to export the product/price sheet into something like Excel or Word so that our reps can use the information in a proposal, RFP, etc. Does anyone have suggestions on how to do this, or who we could hire to provide this type of functionality?
If anyone out there has a large salesforce.com account with a few duplicate accounts it would be great if you could test out my account de-duper. The current beta version does not do any merging of the accounts, contacts, oppertunities yet but the first 2 steps do work and they will show you all of the duplicate account names in your setup and will allow you to export those duplicate names to a CSV file.
The idea of the tool is that it uses a "Replace List" to clean account names by replacing things like "&" and "+" with "and" and will trim off known suffixes like "Inc." You can even force a more unique search by including the billing city or any other custome salesforce.com account field. This way I.B.M. Inc. in New York will not match IBM Corp in Chicago, but, if the city was not used they would match.
You can grab the setup from the URL below and you will need the .NET framework installed in order for it to run.
Here is a screen grab of the first and second page. You can force master accounts on the second page by just right clicking on the account name.
I'll be dropping up some sample code later on to show you how to convert the return from the sforce webservice account query directally into a .NET datasource. It's only a couple of lines of code but I'm sure that you'll find it usefull in building complex application.
