Does anyone out there have a good VERIFICATION report for checking your performances? I've used a variety of ticketing systems in the past and always had to struggle with checking that I got everything just right. I've built this in sql and reporting clients in the past for other systems, but I'm new to being a Tessitura client.
Help?
Mark Levine,
Not so much a report to evaluate the work you have done, but we have a crucial checklist built as an extensive Excel document that we call a "build log" that is used by the staff that build our events.
There is an entry for everything on it. From the basic things like the performance name, to keywords, to MOSes and Offers, Price Type Templates and even optional things like individual Content Tab items. It is detailed and specific, and outlines exactly what information is supposed to be represented in each section and, when relevant, whether it is supposed to be built on the Performance level or Production Season level (or higher). The builder also indicates their initials in that column so it is known who built each event.
Importantly, too, whoever is building the event checks off each element (with an 'x') after they have added it to the event, or, in the case of items that are not added to that event, they check that off as well (with an 'o') so as to indicate that that item was considered and intentionally not added rather than just "maybe not done yet".
Lastly, when the event is fully built and "ready", the builder lets someone else know so that they can go over everything again, proof it, and add their initials as well when done. Maybe it is not as fluid as a report which would collate everything together, and yes, it takes a little bit of training to make sure one is proofing in detail rather than just assuming that the builder got it right in the first place, but we have found it to be highly effective in terms of catching most of the issues prior to putting something on sale. And, when something ends up slipping through the cracks, you can often go back and look at the log and, not place blame because that rarely helps, but to use it as a learning moment to recognize what happened (e-mail correspondence that did not go to each member of the team, misunderstanding of how one particular element works, etc...), and then to update the build log and/or practice of communication to avoid that from happening in the future.
I first built this guide for my own use back in 2013 as I had to get the buy in of the Box Office Manager back then. But once it started being regularly used, it has undergone many transitions and evolutions. It is now a fully integral part of the build process, and there are now two separate documents, one for proper performances and another for education events. Things just do not get built now without going into the build logs. Again, nothing is perfect, but this works extremely well for us. As well as being useful for training new staff on how to build things as it literally has everything that needs to be done there in black and white (and colours! Because sometimes it is nice to add colours to your Excel.).
Best of luck in your building!
John A. Moskal II
I would love to take a look at this. If you wouldn't mind sending to heather.fails@houstonsymphony.org.
Thank you!