Last week we completed our SmartStart Foundations Workshop for our new E10! Overall I am very happy with how the week turned out.
In my last blog post about day one Dual CRM Integration with Eloqua: SmartStart Workshop Day 1 - (aka trying to fit an elephant into a cat carrier) , I admitted that for day two we needed to come back down to Earth and start getting stuff done versus debating how we want to do things. I am proud to say I kept my promise for most of the day and we managed to be extremely productive! We connected both CRM sandboxes to our E10 instance and did some successful initial testing.
Day three however, I made the decision there was one thing I could not leave on the table and I had to put the brakes on!
The most challenging aspect of setting up a new Eloqua system with a dual CRM integration is deciding how to set up the contact table. How many fields can be mapped to both CRM systems and how many system-specific fields will be needed? Is there a better way?
When we started this process I wanted to leverage custom objects as much as possible versus filling up the contact table with fields that can be mapped to only one of the two CRM systems in the integration. Initially I was told that custom objects cannot write data back to SFDC – a fact that would dramatically influence our database structure. After some lengthy discussion I am hopeful we may have found a work around! I am waiting on Sid Batra to connect with Nathan Lichte to verify that what we came up with will work.
While we wait for the final verdict on how much we can leverage custom objects, there are a lot of other decisions that need to be made and work to be done:
1. Getting the basics right.
Thank you to all my Topliner friends for your amazing suggestions in: Re: What would you do differently if you got a clean instance of Eloqua and could start from scratch?
I have already tackled naming conventions and folder structure. I am working on my clean house plan to ensure things stay in good order. And everyone’s favorite – documentation – is in my near future.
2. Dealing with duplicates.
It is OK for duplicate contacts to exist across systems – meaning being a contact in both CRM systems. Duplicates in the same CRM system – not OK.
Options:
Undertake a massive data cleanse exercise - after all, we all know how easy that would be to accomplish (said no one ever!).
OR
Decide that any contact that is a duplicate in a single CRM system is not eligible for Eloqua campaigns.
This one was a no-brainer. We fortunately have an SFDC developer on our team and I am challenging him with writing a program that will help us identify duplicates and tag them accordingly in an automated fashion. Still not sure how that will work out but I still believe this is infinitely easier than dealing with a data cleanse exercise. This also put the ownership of cleaning up duplicates where it belongs – with the owners of the duplicates. If someone wants to include a contact in a campaign and that contact is marked “not eligible for Eloqua campaigns” then it creates a true “pain” and the two affected “contact owners” can start talking – ideal if you ask me – shouldn’t we be speaking to these people as one company and treating them as one contact?
3. Choosing which contacts to sync with Eloqua and which contacts to keep only in SFDC.
Since we pay by contact in Eloqua, and we will not email everyone with an email address in our SFDC systems, how do we control this? Our easy answer was with a check box “Sync with Eloqua.” We still need to work out the specifics around how this box will get checked in a non-manual way. I welcome your input if this is something your company currently does.
4. Planning out test scenarios
Before we can flip the switch from our CRM sandbox instances to the live installs, we have a lot of tests to run. The approach I am planning on taking is to identify a group of internal “testers” who can receive emails and take certain actions (submitting a form, clicking through to the website) to help us ensure Eloqua is writing the correct activity data back to the correct system. Some testers will be unique to a CRM system, others will be “duplicates” so we can see what happens.
My task for the remainder of this week is to come up with a comprehensive list of test scenarios – your suggestions are welcome! (I think I see another Topliners post in my near future!).