Salesforce for Outlook is our next generation integration that we introduced a little over a year ago, which replaces Connect for Outlook. Over 60% of customers integrating Salesforce with Outlook are using this new integration, and thousands more are jumping on board each month. While we're pleased with the adoption, we realize there are still gaps to fill to deliver on the product vision.
Before I get ahead of myself, it has become clear that the introduction of Salesforce for Outlook has left our satisfied Connect for Outlook users somewhat bewildered. "But I had an Outlook integration that worked OK. Why did you change it? Is this a conspiracy against Microsoft?" Umm, no. Let's take a look at how we got here.
A few years ago, we were wrapping up a minor release of Connect for Outlook and were planning the next version. We'd been talking to a lot of customers and we kept hearing the same feedback. Connect for Outlook demo'd well and was initially welcomed by users, but adoption was suffering over time. As a result, these customers' CRM adoption was suffering, too.
By and large, customers thought we could do a lot better. They told us:
  • Your integration is too cumbersome. It's not intelligent. Our salespeople like to move deals forward, not waste time worrying about whether their data is in sync, manually resolving conflicts, managing complicated settings, or performing repetitive steps to add emails.
  • Administration is too complex -- desktop XML files, Windows Registry settings -- aren't you a cloud computing company? We're trying to rely less on IT for our CRM deployment, but this desktop-based configuration model increases our dependencies.
  • It's slow! The more data I have, the harder it is to use Outlook.
We also had learned a lot about Outlook add-ins since building our first integration. They're painful! One software company executive I know described it as "dealing with a bunch of sharp objects". Conflicts between add-ins can occur regularly, the single threaded model is ripe for grinding Outlook to a halt, and to make matters worse, Outlook will decide to disable the last add-in that was running when it crashes. I think everyone knows Outlook can crash just fine on its own. Maybe the conspiracy is the other way around? It was clear to us that moving to a lighter-weight architecture with most of the code running outside of Outlook - on the desktop and maybe in the cloud, too - would serve our customers well.

Another influencing factor was the explosion of a new generation of mobile devices becoming available. They were powerful, easy to use, and showing up in corporate environments around the world. Our users increasingly were doing less at their desks, and more on the go. They needed a way to capture their customer communications in CRM easily, from any device.

So we set out to build Salesforce for Outlook. The architecture moves administration and matching to the cloud, minimizes our footprint inside Outlook, and requires less and less work of the user with each release. Under the hood, we use Email to Salesforce to capture emails that users add to Salesforce. You can use it to add Emails to Salesforce from within Outlook, or from ANY email client.
So where are we headed? (Gasp) Yes, I'm sharing roadmap. Some of our themes:
  • Focus on software compatibility and fully support the latest software our customers use. We didn't react as fast as we should have to support Outlook 2010 and we intend to do a better job here, going forward.
  • Deliver simple integration with the Service Cloud. Service reps are people, too!
  • Give users more control over how their Outlook data integrates with Salesforce. You don't want your grandmother's contact info or dentist appointment in Salesforce? Perfectly reasonable. We should make that a simple decision.
Check out IdeaExchange for some of these features coming in the next release. Spring '12 should close many of the gaps between Salesforce for Outlook and Connect for Outlook, but we're not done.
provide a big leap forward in productivity and compatibility. Mass actions and recommendations will make associating data a breeze and the wait for Outlook 2010 64-bit support will finally be over.
There's much more to be done.