We have a series of webinar events on 5 different topics that have multiple sessions that run weekly through the month and repeat each month for a quarter. This equates to as many as 5 events per month (1-2 weekly) and 15 events per quarter. The webinars are hosted in Webex and registrants come in through multiple sources and register on an Eloqua landing page and form. After that form submission, they are processed through to Webex in preparation for the event. After the event, attendees are sent to Salesforce for sales followup. The challenge is the development and management requirements to support ongoing weekly webinars and associated processing for a program of this magnitude.
To create a scalable, repeatable solution for processing a series of Webex webinar registrations and sending attendees through to Salesforce automatically with the development of as few Eloqua assets as possible. We also wanted to be able to "set it and forget it" each quarter - to be able to launch a campaign at the start of the quarter that would distribute each set of webinar invite emails based on the event calendar and then have any registrations automatically processed to Webex and through to Salesforce as appropriate without having to launch new campaigns for each webinar in the series.
When you consider the assets potentially required to support this effort - 15 invitations emails, 15 thank you emails, 15 landing pages, 15 forms, 15 reminder emails, and 15 campaign canvases that must be created every 3 months, and given the fluidity of webinar event scheduling, it was necessary to find a way to minimize the build requirement, reduce the required lead time, and make the process as efficient as possible.
1. The first decision in our solution set was to eliminate 14 forms by creating a single form processor that could accept registration data from each of the landing pages along with unique identifier values indicating which specific webinar the contact is registering for.
2. Next we created the initial set of webinar invites by topic for the first month. Once these were created and approved, they were cloned and only the dates for the remaining sessions were tweaked in each email. By minimizing the content changes in the repeated sessions, we minimized the development effort for creating the invites for the second and third month of the quarter.
3. Though we kept the 15 thank you emails because they are customized with the .ics calendar files applicable to each event, we created a universal thank you landing page that has a video that helps the contact prepare and test their desktop or device for a successful experience when they join the webinar event. This eliminates 14 landing pages on this first quarter, and all 15 thank you pages on any subsequent quarter.
4. For the 15 reminder emails, a decision was made to send them from the Webex platform instead of Eloqua. They can be automated from that tool and are customized for the given event. This decision automatically removed 15 emails from the list of requirements, and still provides for a good customer experience.
5. For the campaign canvas, standard processing would require that we set up a single campaign canvas for each webinar and process them individually. Instead, we have created a single invitation campaign canvas that has a "track" for each event topic in the series. Within each track, the canvas sends each invite out based on the date of the event, and when a contact actually attends an event within the track, they are removed from future invitations for that track. Once the contact receives the invitation and registered, they are picked up from the form processing step and dropped into a program canvas via a Listener. The program evaluates the ID assigned for the webinar, registers them in the corresponding Webex event via the Webex Cloud Connector app, and then holds them in wait step until after the event. Upon conclusion of the event, the again accesses Webex via the app to confirm that the contact attended the webinar. If the decision rule returns a true value, the contact is sent through a second Cloud Connector to Salesforce for sales followup. If they did not attend, they are dropped from that path in the program. By using Program Canvas, we can handle a single contact being in the program multiple times if they register for more than one event in the series. This part of the solution eliminates the need to have 15 different canvases set up and running each quarter to process for each webinar, and instead uses 1 Campaign Canvas and 1 Program Canvas that run continually until all processing for the quarter is completed.
Below are screenshots of the Campaign Canvas and the Program Canvas. The canvases are large and complex so only partial screenshots are provided.
By the numbers, we reduced a total of 90 assets per quarter down to 34, with 20 of the 34 being quick "clone and tweak" versions of originals. This is a 62% decrease in physical assets required to be managed in the system and, if you extrapolate using an average build/test time of 4 hours per original asset and 2 hours for cloned assets, a savings of over 264 hours per quarter of development time alone. This does not include additional savings on reporting requirements, asset management etc. In addition, this solution allows us to be flexible and responsive to an increasing requirement for supporting online events that have short lead times, changing requirements, and can be easily scaled and repeated.
Going forward, we plan to revisit the invite emails for the repeated events to see if we can find a solution using dynamic content that would allow us to create just that initial set of emails and then resend them with revised content as each repeated session comes up. In addition, we will be looking for ways to reduce the number of thank you emails by finding a solution for customizing the content and .ics file link for each webinar.
Marketing Cloud courses that were helpful with this project: