A couple of weeks ago, for the International Startup Festival in Montreal, a few companies related to Email threw an off-site event – a “hack-a-thon” – to announce their new APIs. I attended the event, and had a pretty good idea of a “neat” tool that I’d like to see for dealing with the kind of data you find in your email inbox. I was pretty jazzed up to start writing the tool until I found out two things:
- What we were being judged on
- Someone else had already built it at a similar event the month before
We were being judged on the number of APIs from that day we used, the creativity of our app, but also the financial viability of it. The business sense. So instead of doing something “cool”, I decided to do something that as a Salesforce User and Admin/Developer, I knew was a particular sore point with the application – Email Integration.
The current state of affairs for integration between email and Salesforce is a bit of a hodgepodge of solutions, so to speak. You can integrate Salesforce with your Outlook installation, or set up an email service (or use the existing Google service for this) that you then make privy to all of your email traffic, bcc’ing it every time you want something to show up in salesforce. You also have to be aware that one solution doesn’t act the same as the other – they all have their quirks and idiosyncrasies, so if you have users on multiple platforms or some that prefer Outlook and others that don’t, there’s no unified truth for email in Salesforce. Of course, you can force users to adopt one method or another, but then you’re making your users conform to the tool instead of making the tool fit the user – not exactly the goal when implementing a system as robust as Salesforce.com!
Once the email data is in Salesforce, it works “sort of” like any other object, but not really. It’s hard to get the data you want when you need it, and even harder to make sense of the data once you find it – assuming your users are still uploading data the way they’re supposed to. With the burden of data delivery on your salespeople, you’re taking them away from the key tasks they’re meant to perform and asking them to follow a new process every time they do something as naturally reflexive as send out an email. That’s like asking someone to change the way they breathe, all day and every day: it can be done, and it’s not an incredibly difficult task, but you’ll be hard pressed to get as much done in your day as you potentially could! Also, you’re more than likely to forget as soon as something important comes up and shakes you out of it. In other words, it’s not natural, it’s not needed, and it’s not the best use of your time!
I guess that’s the ultimate goal when I started working on this – the autonomic nervous system of the sales cycle. Just like youshouldn’t constantly have to think about when to breathe and how, your salespeople shouldn’t have to think about how their email data is getting into Salesforce. By connecting to the email server directly, we can make sure the key data needed to let you make the right decisions ends up in the right location, and by making the details configurable from directly inside Salesforce, we can do it without requiring any additional components or systems to be set up. No plugins in your email client, no bcc’ing some random email address with every communication, and it can all be done directly from inside your Salesforce window. So that’s what I presented, or at least the beginning of it, at the hack-a-thon.
Apparently I wasn’t alone with my frustrations, as I ended up winning the event.