Salesforce.com Implementation -- Day Two

The first challenge: getting real data into Salesforce.com. We had two years of Account, Contact and Case data that we very much wanted to retain for tracking and reference purposes. Toward that goal, our Salesforce.com Sales Rep (Luke St. James -- he's GREAT!) had recommended that we get a Salesforce.com Partner to assist with the data migration. My boss had been speaking with them by phone, and they had been on-hand a week before for the SFDC demo. They had also provided us a quote for their services.

Six weeks, $50,000 US ... yikes!

To be fair, their fee included more than just the data migration from our old SQL database. It also included a full "business process review", data de-duplication of data from our legacy system, data migration into SFDC, and training for our Support staff.

On the otherhand, they projected this to be a 6-8 week effort, and wouldn't be able to start until the first of the year. I started looking for other options.

Through a little keyword searching on the "Help & Training" link, I discovered the Data Loader. The Data Loader is a client application that you download to your desktop. With it, you can bulk import or export data from your Salesforce.com instance. Eureka! This was handy.

To find the Data Loader, you must be the System Administrator:

1.) Click Setup (top of screen, just right of center -- see screenshot below)
2.) From the Administrator Setup menu in the left side bar, click Data
Management -> Data Loader

The best thing about the Data Loader is that it gave me my first glimpse into the architecture of the Salesforce database. Through the Data Loader, I could see every table (err, I mean object), and every field within those tables. I could not see data types, but seeing the object data structures was enough for now. I exported every object that the Data Loader could view.

The Data Loader creates CSV (Comma Seperated Value) files, which you can view readily in Excel. As I skimmed through all the CSV files, I became aware of all the fields in the database -- even the ones I couldn't see from the Page Layout screens. This was cool!

I started to see how object relationships were handled. For instance, in the Contacts.csv file that I had exported, there was no field named "Account". Instead, there was a field labeled "AccountID", which contained a unique 15-byte alpha-numeric string of characters. I grabbed a random Contact, and tried to see if the AccountID had a matching value in Accounts.csv file. It did ... bingo! So that's how they relate Contacts to the parent Account.

It quickly became clear that I'd have to load my legacy data in a systematic way:

1. Import all Accounts
2. Export all Accounts to get their AccountID values
3. Manipulate my Contact import file, replacing the Account Name with this AccountID value
4. Import all Contacts
5. Export all Contacts to get their ContactID values
6. Manipulate my Case import file, updating the appropriate AccountID and ContactID to each record

Phew ... sizeable task, but doable. Monkey work.

Now I had a list of field names for the Salesforce.com database, and I could map those to the field names in our legacy CRM database. Importing the data didn't look like it was going to be all that difficult a task afterall. I hadn't imported a single record, but I had a data map of both systems and was confident that we'd be able to do this work in-house.

It's a GREAT feeling when you can go back to the boss and tell him, "Hey, guess what -- I'm gonna save you $50,000, and deliver the product EARLIER than expected."

So naive.

You've got 30 days ... starting now

"You've got 30 days," my boss told me. "Make the most of them."

We had just turned up several Salesforce.com Enterprise User licenses on a trial basis. I needed to use this 30-day window to:

• Evaluate the Salesforce.com (SFDC) product overall
• Benchmark SFDC against our current CRM platform
• Determine if we should contract a 3rd-Party Partner (referred and recommended by our SFDC Sales Rep) to assist with data migration from our old CRM platform
• Provide a recommendation go / no-go to the EVP of Operations
• Develop a roll-out plan

I stared at the calendar. 30 days. It really didn't seem like a whole lot of time to evaluate a product, recommend a corporate CRM strategy, and develop the roll-out plan for the entire company. Especially since it was early December, and the calendar already had almost two full weeks of Christmas and New Year's holidays blocked out, right in the middle of my 30-day window.

Okay, well ... let's get started.

Evaluating the Product - Day One

I logged into my Salesforce.com trial account on one computer, and our current CRM tool in another computer. I clicked through the various page layouts, comparing them side by side. The views betweem both platforms were very different (I jotted "user training" down on my notepad, and underscored it three times). I liked the way Salesforce.com displayed "objects" in different tabs.

It took me a while to get jiggy with Salesforce lingo. Objects? You mean "tables", right? Database records are stored in tables. My database has an account table, a contacts table, a table with all our cases, etc. Objects, smobjects. I don't know if other newbie admins struggled with the SFDC naming conventions, but I resisted referring to these structured data structures as "objects" for a long time. It wasn't until I started networking with other SFDC Admins and Developers that I forced myself to the naming convention -- just so we could talk a common language.

I started creating some dummy accounts, dummy contacts, and dummy cases. Our corporate Sales team didn't want anything to do with this "Sales Methodology" stuff, so I didn't have to worry about leads and opportunities just yet. This first deployment and roll-out would be for the Support team only.

