Add a checkbox that patron must click to complete order agreeing to theatre covid safety protocols

We have this set up on our checkout page. We set it up in system tables under LTR_TNEW_CUSTOM_FORM_DATA

Exactly what we did as well at the Sunset Cultural Center. I will say that it has helped me squash many an argument at the box office regarding vaccination/masking. 

That solved it! I was only looking at the TNEW side and not in the system tables. This is a tremendous help. Thank you so much!

What steps did you take in the system tables?  We are looking into doing something similar.  We have a line added to the table but we are not receiving the CSIs that should kick back once the check box is checked. Thank you in advance!

In LTR_TNEW_CUSTOM_FORM_DATA you add a line:

Then under optional value you can name it whatever suits your company. This is what we used:

I forgot to mention that you then need to go to LTR_TNEW_CUSTOM_SAVE_DATA to add a line item there so it saves a customer service issue in the patron's account on the back end:

My process was exactly how Amber outlines it below, but I will add that we had to change a setting in TNEW to get the checkbox to appear.

On the TNEW admin side under Page Editor: Payment section, we set checkout survey displayed to True. That may be the case for you already, but it wasn't for us initially.

You can change some the text and settings in Component Editor: Checkout Survey

Thanks so much Amber, we have those in place but we are still not seeing the CSIs come through when a patron checks the box and proceeds through the checkout process, I wonder if there is a setting in TNEW we are missing?

Two cautions:

1) If you do a checkout survey, all patrons will have to check it, regardless of what they are checking out (i.e. Gift Certificates, Donations, Streaming Events, etc.)

2) If you do a performance survey, those are incompatible with SYOS.

Thank you for the cautions - a few questions:

1) We did consider that GC and donations would have to check it as well but could not find any other way to get the checkbox to appear other than displaying as a checkout survey. Is there any way to make it appear, and hopefully specifically to live ticketing?

2) We've had ticket purchases since implementing, and have tested ourselves, and patrons and ourselves have been able to use the SYOS map correctly. In what capacity does the survey affect SYOS?

TNEW is not necessarily my forte so apologies for any rookie questions.

You are basically stuck with the survey coming up for everything if it is a checkout survey.  Performance surveys, which are tied to keywords and only appear if the performance product in question has the specified keyword attached, are presented prior to reserving tickets in Best Seat, but haven't been integrated into the SYOS reservation flow, so if a customer reserves a ticket via SYOS they simply won't see any survey placed on that performance.

Got it! I didn't initially recognize that checkout surveys and performance surveys were different. Thank you.

With some community help ( @lukemckenzie), I tackled this back in in Sept.

Our TNEW site uses the Quick Start Template, so we effectively have no access to any true code portion. However, we do have Google Tag Manager running on it and used that to inject code that determines whether the checkout survey question is visible or not, based on Product Types in the cart. If Product Type X is present, then the question displays. If not, then it is hidden. Should someone have multiple product types in their cart, having Product Type X is still the determining factor. However, the only reason I want it hidden is if it DOESN"T apply, aka no seats at all or only seats to something with a different policy (our schooltime performances), so this is the right fit.

Our code snippet only manages one question since that's all we needed, but it could be expanded to have alternatives (eg if has X, then display Q1; if has Y, then display Q2).

I use a type in question, asking for the purchaser's initials. I wanted something a little less auto-pilot than a checkbox, and I very much prefer the patron-specific paper trail this leaves, should an issue come up and we have to look up the attestation. 

The one drawback of this strategy that I have noticed is that the CSI is created for each order. It won't have the answer stored in it so it's clear enough to not ultimately be a complication, but it feels/looks like clutter. We can auto-close them of course so we're not seeing them everywhere, but I do keep forgetting for a split second when I happen to catch them when I'm looking at something on individual patron records.

At the risk of suggesting a non-ideal/hacky solution, in order to avoid the CSI clutter, could you not "set up" the CSIs with an improper CSI values?  That is, specific Contact Method/Category/Activity Type/Origin for that particular form that CANNOT work and properly create a CSI in Tessitura?  My understanding of the set-up is that, if those cannot actually be used to create a CSI in Tessitura, it just will not do so, though the form itself will work.

That is in fact what we have done.  We have a web checkout form that has two questions; one which we have always had, that updates the order source number, and the second, more recent, Covid checkbox.  We definitely do not need those creating CSIs, so we just made sure the data it is trying to input is non-functional.  Of course, this only works if you for sure do not actually HAVE checkout data that you want collected.  But, if that were the case, I assume one would not be worried that a CSI was created for every order.

Just a thought.

John A. Moskal II

We very much want the "paper" trail for the CSIs that ARE completed--it's the legal proof that someone acknowledged the policy (or, more realistically, was offered the opportunity to read the "fine print"). It's the CSIs that come from the patrons who aren't buying public performance tickets that throw me off when I spot them. Mostly because I have that moment of 'wait, the teacher has that CSI?! what stopped working?!?!' before I remember how it actually works. But there aren't too many of those orders and the auto-close function addresses the real 'clutter' aspect of it.

These do also go to unique CSI, so they are very easily identified as ignorable until we have to research something specifically. At least for everyone except me and my 'wait is it broken?' gut reactions.