We have recently discovered that our web orders have the wrong performance for our permanent collection (we are a museum) because the performance relative button is using the order date as the guideline.
So, the guest is buying tickets for a future date online, and then they come in to the museum to have their tickets printed. We are "checking them in" by using the permanent collection relative button, which is defaulting to the order date instead of today's date. So the attendance is being captured for the wrong date.
Has anyone else had this problem, and what have you put in place to help correct the issue?
Anyone have any thoughts?
Hi Angela,
I had a similar issue at a previous organisation and the only fix that I could find was to stop using the relative buttons and manually changing the Quick Sales layout every day so that the correct performance would display.
It's probably not the most ideal solution though. The processes changed the next year after that and then customers were able to buy open-dated vouchers online, and a nightly script was run to convert the scanned voucher into a ticket for the date they attended, assisting with reporting. If that sounds like it could be useful I'm happy to pass you on to my former colleagues for more info.
Tim
I think I'll put in a ticket and see what comes of it. Maybe support has had similar issues and can offer a work around. The voucher idea is a great one, but not likely to work well in our organization since we have daily performances for most of our exhibitions. Thanks to all!
At a museum that I used to work for we scanned the e-ticket to bring up the order, returned the tickets and used the funds to buy a performance for today's date. We had "hot keys" to automate the transaction. Just another option for a workaround!
Best,
Jennie
Jennie - What do you mean by "hot keys"? Your solution is intriguing...
AutoHotKey has been mentioned a few times before on these forums — it's an automation technology that can be generally applied on Windows. http://ahkscript.org
For example, instead of needing specially programmable keyboard hardware, an AHK script could be written to take predetermined actions on the Tessitura application interface when it notices specified input sequences from the keyboard or other input devices like barcode scanners and MSRs.
Thank you Nick and Jennie! This was very helpful. I'm not sure we have enough of an issue at this point to pursue these avenues, but it helps to know what other organizations are doing. :)