I clicked into the various views for each of the test records I had created. I really liked how related records were visible in each detail record page. For instance, while in the Contact Detail Record Page for "Joe Schmoe", I could see all of the cases that Mr. Schmoe had "submitted". And when I clicked on the Account at which Joe Schmoe was employed, I could see all of Mr. Schmoe's cases, as well as all of the cases opened by his colleagues (Joe Cool and Jessica Rabbit).

The web-browser interface was fast, and I was able to jump from record to record, view to view, very quickly.

After I'd created dozens of accounts, contacts and cases, played around with the search and lookup functionality, and navigated around the tool, I moved on to the Solutions tab.

A Support Organization lives and dies by the ability to create and retrieve knowledgebase articles (our term ... Salesforce calls these "Solutions"), and our support team is no different. In this area, there were some plusses and minuses around the SFDC implementation. In our current CRM platform, we had the ability to use HTML tags in Solution articles. This allowed us to incorporate images, and rich text format (varying fonts, bold / italicized script, text alignment, text colors, etc.) into the solutions. Salesforce, at the time, did not have this functionality.

On the other hand, Salesforce.com had some features we didn't have in our old platform -- such as a weighted percentage "score" that showed the user how likely the solution matched their keyword search criteria. It also allowed for the weighting of solution articles, based on the number of cases these articles had been associated with. Finally, it had a status field for Solutions. I jotted down "build solution release process" in my notes.

The next tab was reports -- wow! There were dozens of canned reports, already built into the tool. There were reports that showed recently added accounts, contacts, cases, across all types of matrices and report formats. The reports could be converted to Excel at a click of a button, very handy! It was very easy to develop a few custom reports, too. I started by just modifying some of the existing reports (adding a new column, changing the order of columns, changing the data filters, etc.). Then created my own custom reports from scratch.

I could tell that my users were going to be challenged by report making in Salesforce.com. It was easy for a database geek (me!) -- who lives in a world of tables, fields, related joins, and filtered select clauses -- to make reports. To lay user, however, that report wizard is just a complex jumble of words, drop-down fields and checkboxes. Salesforce.com has powerful, built-in report-making functionality, but I would need to consider how to roll that out to my end-users very carefully.

Dashboards pretty much blew me away. I had already seen them, of course, in the customer demo that Salesforce.com had given us. But to see these graphical dashboards refreshed with my recently entered test data (as well as some demo data from SFDC that came with the trial account) ... that was just too cool for words.

I looked at the clock, realized it was well past lunch break. I had other projects on my desk besides this one, and had to get to them.

I'd written about 3 full pages of notes. Here are the highlights:

• Need real data -- how do I migrate existing data into SFDC?
• Need help -- what resources can I tap for this project? 30 Days is really 2 weeks, when I factor in upcoming company holdiay time
• Need training (for me!!) -- what admin resources are available online? Instructor-led local? Instructor-led remote? Books?
• Need training (for my users) -- the product is sufficiently different that it's not going to be a simple drop and run
• Lay out the work -- project plan, task list, completion criteria, schedule
• Vacation -- this project is big, plan a nice vacation at the end of it

Come back tomorrow, and see what happened on Day Two ...

In the beginning ...

I have to tell you, in the beginning, I really was not a very big proponent of Salesforce.com. In fact, I hated the very idea of it. Let me get this straight -- you want me to take all of our highly sensitive and confidential customer data and host it remotely? Give my employees access to this data over a web-browser? Pay for the service on a per-user monthly subscription basis? You, sir, are completely nuts!

But the high-priced consulting firm that my company had hired to help select our CRM platform had listed Salesforce.com, along with two other "top picks". To be fair, we gave all three vendors a chance to come in and do their dog-and-pony show. We talked with their customer references, and did a fair amount of digging ourselves. And, of course, we spun the numbers through some ROI models for the corporate management team, who would ultimately have to sign the check.

Something surprising happened along the way. Unavoidably, I became a believer in the SaaS model. SaaS -- it means "Software as a Service" -- and it's the business that Salesforce.com is in. What did it mean for me? No hardware to purchase. No requirements to build a redundant network architecture so that in case the system in Derry goes down, my remote support team will still be able to access the data. No server maintenance costs. No operating systems to manage, upgrade and maintain. No database (Oracle, SAP, GP) to buy. No integrated software to install. No 6-12 month CRM implementation lifecycle to worry about.

We were up and running within 2 weeks, and that includes the time it took to import two years of cases, solutions, accounts and contact data from our legacy CRM system. We spent the next few days and weeks optimizing the system, enhancing the user views -- adding customizations and features that were simply not options in our previous CRM tool.

I kept a development blog of our progress, but because a lot of it is proprietary and company confidential, I can't simply open it to the world. So instead, I'm going start a seperate blog on this site -- to bring any interested readers up to speed on how we implemented Salesforce.com, and what we learned along the way.

Salesforce Monkey is personal interest project, but I hope readers get some benefit from it, as well. Stay tuned!