• Replies 24 replies
  • Subscribers 364 subscribers
  • Views 239 views
  • Users 0 members are here
Related

How do you Extend Tessitura today?

Andrew Recinos
$organization

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

Parents
  • $organization
    Andrew,

    Here is a quintet of real life examples:

    1. We created a custom representation of Fundraising data that we call Projections. This is still under development but in general it treats Contributions and Solicitations as if they were the same kind of thing. The data in T_Contributions represents realized contribution and Solicitations are un-realized Contributions that we hope to get. This was done to match a long time methodology established by Sr. Management prior to the implementation of Tessitura. This allows us to manage the conversion of solicitations into contributions. This representation of the data also handles indirect contributions that are credited to donors not just the contributions that are given on a particular account. There is no place in Tessitura to get this holistic view of a given constituents current donations and a sense of our fundraisings staff expectations for near term donations in the time frame tomorrow to 18 months from now. We are also working on a similar set of data for finance that represents Contribution Transactions and Payment schedules as if they are the same time. Realized Contribution Monies and Expected Contribution Monies on a constituent by constituent bases. This will be displayed as a SSRS report. These data views are already being used in a large number of spreadsheets around the organization using data queries in MS Excel.

    2. We created a series of views and stored procedures to remove duplicate addresses from the system, export, and then re-import NCOA change of address data. This was created because the USPS mandated this data review and there was no standard process provided by the Tessitura Network to take these steps. We are looking at the standard method provided by the Tessitura Network but have not implemented at this time.

    3. We created a custom constituent screen using InfoMaker to hold detailed about changes in Fundraising Campaign goals over time. This was put in the constituent custom screen because (at the time created) there was no other place in Tessitura to put this information. This screen manipulates the data stored in T_Campaign.goal_amt and really has nothing to do with individual constituents. This custom screen allows us to maintain a history of the ebb and flow of fundraising goals over the year.

    4. We created a custom subscription history screen that allows us to show subscriptions despite the fact that the tickets are actual sold as single tickets (with a special group of price types) in Tessitura. Subscriptions are sold in this way because at the time of implementation the Subscription model in Tessitura could not handle the types of subscriptions we were accustomed to selling. The web site has also been developed with this method of Subscriptions in mind. Numerous reports have also been developed to support this type of subscriptions. One of the reasons we have not moved to T-Stats is that the data model that comes with T-Stats does not know how to handle subscriptions sold in this way.

    5 We have created a custom web page used to monitor the status of our web site and Tessitura infrastructure. This way page is monitored by our Alerting System so we know when there are technical problems with our Tessitura System.

    Here at BAM there are hundreds of other customizations we have made to the system.

    --Tom
Reply
  • $organization
    Andrew,

    Here is a quintet of real life examples:

    1. We created a custom representation of Fundraising data that we call Projections. This is still under development but in general it treats Contributions and Solicitations as if they were the same kind of thing. The data in T_Contributions represents realized contribution and Solicitations are un-realized Contributions that we hope to get. This was done to match a long time methodology established by Sr. Management prior to the implementation of Tessitura. This allows us to manage the conversion of solicitations into contributions. This representation of the data also handles indirect contributions that are credited to donors not just the contributions that are given on a particular account. There is no place in Tessitura to get this holistic view of a given constituents current donations and a sense of our fundraisings staff expectations for near term donations in the time frame tomorrow to 18 months from now. We are also working on a similar set of data for finance that represents Contribution Transactions and Payment schedules as if they are the same time. Realized Contribution Monies and Expected Contribution Monies on a constituent by constituent bases. This will be displayed as a SSRS report. These data views are already being used in a large number of spreadsheets around the organization using data queries in MS Excel.

    2. We created a series of views and stored procedures to remove duplicate addresses from the system, export, and then re-import NCOA change of address data. This was created because the USPS mandated this data review and there was no standard process provided by the Tessitura Network to take these steps. We are looking at the standard method provided by the Tessitura Network but have not implemented at this time.

    3. We created a custom constituent screen using InfoMaker to hold detailed about changes in Fundraising Campaign goals over time. This was put in the constituent custom screen because (at the time created) there was no other place in Tessitura to put this information. This screen manipulates the data stored in T_Campaign.goal_amt and really has nothing to do with individual constituents. This custom screen allows us to maintain a history of the ebb and flow of fundraising goals over the year.

    4. We created a custom subscription history screen that allows us to show subscriptions despite the fact that the tickets are actual sold as single tickets (with a special group of price types) in Tessitura. Subscriptions are sold in this way because at the time of implementation the Subscription model in Tessitura could not handle the types of subscriptions we were accustomed to selling. The web site has also been developed with this method of Subscriptions in mind. Numerous reports have also been developed to support this type of subscriptions. One of the reasons we have not moved to T-Stats is that the data model that comes with T-Stats does not know how to handle subscriptions sold in this way.

    5 We have created a custom web page used to monitor the status of our web site and Tessitura infrastructure. This way page is monitored by our Alerting System so we know when there are technical problems with our Tessitura System.

    Here at BAM there are hundreds of other customizations we have made to the system.

    --Tom
Children
No Data