Purpose
Generally, when tickets for a performance or a match are sold in SecuTix, the seats are selected on the seat map at the time when the order is placed by the customer, be it a reservation or a sale.
When organising a tournament, or another event with advanced seating needs, it is sometimes useful to be able to sell tickets without selecting any seats, and to assign seats to customers in a second step, once the full overview of the orders placed is known.
This can allow seats to be to assign independently of the order in which the sales are made, to seat favoured guest or sponsors in specific locations, or to determine after the sales where specific groups will be located, for instance.
Such a process can also allow sales to be conducted before a real seat map is finalized, just using a temporary one where only the quotas are known.
Such a process has advantages in terms of flexibility, but consequently requires a more complex handling of seat quotas, which must be determined twice, once at an abstract level independently of the seat map, and once on the seat map itself. There is an additional effort to be planned to ensure the consistency of these quotas, and a careful decision should be made before making use of the functionalities described below.
1. Contingents
2. Logical configurations
3. Performance / match setup
4. Sales
5. Seating
6. Access control
Setup
1. Contingents
To implement such a process, the first step is to create, in Institution | Initialisation | Contingents, a contingent of type = “Target group”, as below. A “Target group” is the top of a hierarchy of smaller “Sub-target groups”, which will be associated later with sales quotas for every match.
There can be several target groups created, each corresponding to a broad set of customers, such as “General public”, “Commercial partners”, “VIPs”, etc…
Once the “Target group“ is created, a set of sub-contingents, also known as sub-target groups, should be created inside the target group. The sub-contingents created should cover all possible use cases, even if there won’t be any quotas for them on some events.
2. Logical configurations
On a logical configuration, it is then possible to define planned quotas for a selection of target groups and sub-target groups. There are two levels of quotas, both at target group and at sub-target group levels.
The principle is that quotas are set first at target group level, globally, then broken down inside the sub-target groups. There is no automatic rule to impose that the sum of quotas set for the sub-target groups are equal to the quotas set at target group level, but if this is not the case, then the quota management screen for sub-target groups will signal a non-blocking inconsistency.
Ultimately, for unseated sales, only the sub-target groups quotas are required, but it is recommended to define quotas also at target group level for avoid warning messages in setup screens.
Planned quotas can be set for logical configurations with or without a seat map, although the most common use case is for them to be set on configuration with a seat map.
At target group and sub-target group level, the quotas are defined separately for Purchase (P) and Complimentary (C) tickets, for each seat category. Total (T) quotas are indicated, corresponding to the sum of Purchase and Complimentary.
Sales are considered to be complimentary if they sold within a tariff that has the “audience type” = “Free” and to be purchase otherwise. The rule does not depend on the price of the ticket.
In Organisation | Venue | Logical Configurations, select a logical configuration and click the “Planned quotas” button to access the screen allowing planned quotas to be defined.
Inside the planned quotas screen, there are various sub-menus:
- Target groups: Allows the planned quotas to be defined for each target group and seat category.
- Sub-target groups > Pre-seating view: Allows the planned quotas to be defined for each sub-target group and seat category, and consistency checked with target group level.
Once planned quotas have been defined on one logical configuration, they can be copied to another one, also partially, through the “Change Planned quotas” button in the Organisation | Venue | Logical Configurations screen.
The system allows planned quotas to be administered completely autonomously from the process of assigning seats to contingents on the seat map. Both set of quotas can evolve in parallel. Once seating starts however, the two sets of quotas should be consistent.
If planned quotas are defined, the system will prevent sales from going above the planned quota, which becomes a hard limit for sales inside a sub-target group and category, independently of the number of seats assigned on the map. Therefore, if additional seats on the map are added to a contingent, the planned quotas should also be raised.
3. Performance / match setup
When a performance or a match is validated, similarly to the handling of seat maps, the planned quotas defined in the logical configuration are duplicated into new values that are associated with the specific performance or match, and are then administered at the performance or match level, instead of within the logical configuration.
In the Organisation | Catalogue | Performance / Match screen, using the “Planned quotas” screen, it is possible to see and update the planned quotas for a specific performance / match.
Inside the planned quotas screen, there are various sub-menus:
- Target groups: Allows the planned quotas to be defined for each target group and seat category.
- Sub-target groups > Pre-seating view: Allows the planned quotas to be defined for each sub-target group and seat category, and consistency checked with target group level, and mapped seats assigned on the seat map.
- Sub-target groups > Sales view: Allows the number of tickets planned to be compared to those allocated (= reserved and sold), and with various other quantities relevant to B2B sales (pre-requested, requested, validated tickets). This screen is read-only.
- Sub-target groups > Seating view: Allows a consistency check to be made between the planned quotas, the number of seats assigned in each combination of category and contingent on the seat map ( = mapped seats), and the tickets sold.
- Sub-target groups > Fulfilment view: Allows the number of tickets sold, seated, printed, and sent to be compared. This screen is read-only.
If necessary, it is possible to copy again the planned quotas from the logical configuration to the performance / match, in the Organisation | Catalogue | Performance / Match screen, using the “Change Planned quotas” screen. Is it also possible to copy only the quotas from one target group.
Operation
4. Sales
When using planned quotas, both front-office and back-office sales can be conducted without assigning any seats to the reservations or the sales.
To set this up, a front-office portal should have the appropriate parameter set in the sales channel. To go Institution | Initialisation | Sales Channels, open a front-office sales channels (of type “Internet B2C” or “Internet B2B”), and set the “Default seat selection mode” = “Without seating”, as shown below.
With this setup, customers on the front-office sales portal will be able to choose the number of seats required in each seat category (see below), but will not have any possibility to select areas or blocks, nor see any other information relating to their future seating, until this is decided later in the back-office.
It is possible to operate a resale platform before or after seating has been made. The display on the front-office portal is not controlled by the sales channel set-up, but by the nature of the tickets that are resold:
- If no resold tickets are seated, then the resale purchase process is identical to the standard unseated ticket purchase process, shown above: customers just select numbers of tickets from a big pool
- If all resold tickets are seated, the resale purchase process shows a seat map, and customers select groups of seats on a map.
- If some tickets are seated and others not, the resale platform is still functional, but the display might be confusing for customers, and this is not recommended. The display is shown below:
In the back-office, reservations and sales can be made with or without seating, independently of any setup parameters. It is not possible to prevent operators from making seated or unseated sales.
To make an unseated sale in the back-office, once the relevant performance / match, seat category, sub-target group (contingent) and tariff have been selected in the temporary cart, the “without seating” option, shown below, should be selected.
Tickets are then placed immediately in the cart, without any seat details:
A shipment mode and a payment method are then selected, as usual, to complete the sale. All usual rules about acceptable shipment methods apply. All payment methods can be used.
Unseated files can be processed in the back-office like normal ones, in order to make exchanges, cancellations, payment of reservations, or cancellation of reservations.
5. Seating
A dedicated module is provided in the sales context to perform all seating operations. The screen Sales | Seating | Ticketing is the main way to assign seats to unseated files.
The seating process is always performed for a single performance / match at a time, and consists of:
- Selecting a performance / match and a set of operations to seat, through various search filters (file status, category, target-group, sub-target group, tariff, contact, country of buyer, etc…)
- Manually choosing the seats on the seat map for the selected files, or asking the system to perform automated seating on them, using the standard seating algorithm. The system is designed to allow thousands of tickets to be seated automatically simultaneously, in a single step.
The system will allow reservations and/or sales to be seated.
Seating of tickets sold in a given sub-target group is only possible on the seats associated with the same sub-target group, provided there is at least one seat mapped to that sub-target group on the current performance / match. If there are no seats mapped to that sub-target group then sales can be seated on seats in the parent target group.
This is designed to facilitate the seating process:
- Either mapped seats are handled as big pot for the target-group as a whole, and they can be used for any sub-target group sale (this might be used for general public, for instance);
- Or seats are mapped individually to each sub-target group, and then seating proceeds individually in each pot (this might be used for internal sales / VIPs).
The same process applies to seating in configurations without a seat map. In this case, the seating process consists of assigning areas to files.
Advanced seating processes include linking files for seating (i.e. the possibility for customers to ask to be seated with other customers), and managing priority seating lists.
Files and be repeatedly seated and unseated, and seating changed, provided the tickets have not been printed or exported.
Once seats have been attributed to a file, they become visible on the front-office portals for customers, in the file details and in the list of tickets.
6. Access control
Unseated files already have tickets associated to them, and barcodes are already attributed, even though the seating is not yet defined. Therefore, such tickets should generally not be exported to any access control system, until the seating is finished.
To ensure such a restriction, there is a parameter that must be set (by SecuTix only) in the institution parameters, shown below:
This configuration will ensure that only PRINTED ticket are exported to the access control system. Once a ticket is printed, its seating details cannot be changed, so it is safe to send it to the access control provider.
This parameter is then used with all access control interfaces (SecuTix API for access control, Skidata Handshake, Orange StadAccess, …).
TBD – does with works with TnAC?
Next steps
Once you have a performance / match using sub-target groups and planned quotas, this opens the door to a sophisticated B2B sales process, using options, that can be used to facilitate the administration of events with over-demand. This will be the subject of a separate documentation.