RunSignup, Inc.has developed a system for MultiDay Timed Entry (MTE) Ticketing for Recurring Events that is Patent Pending. It will be published on the USPTO website in the coming months. The MTE version of TicketSignup is currently in Beta with several customers and we expect to release it in Q4, 2024. If you would like more information, please contact us.
Timed Entry Challenge for Legacy Ticketing Systems
Our next generation patent pending approach has three fundamental goals in our system for recurring events:
This is a common challenge of ticketing systems for events that recur since there can be tens of thousands of time slots with many parameters such as pricing, caps, questions, store items, discount and membership availability to each timeslot. There are a number of legacy vendors like Eventbrite, FareHarbor, TicketSpice and Showclix who have essentially slapped a thin veneer on their existing ticket system. This creates performance and scaling issues, as well as becomes difficult for event directors to manage these events and venues.
- Optimizing storage and retrieval of information in a multi-tenant SaaS system with hundreds of thousands of events each with potentially thousands of time slots over a period of decades. In other words a very large and complex database structure that needs to be optimized.
- Ease of configuration, setup, change and reporting for Event Directors in creating and managing their event ticketing for recurring events.
- Ease of signup for ticket purchasers.
RunSignup has solved this problem by developing a unique calendar based database architecture that allows for efficient storage and processing of recurring events, while also adding capabilities for both event directors and users.
Database Architecture
The key to the database architecture is a data structure that is optimized for time slots that re-occur over days or months. Traditionally this would be solved with data records for each time slot with potential duplication of meta-data such as pricing, sales windows, ticket caps, etc. RunSignup’s architecture utilizes a calendar rule based system that can represent tens of thousands of time slots with much less data. It can also represent multi-day timeslots that may not have an end date (such as a tour group that runs 4 hour tours every day for years) without incurring the data demands of all of the future timeslots. This unlocks efficiency from a data storage and retrieval perspective, faster execution of event director and ticket buyer applications and a system that can continue to perform well after years of multi-day timeslot data is accumulated.
Timeslot Rule Table
This sets the rules for how a timeslot can recur within a Day – for example there is hourly entry into a Halloween Haunt or a Botanical Garden. If Weekday hours are different than weekend hours, then 2 rules could be set up.
The key parameters for defining the start times:
- ID and Name
- First Slot Start Time (eg. 10AM)
- Slot Duration and Slot Offset (eg. 1 Hour and 2 Hours)
- Number of recurring Slots per Day (eg. 6 Slots)
The examples above would set 10, 12, 2, 4 and 6 as the start times for each 1 hour slot.
The other key fields connect various settings to a rule – for example which ticket levels are available, pricing, caps, etc.
This is an immutable table except for the Name. This makes sure that tickets sold associated with the rules tied to this table are kept permanently. It’s also immutable because exceptions to the rule depend on the start time of each slot. Using the example given above, let’s say we changed 12pm to 1pm if the rule is mutable and we changed the slot offset to be 1 hour instead. The new time slots would be 10, 11, 12, 1, 2, and 3, now the exception is incorrect because it was meant for the 2nd occurrence of the rule, but 12pm in the updated rule is actually the 3rd occurrence. The tables below accommodate changes like this.
Timeslot Additions Table
This creates timeslots that are not a regular pattern defined by the rule – but they can associate with the recurring rule settings. This is useful for making the event management applications easier to build and understand. For example, someone might want to add a 5:00 timeslot, or change the duration of the 12:00 timeslot to be only 30 minutes.
Calendar Recurring Rule Table
This takes a Timeslot Rule (and Additions) and makes it repeat on a certain pattern (Note this is not necessarily tied only to the timeslot rule, so it can be used for other applications as well in the future). This is a concept that iCalendar systems have and we all use to set up weekly meetings on popular calendar applications. For tickets, this is useful because a Halloween Haunt might have common hours every Weekday except Monday (closed), and different hours for each Saturday and each Sunday of October. This is also very useful for admissions types of applications where a Botanical Garden would be able to set up tickets once and it would last for years – easy for event directors and much more efficient from a database perspective.
The Calendar Recurring database table is very efficient. It uses a bitwise database field to set:
- Recurring Days of Week
- Recurring Days in Month
- Recurring Weeks in Month
- Recurring Months
- And an ending Timestamp
With our Day of Week design covered below, we basically create a rule for each day of the week. So if you event is open for 2 months, this table consolidates all the Friday information for timeslots, pricing, caps, etc. This is one of the keys to the enormous database efficiencies this patent pending technology brings to recurring events.
Exceptions Table
This table is used to define things that are different from the defined rules – different duration, different time, different ticket levels (canceled ones), different time slot config for specific ticket levels, different calendar recurring rule.
This includes both regular time slots and additional time slots:
- When changes like time slot start time, duration, canceled, or cancel ticket level occur, we will add a row.
- Used to figure out if it’s an exception for a regular time slot or an additional time slot.
- Used to apply the exception only to one level.
- Used to apply the change to more than just one day.
- If editing a time slot with ticket levels that have sales already:
- Warn the director about it.
- Update for affected sold tickets.
- Allow sending notifications to affected ticket holders.
Data efficiency:
- When adding a new exception, we check for previous related exceptions, and see if we can delete them. An example would be if I changed the start time twice, the first time change I made is useless now and can be deleted. We would need to make many checks to verify if the previous exception is delectable, but for now, we will go with:
- Check if the previous related exception(s) doesn’t have a calendar recurring rule, then it’s safe to delete since we know it’s only for the affected date time.
- Check if the previous related exception(s) Have the exact matching calendar recurring rule definition, in that case since the new rule completely overlaps with the previous one(s), they should be safe to delete.
- Check if the new exception, in combination with previous exceptions completely overlaps another previous exception. If this cleaning method is too computationally intensive for each edit, we can use a daemon to clean up the database every once in a while.
- When making an edit, we always consider if the same result can be accomplished without adding an exception first, so we don’t keep on having to pull down redundant data. An example would be if I added an additional time slot that continues from Monday to Friday, and assigned ticket level “Admission” to it also from Monday to Friday. In this case, if I want to cancel all “Admission” ticket levels from Monday to Friday, instead of creating an exception for it, it may be better to delete the ticket level assignment. That way, we no longer need to pull in data about the ticket-level assignment, and any exception.
Additional Tables
There are other database tables that help with changes and exceptions, as well as keeping an audit trail of settings and changes that are made by event directors.
There are also tables that get created to hold the associated settings for all the applications like pricing, caps, discounts, etc.
Algorithms and Functions
We have created a set of common algorithms and functions that create an abstraction layer to the data structure and a standard way to interact with the data that can be reused across the applications including setup of timeslots, rules, exceptions and additional information, retrievals of that information for display purposes in the Event Director Dashboard or in the front end Website and purchase path of ticket buyer, as well as ticket purchases, and reporting of ticket purchases and all financial transactions.
Event Director Dashboard Applications and User Experience
There are a variety of applications that event directors need to set up and manage a recurring event.
- Features by ticket level (type, like General Admission, Kids, VIP, etc.), time slot rule, or time slot
- Time slot rule – group is external name
- Other features – pricing, caps, coupons, store item availability / bundle, season passes, rules for transfer, etc. The above database structure allows for additional applications and database tables to be added incrementally, providing a platform for future growth and ability to meet customer needs.
- Incremental features can be added
Setting Timeslots and Timeslot Groups
Timeslot Groups in the Event Director Dashboard are the equivalent to Timeslot Rules. Event Directors can easily add Timeslot Groups with the interface below. In the Schedule interface, we show the timeslots that have been setup (we also have a Day of Week approach, which is the default explained later for ease of use, but uses the same infrastructure):
If we click on a day, it opens up the Timeslot Groups defined for that day. In this example, there is one Timeslot Group called “Saturday Daytime Timeslots”. The gear icon next to the name allows for editing of the Timeslot Group. This functionality will include adding, changing and removing timeslots within a day as well as adding other days to the Timeslot Group.
We will come back to the Pricing buttons associated with the TImeslot Group as well as each Timeslot in another section.
You can also add other Timeslot Groups. The example below adds 2 evening events that are 1 hour in duration with the first event at 7:00PM and the second event at 8:30PM every Saturday from April 13, 2024 until August 24, 2024.
The other key item is defining which tickets can be purchased in a timeslot. For example, if there were Child tickets, those might not be available for the evening timeslot group.
The large Schedule interface is updated:
And the day view is updated to show two Timeslot Groups:
Pricing
Tickets (called Ticket Levels in the code) can have advanced pricing rules set up on an overall basis in the dashboard. This will set a default pricing for all Timeslot Groups as well as Timeslots.
Ticket purchase Schedule is the first set of parameters to set. We offer any combination of scheduling:
- Ticket Sales Start
- For all timeslots on a set date (the example above – which is 05/25/2023)
- Set number of minutes/hours/days before a timeslot begins. This is useful for events that repeat over a long period of time where you do not want to sell tickets more than say 90 days in advanced. This can be done on a specific day or specific amount of time before each timeslot. For example, all tickets for April 1 would go on sale on January 1 at midnight. Or on January 1, tickets for the 8:00AM timeslot would go on sale at 8:00AM, the 10:00 timeslot would go on sales at 10:00 AM on January 1.
- Ticket Sales Close
- Ticket sales for a timeslot can close a set amount of time after or before a start time. In the example above, we set sales to close 15 minutes after the start time. So tickets would close at 8:15AM for an 8:00 start time. This can also be a negative number, so tickets could close 1 day before the timeslot.
- Ticket sales can also close on a specific date. This can be useful for events that want to sell all of their tickets say 10 days before the first timeslot starts. For example, a festival might need a specific headcount to know how much food to order.
There can also be multiple purchase periods, which accommodates price increases. For example, prices could be $10 if purchased 90 days before a Timeslot and $15 if between 7-90 days before a Timeslot and $20 if within a week of the Timeslot. This obviously helps events increase more up front cash flow and build a base of ticket buyers who can spread the word about the event.
Volume Pricing is also available in this setup with discounted pricing for buying more tickets. In this example tickets are $10 if 1-3 tickets are purchased, but the price drops to $8 if more than 4 tickets are purchased.
All of the pricing options are available on a per Timeslot Group or individual Timeslot basis from the Schedule page.
Additional Settings
We are adding a variety of additional settings – caps, coupons, store item availability / bundle, season passes, rules for transfer, etc.
Day of Week Design
We have added a simpler experience that most event directors will be able to use based upon a Day of Week design. Most recurring events have similar hours on each day of the week. For example, an event or venue might be closed on Monday and Tuesday, Open during afternoon hours on Wednesday – Friday and afternoons and evenings on weekends. Prices might be higher on Friday and Saturday. To accommodate this common use case, we have a Day of Week Wizard and Management that makes setup and changes simple and easy.
Picking the days when the event is open is simple and quick. We have quick selection buttons for things like all Saturdays or all weekdays, and then each calendar dates is a simple click to toggle open or closed:
The wizard allows event directors to create a rule for each day for each ticket type – the rule includes special pricing for that day, the timeslots and the caps per timeslot. These can all be changed and controlled on a per timeslot basis once the quick wizard is finished:
Once copied for a day, it is simple to copy to other days:
And then modify a weekend day with increased pricing and with expanded hours. In this case Friday:
The wizard makes it easy to see what has been done, edit things, and copy from one day to others:
Management
Once the MTE event is created with the wizard, event directors have a full function Dashboard to do management and reporting. Management allows to looks quickly at a calendar based schedule and edit.
TicketSignup MTE has management capabilities from a month view Schedule. Simply click a day on the month view calendar:
Note the 4 buttons on the top that allow for editing Timeslots, Pricing and Caps as well as taking Attendee Actions like Email or cancel a day. There is a clear view of the day that shows summary information like ticket sold and cap as well as price range for each timeslot.
The reason we can do this so easily is that we have a calendar architecture underneath. It is like changing the start time in your calendar app for a recurring meeting for just one day, or for all future days. That is simple in your Google or Outlook Calendar for a reason. And we have that same capability.
Calendar Based Reporting
Looking at traditional row and column tabular reports is hard for recurring events. Calendar based views provide quick and easy viewing of the key metrics of your timed entry event. This allows you to manage your business better – staffing properly, knowing when to increase prices for dates that are approaching sell-out, or marketing dates that are lagging.
Legacy systems like Eventbrite, FareHarbor, TicketSpice and Showclix do not have the database architecture to pull this off because the queries are too difficult. And they are not dedicated to a new way of doing things like TicketSignup.
Here is an example of a ticket sales report with a drill down of a single day to see details below. Note the color shading to easily visualize the busiest days:
We also have date based analytics for when tickets are sold, including tracking of source like websites (like Google), specific tracking codes (for your ads) and email:
And our Ticket CheckIn app will show checkins by day and timeslot in a variety of ways:
Changes and Exceptions
Legacy products like Eventbrite, Fare Harbor, TicketSpice and Showclix sometimes have difficulty with changes. This is because the definitions are very separate. So changing the price (or caps or timeslots) for all future Saturday evenings is hard. With our calendar based data architecture, it behaves a lot like your calendar if you are updating the time for the Monday meeting or adding a person to the Monday meeting, those changes can be made for all future Mondays with a simple click of a button.
We also allow fine grained editing of any combination of times, ticket types, date or individual timeslots. For example, if you want to edit pricing, pick the day, and click Edit Pricing. That will enable you to pick what combination you want to change pricing for.
Picking an individual timeslot, you can change the pricing. And the pricing has advanced capabilities like going on sale on a date, and then increasing 3 days before the timeslot and then close 15 minutes after the timeslot starts in this example. Also note that you can then copy this setting to future.
Ticket Buyer User Experience
We offer a wide variety of options for displaying calendars and information. For example, the large calendar can show a full month of data including information like tickets available and pricing. Due to the calendar based database design, it is very fast and efficient.
And we offer a number of options for event directors to put the information they want:
Our architecture allows for picking the various options in any order during the purchase experience:
- Date
- Timeslot
- Ticket Type
For example, this shows picking Date -> Time -> Tickets
And this options is Date -> Tickets -> Time
We will be having a variety of user experience options for event directors to choose from in addition to these. For example, the date picker options will be:
Additionally options to group elements together – such a Mornings and Evenings. Displays will also be dynamic to show sold out dates, timeslots and tickets.
Summary
TicketSignup has developed a Patent Pending system for MultiDay Timed Entry Ticketing for Recurring Events. This is a common challenge of ticketing systems for events that recur since there can be millions of Timeslots across thousands of events with many parameters such as pricing, caps, questions, store items, discount, season passes, and membership availability to each timeslot.