I have been working at Wolters Kluwer since the beginning of this year, it's a very big organization with a very big challenge: Implement and introduce Eloqua as all-round marketing tool in more than 10 different countries/business units.


I joined the company in wave 2, which meant that already four of these countries had joined, the rest of the countries/bu's were still to follow.


Fortunately, my colleagues who worked on this before, created a data model blueprint, which enabled standardization of implementation in each country.


This blog is about:

  • Status quo
  • Where to next?
  • Lessons learned from implementation and on-going support.
  • Conclusion
  • University courses using during this implementation.


Status quo:

At this moment, all countries have been implemented with Eloqua and we have a governance structure in place.

This means that every country/BU has a local admin (customer administrator but with less rights) and a marketing champion who represents the business.


We try to assist and let them grow in the use of Eloqua by:

  • Jira (support management portal).
    • In this portal, we (customer administrators) are able to resolve defects, service requests and change requests.
  • Confluence (knowledge management portal)***(Figure 1.0)
    • In this portal best practice knowledge is placed, as well as information about change requests, FAQS and resolved tickets (solution building).
    • Solution tagging is applied, which makes it easy for local admins find solutions easy. (this accumulates)
  • Workshops
    • One data model workshop has happened so far, where the data model blueprint was updated. As marketing automation knowledge grows among end users, so does the need for more automation for new possibilities.
  • Operational calls (this is a moment where local admins can speak about their tickets, but can also request help from other local admins)
  • Training Tuesday (this is a moment where a new topic or addition to our Eloqua instance is shared/explained.)
  • Best practice sessions (a place where marketing automation champions share successful stories/campaigns to inform other countries their MA champions.



Where to next?

As a Customer administrator, my personal challenge is to keep/turn every country as enabled as they can be in marketing automation.

However, this also means strict regulation of changes towards the data model and/or APIs. We safeguard this by severely QA testing new apps or other additions towards the Eloqua instance.  We’ve lined up some ideas that we’re currently or are going to work on in 2018; to make the end-users as enabled as they can be.



  • creating a local admin community
  • creating a marketing automation champion community


This will give them a way of speaking to each other and addressing the business growth points where me or my colleague from an operational point of view won’t get too as fast as they might.

These communities will be, in a sense, their own responsibility, but we have some ideas outlined for the future that we can push like: ROI reporting, marketing funnel and add-ons for Eloqua that can assist them in their future needs.


User role acceptance tests:

We are also going to work out a test-plan in 2018, which will enable newly created end users to create a series of assets in Eloqua, testing their Eloqua knowledge and skill. Based on this an appropriate user role will be given to this person.


Tighter change request process:

The most important aspect of change requests is communication, technical understanding comes after this. I'm mentioning this because early this year me and my colleague were facing the implementation of several countries, while taking care of support towards other countries. This made for situations where a lot of backtracking was needed.


To avoid this we applied the following improvements:

- Use a template in confluence to register change request instead of a Word document. This allows for one place where every change request is stored. (this can also be linked back to our support portal, Jira)

- After this, the architect then estimates the effort on Eloqua side, but also the API side.

- Finally this is then presented in a Change request advisory board (CAB) where this change request can be approved/paused or rejected.


Knowledge management:

Eloqua knowledge is pretty rigid, meaning it doesn't change that much over a big period of time. However there is a lot of information out there! We try to give that a place in Confluence, where the communities can share opinions and discussions. That is the place where the knowledge will get challenged but also applied to several topics.


We're currently working on expanding this, to inform different kinds of stakeholders in one place about everything Eloqua related that they might be interested in. Please see picture for overview.

(Figure 1.0)

Right now we’re seeing that often successful cases are being shared in the best practice sessions, but I believe it to be incredibly valuable when countries will start talking about their moments where something went wrong or just simply did not have the expected result.


Lessons learned from implementation and on-going support.


Create a firm data model

One of our learning points was that the data model piloted for just one country, was not sufficient. It should have been at least 3-4 countries looking at the entire scale (10 countries)

This would have saved a lot in time and effort in reloading and re-adjusting API definitions with Eloqua in the beginning of the project.


Check limitations of the tracking script.

One of our learning points was that we were unaware that working with all countries in one instance, makes it so that the tracking script would eventually hit a limitation of an X amount of million records per day. If we had split the countries over multiple instances with multiple tracking scripts, we wouldn’t have had this problem. To be fair, this was not communicated to us, but it’s a lesson none the less.


Design a labeling workflow that works for all countries, but in a smart way.

We had already worked with a labeling workflow, that labeled most contacts just once, unless re-labeled completely. The lessons we learned from our partner consultancy firm was that when adding a label first that is for the customer administrator (let’s say: label = ALL_Contacts) that this causes trouble* when the label gets deleted by manually putting this into a step that deletes the labels.


We upgraded this flow, to always check if a person had been modified in the last 24 hours, if it’s a floating contact (a contact shared by multiple business units), if so, it gets relabeled accordingly via a series of checks. Please see picture (figure 1.1)


*To clarify, we learned that when labeling contacts, you start from the smallest label towards the most global label that you can assign to this contact, if you don’t do this, and the contact needs to be re-labeled, this person will drop out of a campaign.


(figure 1.1)


4.      Branding VS HTTPS

Without Branding, you can have https, and with branding, you cannot have https, that’s the rule as it is in Eloqua. However, we discussed several months with countries about this matter, until it turned out that the https submission of data can still happen when you just change the link in the form submit button.


Note that we still bought SSL certificates for certain microsites, but branding can stay turned on, without having the lack of https. This would be a matter for concern for countries having clients using Google Chrome (this will more and more show warnings about insecure sites).


5.        Keep the change request simple

Looking back, I would say that: create the change request process as simple and tight as possible + always have an efficient way of sharing this knowledge with all countries.



The project itself has been commented as one of the smoothest projects, but this was really due to the project team having severe project management skills, great consultancy partners with the necessary knowledge, and a willingness to commit to a timeline and resources/skill by the local countries.


We now have a marketing automation setup for around 10 countries/business units where I myself plus another are the customer administrator and the business process owner of Eloqua work successfully to support every business with their growing marketing automation needs. Governance is the key in this area.


It is now a matter of continuing the blueprint that was laid down, trying to keep the data model in place, and have continuous communication about changes that affect countries on local level, triggering input for improvements for other countries.


Hopefully above, and knowledge management measures we are taking will let each country focus more on:

- email marketing in an advanced way

- building welcome campaigns and personalized nurture campaigns

- more a/b testing

- more returned value (converted leads/ROI)


University courses used during this implementation

Academy Course – Eloqua 10: System Integration

Academy Course - Eloqua 10: User Management (WBT)

Academy Course - Eloqua 10: Database Security (WBT)

Academy Course - Eloqua 10: Database Configuration

Academy Course - Eloqua 10: CRM Integrations (WBT)

Academy Course -- B2B: Technology (1-day course)

B2B: Program Canvas (WBT)

B2B: Integrating Custom Objects with Campaign Canvas