Seat Allocation Business Rules - Ticketing

[jamienz]

Hi team,

It started as a bit of an experiment, but we have ended up building our own 'in-house' ticketing management application.

To further the development, we have decided to develop an 'intelligent' seat allocation module and are currently trying to formally define the 'business rules' that apply when we (as humans) allocate seats.

Obviously, when you're a human looking at a paper seating chart, it is easy to see gaps and avoid assigning tickets that are going to cause widowed seats or problems in the future using intuition - it's not so easy to define these as rules for a bit of software! =/

If you were to 'define' the rules you apply when assigning tickets, what would you be looking for?

The types of rules we have so far are pretty basic, including things like:

* Allocations must not 'widow' either a single or group of three seats.
* Allocations must not be made across sections (i.e. avoid seating people over a walk-way or gap)
* If an allocation of 4 or more seats is being made and it is not possible to allocate these in one row, they can be split across two adjacent rows (i.e. assign A1, A2 and B1 and B2 so they're sitting behind each other).
* Where possible, 'convenient' gaps must be filled. In our seating charts, seats are 'ranked' from best to worse to allow easy allocation of seats, but also have a 'ranking category' which is often the same/linked to the tier of seat it is. If a patron requests three seats, and there is a 'gap' on the map of three seats, the system will automatically allocate these as opposed to the 'next best available'. This will only happen for seats in the same 'ranking category', and only for exact number matches.

So - any thoughts? What kind of rules do you think about when allocating seats? Do you have any comments on the above rules that we are building already?

Cheers

Jam.

 

[cpf]

You could use simulated annealing, which would let you assign an "undesirability score" to each potential seating mishap, then let the computer grind through permutations until it comes up with a best-case scenario (even when a perfect layout is impossible).

The downside of that being that no-one would know their seating position until all ticket sales closed. You could get around this by running the algorithm on each sale, only letting it move the yet-to-be-bought seats while keeping purchased ones in their original positions. This would also make the annealing part of the simulated annealing a bit easier to code.

 

[derekleffew]

... * Allocations must not 'widow' either a single or group of three seats. ...

I've always thought Scattered Singles would make a good name for a play about theatre-goers.

Back in the dark ages (1980s), when we used "hard" pre-printed tickets, the first thing we would do when a new batch came in, before putting them on sale, was "clip triples." This involved putting a paper clip on the end of each set of three tickets left in an odd-numbered row. Only after all pairs had been sold, was it permissible to "break triples." After that, we could sometimes sell the singles to couples, by telling them, "I have two good seats, but they are not side-by-side, they're in front of each other, on the aisle." Try to keep your singles on the aisle; they're easier to sell and the ushers can sit in them once the show has started.

This was for 300-500 seat houses in Chicago for open-end run shows, and may not be applicable to larger or smaller theatres, or one-off dates.

Hope this helps.

EDIT: Perhaps due to the "triples" process, I prefer the term "orphaned" over "widowed" when referring to singles. Go figure.

 

[JChenault]

Generally I like the approach. Some comments.

Your algorithm seems to assume that the majority of sales are in multiples of two. While this seems reasonable, I would do some data mining to verify.

I think you need to think about season subscriptions. I would probably let your season subscribers have their same seats.

I could not quite parse your 'convenient gaps' section - but I think the model of ranking best to worse may be too simple. For example how do you handle requests like 'on the aisle'. Or 'close' or 'center'. The point is that a different patrons value the same seats differently.

It could be over engineering, but you might want to consider multiple ranking systems ( close, center, handicap, aisle etc). You might want to model your widow seat as just another ranking system. When a customer asks for a seat, you would apply an adjustment fact to the ranks for each seat.

 

[jamienz]

Hey all,

Thank you for your comments!

@cpf - Hmmmm, it would be cool if we could do this but we need to assign seats 'live' so waiting for everything to close to complete the allocation process wouldn't suit our requirements. At present, the 'planned' implementation sort of does this on a sale-by-sale approach, as it tries to fill gaps that appear so we can get to the 'best-case scenario'.

@derekleffew - Hehe, interesting thought though! I think if singles are required, as you've suggested it would be best to keep them on the end of rows.

@JChenault - We worked on the assumption that most sales are in groups of two, or more than three. I don't quite recall how we came to this particular train of thought but it is definitely something we need to investigate further (I think something along the lines of if a gap of three is left, and two are sold - the most common number sold in a group - it leaves a single again).

I really like the idea of adding multiple rankings. Although we originally designed this to be quite a simple 'best seats available' picker, it may be worthwhile adding the ability to request certain seats (aisle, etc). A different way to go about this would be to add a flag to all seats that are on the aisle so we can just search those if that particular attribute is required. The only problem I can see is how much are patrons willing to trade off 'good seats' for those on the aisle? I can imagine all the aisle seats selling out and the 'best aisle' seat being in the last row when we have perfectly good ones available front and centre.

The 'convenient seat' gap filler function works something like this: say you have two rows, with three seats in each. Row 'A' is the best available and Row 'B' is ranked second, but both are in the same tier/ranking category. At the moment, all of Row 'A' is available, and two seats in Row 'B' are available (one is sold). A patron comes along and requests two seats: although Row 'A' is the best available, the algorithm will assign the customer to the two remaining seats in Row 'B' because this 'conveniently' fills the row without trading off seat ranking too much. Obviously in this case, placing the customer in Row 'A' would break the widow rule anyway, but this is just an illustration.

Season tickets is not something we have gotten on to yet... but our maps have the ability to 'hold' particular seats that can then be manually assigned. This may be the best work around to give patrons the same seats for their season pass.

As always, any more thoughts are appreciated

Jam.

 

[cpf]

Oh, just re-read your post, is this an automatic system to guide human operators? If so, could you just condense everything mentioned in this thread into a few bullet point tips that are automatically filtered based on the situation, then shown to the operator during seat selection? You could also combine it with some UI tricks like automatically grouping the seats to "fit" any selected open block, colour coding seats based on seating efficiency, stuff like that. That way you can keep the "human factor" involved while avoiding mistakes. Not sure that I understand what these rules are for, though.

 

[jamienz]

Oh, just re-read your post, is this an automatic system to guide human operators? If so, could you just condense everything mentioned in this thread into a few bullet point tips that are automatically filtered based on the situation, then shown to the operator during seat selection? You could also combine it with some UI tricks like automatically grouping the seats to "fit" any selected open block, colour coding seats based on seating efficiency, stuff like that. That way you can keep the "human factor" involved while avoiding mistakes. Not sure that I understand what these rules are for, though.

Thanks for the suggestions!

The application is designed to run stand-alone on our patron front-end (it picks the seats according to the patrons requested tier, etc), but does run in an 'assistance' mode for our operator back-end. On the back-end, the system will 'suggest' the best seats available and also highlight seats dependant on their rank so the operator can make their final decision.

At the end of the day, the implementation of this is to increase efficiency when assigning seats - as opposed to trawling through manual seat charts, etc. There will always be human oversight to steer the algorithm in the right way (for example, adjusting ranks if the map is getting messy or assigning different seats if the application has messed up) but it's to add a little automation to it all.

Jam.

 

[Cashwalker]

A suggestion, on our ticket reservation page, I let the patron choose general seating preferences, such as in the middle, to either side, on an aisle, near the front, near the back, etc. It's just a form input through sendmail, we still have a human setting up the seating charts...

 

[museav]

Many years ago, literally back in the days of terminals, VAX and PDP mainframes and tractor feed printers, I was a 'guinea pig' for a proposed Systems Engineering curriculum that focused on areas such an applying optimization to real world problems (routing snow plows and the truck that paint the lines on the streets in the most efficient and effective manner were two projects that sprang out of that early work). The general process was to break the problem down into a series of equations that could then be simultaneously solved, using some newfangled parallel processing technology to speed it up, to optimize various selected factors. The determination of all of the relevant equations and any related weighting factors was the challenge then and seems to be the aspect you are addressing.

You want to include some simple yes/no differentiators such as whether they will accept 'widowed' seats or consider a different pricing tier if it meant being able to get more of what they want. But there may still be subjective aspects that simply cannot be calculated and would have to be defined, for example I have certain seats I prefer at one local theatre because you generally get the best sound there, something that due to both being subjective and a personal preference may not be easy to include in any predictive model. Unless you somehow can include factors for sightlines, ease of access, audio quality, adjacency to restrooms/beverages, relation to exits, etc.