If someone mistakenly marks a seat attended when stubs are being scanned, is there a way to fix that? We aren't set up yet for scanning tix when people enter the theater, so we have to manually do it with a handheld scanner when the show is over, and once in a while, errors are made.
Can you describe what you mean here by an error made when scanning tickets that needs to be reversed? I have a hunch that there may be a misunderstanding about how Tessitura records attendance from stubs.
People will bring the wrong tickets for a future show, and if the person taking tickets doesn't notice, the tix get torn and put in with the night's stubs. If that happens to be the first stub that gets scanned after the show, the person doing the scanning won't notice he/she just scanned a ticket for a future show until the next stub gets scanned. Does that make sense? So, we now have a future show with a seat already marked attended.
Gotcha -- yes, this happens to us too. The workaround for this within the app is to return, reseat, and reprint the customer's tickets. Typically, that's appropriate anyway since the customer will need to pick up their tickets again from Will Call.
Another approach you might be able to incorporate to help with the root cause of the problem would be to have each ticket taker responsible for stacking all of the stubs they collect, bundling them up, and putting their name on them. That way when the stubs are being scanned later (probably by a supervisor), and Tessitura throws an error about the performance being different, you can give some feedback to the person who failed to check the ticket date when they were ripping tickets.
Thanks for the advice!
That process results in over stated attendance numbers as the attendance record will still reside in T_Attendance after the return. This will matter to organizations that are not a performance based and rely on scan counts for their attendance.
I recall submitting an enhancement request about this at least a year ago. To me, it does not make sense to keep the record scanned in as attended once the ticket that was recorded as attended has been returned. But I do not recall anything as having been done about this, so maybe more enhancement requests might help.
Just because a ticket gets returned does not mean it should have its attendance deleted as a ticket upgraded to a membership systemically is no different that a ticket that was returned.
Using the new membership to scan back in the attendance after upgrading the tickets is not an option as it skews the time on the attendance for those of us who track attendance by time intervals.
Most importantly simply delete records from T_Attedance is not an ideal solution as an attendance report run today for how many people entered the facility between 9 and 10 could result in completely different numbers when run 1 month from today due to records that were deleted from the table.
Historically the various ticketing systems I have worked with have all had the option to void the attendance. This action did not delete the record, instead it put in an offsetting record reversing the previous entry. This provided an audit trail as well as providing reporting consistency.
In addition to void functionality the ability to record failed authentications and overrides was equally important.