We would like to add a checkbox on the TNEW payment screen that the patron must click to proceed forward, stating that they agree to our covid protocols (mask, vaccine/negative test check). We are trying to avoid patrons claiming that they did not see it during the checkout process. Is there a way to add this in? We are currently using TNEW 7/
This may exist already, but I'm not 100% sure how to search for it or what term I should be using for it.
Any help you can provide would be greatly appreciated! Thank you!
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.
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.
We had a similar issue with a checkout survey where we couldn't set the CSI type to auto-close (basically, if the survey had data someone had to address it in short order, if it had no data it was useless). I built a SQL Server Agent job to routinely go through CSIs of that type, and if they lacked data (non-trivial to determine, at least to me) delete them.
Hey Jamie, I've brought up your solution to our Marketing Team and they were wondering if you would be willing to share the code that you inject into Google Tag Manager? Let me know! Thanks, Katie
Here's Luke's code snippet and his intro notes. It's not precisely what I have running--if I remember correctly, the main changes were simply that I use a different question type and I updated the text of the error message--but it's certainly the bulk of the work.
To see the code, open the attached file and View Source. Or use your preferred trick that accomplishes something similar.
(i'm having trouble with the attachment. It looks like it's getting added but then it doesn't show up where I can see it...I need to publish to know if it's actually here or not.)
Try this access. Permissions should allow readership by anyone with the link. drive.google.com/.../view
I can see it! Thank you so much!!
Jamie this is awesome! Thank you and (thanks to Luke) for sharing it!