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 ...