After months of admiring event management success stories and hoping for a scenario where I could foray into ESM once and for all, I got what I wanted.
Our internal Global Sales meeting was under way.
3 days, 15 time slots, 103 sessions/options and 300 participants. Perfect – couldn’t be simpler. All I had to do was model Eloqua training registration and I was set.
It took a good month and a half and a whole lot of (sometimes foolhardy) determination before we got something that works the way we need it to. What I learnt through the process is that even if something looks like it will not work, chances are, you can string something together that will give you what you need. There are really no dead ends though you will find that there are limitations to the system. The key is determining what result you want and working backwards from there.
I dove into ESM with no idea what lay ahead and soon came across –
Challenge No. 1 - ESM was not built for multi-option, multi-time slot events.
Here’s what I mean. My form looked something like the image attached (The-form.gif)
Each “Please Select” had a minimum of 6 options. Each registrant had to make a selection in each time slot so that their potential datacard had 15 sessions total – no less (and no more!) So while ESM functions well in the arena of one datacard per contact, here is where it gets tricky.
Solution: 15 Event processing steps in the form
I cannot take credit for this part but I will say that the solution was to add a “Create/Update Event Registration” processing step for each time slot. While this will mean that you have 15 datacards per person, it worked pretty well since the point was to make sure that each person is registered for the session they want in each time slot. Using Event reports to slice and present the data takes care of the multi data card problem and it was not an issue.
Challenge No. 2 – Being limited to one Session Field for all those time slots.
If you have used ESM you know that you can only assign one field as the Session field. From this session field, multiple sessions (if you have them), will be created. For me, as you can see above, that was a BIG PROBLEM, as I had 15 fields, all whose values needed to be populated into that one field. In other words, my event in ESM had to have a total of 103 sessions in the Event details section.
Solution: Use 15 values in the form but trick Eloqua into passing those values to one field
Again, I cannot take credit for this solution but on my form I had the 15 fields as needed. In the Eloqua form I also had the 15 fields but introduced another Single Select field (Selections) that didn’t exist outside of Eloqua. In my Event processing steps, I mapped each of the 15 fields to the Single Select field (see image attached - "form_processing.gif")
This worked well, allowing the Selections field to now house all the values in one place. Note that I also had to create a Single Select list in Eloqua with all the values exactly as they appear in the external form. I mapped this select list to the internal field Selections in the form field area. It came in handy!
Now, I could assign Selections as the Session field and Viola! 103 sessions – just like that.
Challenge No. 3 – Not being able to notify the registrant which session they are waitlisted for.
One of the reasons I didn’t want to abandon ESM was because of the waitlist functionality. With 103 sessions to manage, you can imagine it was a huge plus to have ESM do the work for us. However I discovered (again because ESM was not built to be used the way I was using it) that since each person was registering for 15 sessions and could be waitlisted for one and not the other session, it was not possible to customize the email in such a way that I could dynamically insert the name of the session that was now full and notify the registrant. There is no connection between waitlist functionality and any fields that I had access to on the front end.
Solution: When the session is full – remove the option from the HTML form!
Sometimes the answers are simple. Although this meant manual work for me, turns out that by investing the time up-front to use ESM to manage the registration for us, I actually had the time to do this. Since I was getting the System notification that the session is full, as soon as a session was full I removed the option from the form, and only had to manage one or two registrants that sneaked by. Not a problem at all.
Overall I appreciate the experience since now I know what the limitations are. I still think that ESM is worthwhile but knowing the limitations upfront is very valuable as it allows for proper project planning.
I appreciate the fact that while there are things that don’t always work the way I imagined in the tool, in the grand scheme of things Eloqua is still flexible enough that I have the option to come up with a solution. I don’t think all tools have this flexibility.
I’m sure there are other ways to tackle these challenges and I like the fact that almost all users I have come across find their own solutions to the same problems.