The new lottery application widget is the first step towards providing a brand new, versatile and much simpler lottery process. No need to synchronize contacts to a separate module and re-integrate reservations/sales after the draw. The new process relies on existing tools of the core S-360 system and will allow you to run your lottery in different ways.
Automated payment lottery: in the classic mode, customers define precisely what they are applying for, including the tariffs and quantity, and the system will automatically create a reservation for each winners. Automatic payment can be done if credit cards alias have been captured.
The application widget now supports capturing the quantities and tariffs. However, the draw process and automatic payment require an ad hoc process. |
The new widget lets you customer register their requests inside the waiting list table
The new process relies on the following tools:
Currently the new widget only supports multiple events/competitions with multiple performances/matches. It does not support other product families. |
In the sales periods of the activity profile, a new function has been added to define the competition and matches available for request.
You need to activate the link in the navigation menu, (which also activates the widget) through the following POS configuration key: config.presales.waitingList.activated = true |
For capturing the tariffs and quantity, the organization needs to be configured accordingly.
A new "Application confirmation" document class has been added. The email is triggered when creating, updating and deleting an application. For the first two cases, the content of the application can be displayed in the email.
The new widget is integrated in the following page:
The first screen can be configured to provide information about the lottery process. It also serves as the summary page, once an application has been submitted.
The second screen lists all the matches available and provides the following filters:
Users can expand specific matches and select one of the available seat categories. Once all requested matches and seat categories are selected, the user can click on the continue button at the bottom of the screen.
In the mobile view, the team names are replaced by the team codes, so it is recommended to use an official 3-letter code system:
|
The lottery application widget can also capture tariffs and quantities as illustrated in the 2nd set of screenshots.
The last screen of the process displays all the specific contact criteria with visibility level "Lottery application" to provide some additional options.
Users must then accept the terms and conditions to save their application.
Applications can be later edited or fully cancelled.
When the capture of tariffs and quantity is active, the system will check the following constraints:
Conditional tariffs are displayed in the same way as in the regular sales process and will become available only once the parent tariff threshold quantity is reached. The quantity ration will also apply.
Contact limits and sales restrictions are enforced when the application is submitted. The validation is currently only done back-end side.
Note that sales restrictions are also enforced with only capturing the seat category.
All requests can be reviewed and managed from the waiting list screen of the contact module.
SAM targeting can be used by relying on custom queries.
The query builder does not support direct targeting of the waiting list data. However, custom queries can be built to create a SAM target. The waiting_list table needs to be whitelisted in the institution parameters of ELCADMIN for custom queries on the waiting list table. |