Client Challenge

Vodafone had recently brought all their different B2B business units onto 1 instance of SFDC, their CIO had a vision to streamline Eloqua in the exact same manner.  VGE was already using Eloqua so they were to open up their instance to allow for the on-boarding of all other B2B business areas globally.

They had eight different sandboxes to go through, Accenture were the firm that had implemented 1SF, their 1 instance of Salesforce, VGE did not want to have any other business unit get brought onto their platform and another agency, Sojourn Solutions were deeply embedded with VGE.  Throw on top of that a very strict change board and this was by far the most hostile Eloqua engagement I had been on.

Approach

The approach was to build an Eloqua implementation package which would using the UK as a vehicle.  Then use that standardized package to roll out to each of the additional countries, thus achieving having all of Vodafone B2B on the same instance.

Contact level security was the key to making this possible.  VGE had their own program that would identify Enterprize contacts, then the rest would be separated by their country, assigned to the relevant business group, contact level security would kick in and then leads or contacts would be created and sent to SFDC so sales could process them.

Progress was very slow because every single decision needed to be ratified by a change board that did not necessarily understand what it was I was trying to push forward.  It was a very political engagement which is an environment I find foreign and unforgiving.

The major part of this was getting the integration between SFDC and Eloqua built because that was seen as the key to being able to on-board the other business units.

VGE would not allow us to open up the integration they had to include the country code for leads and contacts that would be sent though.  It became apparent why – but not until a lot later in the project.

Accenture had built 1SF – The CIOs vision, one platform, one record, one central point of truth.  Through pushing hard and making a lot of enemies on the way I found out why.

There were two ways to build one version of the truth, the hard way and easy way.

The hard way means globally agreeing on a lead layout with core values, there may be some localizations that would get displayed on SFDC user views, this includes the dreaded picklist value questions.  Then fields that were required for localization could just be added to the SFDC users view for that business unit.  This method ensures one version of the truth.  You get your 360’ view because one contact or/and lead in SFDC equals one Eloqua contact ID and in Eloqua with the SFDC Lead ID and SFDC Contact ID fields containing the ID for their related object in SFDC.

The easy way is to have one instance of SFDC and multiple record types, different picklists for business units and more or less have everyone sign off on everything because everyone gets what they want.  This means the project gets delivered ahead of schedule with minimum people from the Accenture side and profits are maximized.  However there is no 360’’ view of the truth because contacts and leads could be owned by different overlay companies like Internet of things, there were other reasons too but you can probably imagine all the scenarios.

Accenture has built it the easy way which I can understand, no resistance, everyone is on one instance of SFDC, however this would then create merry hell for the integration approach and not achieve the 360’ view you are looking for.

We built the implementation package, got the integration working for the GB, ES and IE markets.  This was then subsequently rolled out to other areas.

Impact

The other business units were brought on to the same instance of Eloqua so that was a success.