Contiguity Best Practice?

Hello all,

After some recent issues with my Best Seat Maps, I was hoping to check how other orgs implement the contiguity in their Facilities.

When defining Contiguity, do you:

  • Select a single row and define the Contiguity, allowing the value to increment by 10 on each row.?

Or

  • Select a group of rows if they are physically together and apply the Contiguity all at once?

I have been relying on the 'Validate Completeness' to check my Contiguity, and having used the first method I would then get an error while Best Seating large number (larger than the seats in a single row). 

After trying out the second method above, I did not see the error any more.

Thanks :)

Parents
  • Nicholas –

     

    From a Network standpoint, best-practice recommendation is that each physical row be its own contiguity row value. Absent such individual contiguity, Tessitura doesn’t “know” that row A is in front of row B, which is in front of row C, etc; applying different contiguity rows to each physical row establishes an order which is used by the Vertical fill pattern to determine priority of each row in the best-seat zone- just as contiguity seat numbers determine the order of seat positions across a row and the behavior of the Horizontal fill pattern. If you /don’t/ have different contiguity rows for separate physical rows, then the best-seat routine considers them all as if they’re in one long continuous row, and fills that one long continuous row according to the Horizontal fill pattern selected – which can lead to unexpected results if you want it to fill from the front row to the back but your horizontal fill is set to “Center Out”.

    Lastly, it’s to be expected that you might get errors when best-seating in a section that uses separate contiguity rows. Since only seats in the same contiguity row and with consecutive contiguity seat numbers are “next to” each other, then the best-seat request will fail if that number of contiguous seats can’t be found. So if your widest row is 10 seats and you request 12 – or if 4 seats are available, but only as 2,1 and 1 - that’s not an error but a recognition that there aren’t that many seats available “together”. The Validate Completeness check when building a facility doesn’t check to see that your contiguity, row lettering, seat numbering etc. is /right/ - just that there is a value for each of these things applied to each seat.

     

    Hope this helps,

    Jonathan

     

    From: Tessitura Ticketing Forum [mailto:forums-ticketing@tessituranetwork.com] On Behalf Of Nicholas Hudson-Ellis
    Sent: Sunday, August 26, 2012 9:08 PM
    To: Jonathan Smillie
    Subject: [Tessitura Ticketing Forum] Contiguity Best Practice?

     

    Hello all,

    After some recent issues with my Best Seat Maps, I was hoping to check how other orgs implement the contiguity in their Facilities.

    When defining Contiguity, do you:

    • Select a single row and define the Contiguity, allowing the value to increment by 10 on each row.?

    Or

    • Select a group of rows if they are physically together and apply the Contiguity all at once?

    I have been relying on the 'Validate Completeness' to check my Contiguity, and having used the first method I would then get an error while Best Seating large number (larger than the seats in a single row). 

    After trying out the second method above, I did not see the error any more.

    Thanks :)




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Ticketing Forum. You may reply to this message to post to the Ticketing forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Hi Jonathan,

    Thank you for sharing that advice. It's good to know that the errors I was seeing is actually just Tessitura saying "I can't set this request all at once" rather than just an unexpected error.

    The example I was dealing with is for an exhibition with timed entry, meaning that it is not a GA Facility, as sections are the entry time periods. One of the ways the error was presenting was on the web, which was confusing to customers.

    From what you say, it sounds like there would not be any adverse consequences to defining contiguity in "multi row" blocks for this style of Facility and ultimate use by patrons.

    Thanks again!

    Best,

    Nicholas

Reply
  • Hi Jonathan,

    Thank you for sharing that advice. It's good to know that the errors I was seeing is actually just Tessitura saying "I can't set this request all at once" rather than just an unexpected error.

    The example I was dealing with is for an exhibition with timed entry, meaning that it is not a GA Facility, as sections are the entry time periods. One of the ways the error was presenting was on the web, which was confusing to customers.

    From what you say, it sounds like there would not be any adverse consequences to defining contiguity in "multi row" blocks for this style of Facility and ultimate use by patrons.

    Thanks again!

    Best,

    Nicholas

Children
No Data