Hi,
As we explore and refine the potential architecture approach for the Next Generation product, a key element is extensibility. The current Tessitura software provides a variety of ways for organizations to extend the software today, and we have heard loud and clear that a high degree of customization/extensibility in the future product is a key requirement. One way to help us understand future extensibility needs is to first understand how you customize today. This is a purposefully open-ended question:
Please provide us with examples of customizations or extensions you have made to Tessitura and the business case behind why you made the extension.
We aren’t looking for every customization, but one or two samples that are either most representative or most difficult to accomplish in current Tessitura.
A quartet of examples:
1. We created a custom Box Office Statement in InfoMaker to match specific output field requirements of our promoter. This allows us to settle with the promoter in an efficient and speedy fashion, without us having to run multiple reports and combine them after the fact.
2. We adapted lp_customer_rank to automatically assign a constituency code of ‘Student’ if the constituent has purchased tickets to our Education season and has a customer type of Child. This allows CSRs to quickly identify students when looking up an account, and makes list pulling easier.
3. We created a custom constituent screen using InfoMaker to hold detailed information about our Press contacts. This allows us to have information about all constituents in one place, and ensures we can track specific seating assignments and preferences based on the reviewer.
4. We created a set of pages on our website to record individual member names on a family membership, tied to a custom table and custom membership card output so we can print individual member names on membership cards and link them back to a single membership in Tessitura. This means that multiple members of a household can each have their own personalized membership card while retaining a single membership on the household itself.
Thanks!
Andrew
Normal 0 false false false EN-US X-NONE X-NONE
A trio of examples:
1. Address Standardization
We have a standard format that our primary address should be in (Street spelled out, Boulevard abbreviated, etc.). Of course, our staff always follows these rules to the letter, but when our customers input their addresses on our web site, they don't always follow our rules. To solve this, we have modified lp_customer_rank to call the world famous lf_titlecase to properly standardize our addresses.
2. Acknowledgement Letters
Our business process requires at least one acknowledgement letter for every contribution. In order to enforce this business rule, we are in the process of building a custom report that will be run prior to closing the batch to report on the gifts in the batch and which acknowledgement letter(s) are assigned to each contribution. This way any problems can be resolved before the batch is closed and will hopefully reduce the number of adjustments needed.
3. Purchase Restrictions
We occasionally have ticketed performances that are only open to constituents who are purchasing (or have already purchased) tickets for another performance. We can currently only sell these “add-on” performances in the box office and hope that our ticket sellers correctly enforce the rules. We cannot sell these tickets online. (We typically do not find out about the “add-on” performance until well after the original performance is built and on-sale.)
The common thread to these examples is the need to be able to get control at various points in the flow of the application in order to allow custom business rules to be enforced. There are many different points where hooks could be available, and they should be fairly specific. For the first example, my ideal implementation would have a “local procedure” that would be called just prior to saving an address and would have the ability to either modify the data prior to saving in the database or return an error that would be displayed in either the client or returned to the web API for processing. For the other two examples, the “local procedure” would be called prior to payments being processed to make sure that the contribution/order met our business rules.
Also, it would be advantageous for these “local procedures” to be implemented using tools other than SQL. SQL is the hammer in my tool chest. There are times, however, that I need a little more finesse than a hammer provides. For instance, I would prefer to implement something like lf_titlecase in Perl because Perl is a good tool for pure character string manipulation using regular expressions. For implementing other business rules, other tools might be better (APL anyone?).
-steve carlock
Santa Barbara Center for the Performing Arts/The Granada
Here are a couple more examples from museum-world:
1) Customized web code: We have customized our web code to price our performances differently depending on what combination of performances our patrons select (exp. if they purchase an Omnitheater and Museum Exhibit Admission the price on the Omnitheater performance is different than if they purchase it alone). We have also customized our web code to apply benefits (free and discounted tickets) to our members based on level and size of family.
2) We use a lot of custom functionality (some used by a few other Tessy organizations as well) for our youth and family classes. We have a custom screen that creates accounts for each child on a record which allows us to track their class and camp attendance history on both the parent and child records. We have custom web code in place to restrict the sale of classes to children who are not the correct age for the class. We also have security in place that prevents the accidental sale of memberships and tickets to these 'child' type accounts.
One thing I've been doing lately is leveraging local views and tables into MS Office applicaitons. For instance I have one of my groups full season sales and last seven days sales compiling into two local read-only tables each night, grouped by show and pricetype, and then that local table is ODBC linked into a spreadsheet. Then that spreadsheet can be used as a de facto data source for any other reporting, dynamically refreshed nightly. The last seven days is for trending and projections compared against the whole.
The impetus for this was the realization that everyone was running reports, then dumping them into Excel and manipulating it. So I cut out the middleman.
We also do our own address standardization using SDK called Perfect Address. Pretty cost effective.
I would love to see your attendance tracking - we are getting ready for 160 classes per week for 42 weeks and need to think about attendance tracking per class/student....