• Replies 3 replies
  • Subscribers 338 subscribers
  • Views 83 views
  • Users 0 members are here
Related

When to use Interests vs Constituency codes?

Nick Reilingh
$organization

Hey all,

So far, we've been pretty strict with the way we've designed our constituency codes and interests. Our interests are basically only genres, and all relate to TKWs applied to programming. Our constituency codes are basically a limited set of "evergreen" classes of relationship with our institution, and I think it makes sense to be on the conservative side when it comes to adding new codes.

We have a business need for managing "lists" of constituents, in that membership in the list needs to be editable, a start and end date is not required (this is too granular for constituency codes anyway), and pulling a customer's membership for all classes of "list" should be easy to add to custom reports and output sets. Just creating a simple static list is not an acceptable solution since static lists cannot be edited by users who did not create them, and this would not be editable from the constituent record.

Something I've done in the past when doing large constituent imports has been to create an attribute with multiple dropdown values, and assign a value (referencing the dataset) upon import. This seems to work out okay for one-off imports since the user doesn't do any assigning (and I can even make the attribute non-editable), but I don't think it's the right choice for this situation.

So what I'm considering is creating a set of TKWs for constituents only, in a distinct TKW_CATEGORY that I can use to base my output set elements on. Does my thinking sound correct on this? Just want to make sure I'm not overlooking anything.

  • $organization

    Nick,

    I don't know how helpful I might end up being, but I can say that in our situation we're using Constituency and Interests in about the same manner that you are.

    Constituency is where we do most of our custom additions, and we use Lists and Import to Lists to add and remove Constituency data from our patrons as needed. We have Constituency values for all of our major membership groups, our Board Directors, and we even tie Constituency into giving amounts to our Annual Fund to track their level of giving for benefit purposes.

    Interests we don't use very much, primarily because--and this will sound crazy--we don't use Tess for Ticketing because the performing arts center that presents us uses Tickets.com and so we have to import ticket data post-performance to have in Tessitura (and our first import likely won't happen until after we're done with The Nutcracker this month. We have been Ticketing via TNEW for our Center for Dance Education classes though, so that combined with ticket data import will have us using Interests more in the future just to assist our Ticketing/Marketing department with customer history for performance types.

    Thank you,

    Brian

  • $organization

    Nick

    I have tended to use interests for allowing customers to add themselves to (or off) mailing lists, so your solution sounds fine.

    Only thing is you may want to add a weight to the interestwhen added to a constituent record (poss background sp) as that way you can see when people have unticked it as otherwise the DB just deletes the record - just helps with queries and gives you a way of seeing the deletions as well as the adds.

    Mark

  • $organization

    We’ve been using mail purpose. Our web implementation displays them as check boxes that patrons can manipulate when they are logged in. One of the options is “No e-mail to this address.”

     

    People who check that get the e-marketing box unchecked for that eaddress. (I have a report that looks daily for that as well as other e-mail issues and calls to my attention any e-mails where someone has inadvertently selected positive e-mail lists (News, Special Offers, and the like) as well as the No Mail box, which, if they were entered at the same time, I uncheck. This happens, during busy periods, perhaps a couple of times a week.

     

    Lucie

     

     

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mark Ridley
    Sent: Monday, December 12, 2016 4:39 AM
    To: Lucie Spieler <lspieler@fgo.org>
    Subject: Re: [Tessitura Technical Forum] When to use Interests vs Constituency codes?

     

    Nick

    I have tended to use interests for allowing customers to add themselves to (or off) mailing lists, so your solution sounds fine.

    Only thing is you may want to add a weight to the interestwhen added to a constituent record (poss background sp) as that way you can see when people have unticked it as otherwise the DB just deletes the record - just helps with queries and gives you a way of seeing the deletions as well as the adds.

    Mark

    From: Nick Reilingh <bounce-nicholasreilingh4883@tessituranetwork.com>
    Sent: 12/10/2016 2:50:28 PM

    Hey all,

    So far, we've been pretty strict with the way we've designed our constituency codes and interests. Our interests are basically only genres, and all relate to TKWs applied to programming. Our constituency codes are basically a limited set of "evergreen" classes of relationship with our institution, and I think it makes sense to be on the conservative side when it comes to adding new codes.

    We have a business need for managing "lists" of constituents, in that membership in the list needs to be editable, a start and end date is not required (this is too granular for constituency codes anyway), and pulling a customer's membership for all classes of "list" should be easy to add to custom reports and output sets. Just creating a simple static list is not an acceptable solution since static lists cannot be edited by users who did not create them, and this would not be editable from the constituent record.

    Something I've done in the past when doing large constituent imports has been to create an attribute with multiple dropdown values, and assign a value (referencing the dataset) upon import. This seems to work out okay for one-off imports since the user doesn't do any assigning (and I can even make the attribute non-editable), but I don't think it's the right choice for this situation.

    So what I'm considering is creating a set of TKWs for constituents only, in a distinct TKW_CATEGORY that I can use to base my output set elements on. Does my thinking sound correct on this? Just want to make sure I'm not overlooking anything.




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!