Do Not Share Request coding

Former Member
Former Member $organization

While we have a practice of not sharing constituent contact lists from our database, there are times when we might want to provide a specific constituent list to a close alliance for our own purposes.  In a recent list share, we extracted all who have no mail and no contact codes in the constituent field of mailing restriction from the list.  Since the three restriction fields (mail, phone and email) only allow one code entry, I am trying to figure out how to ensure that those who both do not want any postal mail from us as well as do not want their contact ever shared to be coded.  

Do any of you track specific requests for Do Not Share Contact Info separately from these three restriction fields? If so, where?  How do you handle restrictions that extend beyond the capacity of the three fields on the general tab of the constituent record?

Thank you. Laura

  • We now have a firm no trade/share policy. However, we also use attributes to track all our mailing purposes, because three options just isn't enough. One of our options for mailings has been "do not trade" - that would be what we would exclude if we were doing a trade in the past. We also marked that attribute on anyone who requested that they be removed from all our mailing lists, just as a courtesy.

    Beth Varro
    Science Museum of Minnesota


    *   *   *   *   *
    How do astronauts get to space? How do they eat, sleep, and do research in a weightless environment? And how do they go to the bathroom? Find out during an unforgettable day of space exploration at the world premiere Space exhibition. It's now open at the Science Museum of Minnesota, along with the brand new Omnitheater film, Journey to Space. Visit www.smm.org/space to plan your visit today!


    From: "Laura Chaney" <bounce-laurachaney2031@tessituranetwork.com>
    To: evarro@smm.org
    Sent: Thursday, July 23, 2015 12:22:15 PM
    Subject: [Tessitura Development Forum] Do Not Share Request coding

    While we have a practice of not sharing constituent contact lists from our database, there are times when we might want to provide a specific constituent list to a close alliance for our own purposes.  In a recent list share, we extracted all who have no mail and no contact codes in the constituent field of mailing restriction from the list.  Since the three restriction fields (mail, phone and email) only allow one code entry, I am trying to figure out how to ensure that those who both do not want any postal mail from us as well as do not want their contact ever shared to be coded.  

    Do any of you track specific requests for Do Not Share Contact Info separately from these three restriction fields? If so, where?  How do you handle restrictions that extend beyond the capacity of the three fields on the general tab of the constituent record?

    Thank you. Laura




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Development Forum. You may reply to this message to post to the Development 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!
  • Former Member
    Former Member $organization

    We also use Attributes.  We have a Privacy Attribute and then multiple criteria in the drop down (i.e. Do Not Contact, Do Not Call, Do not Email, Do not Trade, etc…) We then build various lists and use which ever ones are appropriate as suppression segments in Extractions.

     

    Mark Frey  |  Woodruff Arts Center  |   P: 404.733.4277

     

    From: Tessitura Development Forum [mailto:forums-development@tessituranetwork.com] On Behalf Of Beth Varro
    Sent: Thursday, July 23, 2015 1:48 PM
    To: Mark Frey
    Subject: Re: [Tessitura Development Forum] Do Not Share Request coding

     

    We now have a firm no trade/share policy. However, we also use attributes to track all our mailing purposes, because three options just isn't enough. One of our options for mailings has been "do not trade" - that would be what we would exclude if we were doing a trade in the past. We also marked that attribute on anyone who requested that they be removed from all our mailing lists, just as a courtesy.

     

    Beth Varro

    Science Museum of Minnesota

     

     

    *   *   *   *   *

    How do astronauts get to space? How do they eat, sleep, and do research in a weightless environment? And how do they go to the bathroom? Find out during an unforgettable day of space exploration at the world premiere Space exhibition. It's now open at the Science Museum of Minnesota, along with the brand new Omnitheater film, Journey to Space. Visit www.smm.org/space to plan your visit today!

     


    From: "Laura Chaney" <bounce-laurachaney2031@tessituranetwork.com>
    To: evarro@smm.org
    Sent: Thursday, July 23, 2015 12:22:15 PM
    Subject: [Tessitura Development Forum] Do Not Share Request coding

    While we have a practice of not sharing constituent contact lists from our database, there are times when we might want to provide a specific constituent list to a close alliance for our own purposes.  In a recent list share, we extracted all who have no mail and no contact codes in the constituent field of mailing restriction from the list.  Since the three restriction fields (mail, phone and email) only allow one code entry, I am trying to figure out how to ensure that those who both do not want any postal mail from us as well as do not want their contact ever shared to be coded.  

    Do any of you track specific requests for Do Not Share Contact Info separately from these three restriction fields? If so, where?  How do you handle restrictions that extend beyond the capacity of the three fields on the general tab of the constituent record?

    Thank you. Laura




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Development Forum. You may reply to this message to post to the Development 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!

     




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Development Forum. You may reply to this message to post to the Development 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!

  • Hi, Laura:

     

    We use several settings in TR_MAIL_IND (the system table that sets up the mail restriction drop-down menu):

    ·         No List Trade [Automatically entered by a procedure that runs hourly for patrons with certain constituencies, if they don’t have a more restrictive mail setting already]

    ·         No Mail/Customer Request [Manually entered by someone on our staff based on a patron’s request]

    ·         No Mail/Marketing Limited [Entered online by patron]

    ·         No Mail/Staff Inhouse [Manually entered by someone on our staff based on someone’s being on staff]

    ·         No Valid Address [Automatically entered by a procedure that runs hourly if the primary address has a postal code of 99999 or the Street1 field is set to “No Valid Address”]

     

    I track changing mail settings, when they are not automated, with actions of “Set Phone/Mail Preferences” in a customer service issue of the category Account Issue.

     

    Lucie

    ______________________________
    Lucie Spieler
    IT Development and Training Manager

    Florida Grand Opera