[Melody Penner]

We are receiving an increasing number of requests for Email only contact as well as specific requests for mailings like faculty newsletters or our quarterly alumni journal to be sent to our constituents via email in pdf format.

My question is do you have any suggestions for how we handle flagging this on a constituent record?

The plan we have in place (that I have not rolled out yet) is to use the following solicit codes:
Email Only
Email - Specific Mailing 1
Email - Specific Mailing 2 etc... (Where specific mailing = the publicaction ie faculty newsletter, alumni journal etc)

This would be similar to our current solicit code structure where we have some positive and some negative solicit codes (ie No alumni jounal, add to alumni journal).

I am concerned that this will continue to grow significantly as more and more of our alumni become more and more environmentally conscious as well as technically inclined.

What are your thoughts on this.

thanks, look forward to your input.

Melody

[Peter Gulka]

Solicit codes are best if left in one direction - exclusionary only. this
meaning "Don't send me X". If you star mixing in inclusionary things like
"Email only" it gets messy.

I'd suggest an attribute of "Mail preference" or something like taht to hold
"Email only" or "Snail mail only"

[Melody Penner]

So Peter, what you suggest is moving all our positive solicit codes to an attribute instead like "Mail preferences"? And using only exclusions in our solicit codes like "No Alumni jounall" ?
I like that!

I will look over what we have and consider the implications of what you suggest and see if it will work with what we already have.

I'll let you know.
thanks again.
Melody

[Peter Gulka]

Something like that yeah. For exisitng codes that can be a big project. This
new job at St Paul's High School ahs landed me in exactly that boat. Solicit
codes have been used inconsistently and contaminated. As a result people
have "No Solicitation", "No Email Solicitation", and "Email only" on the
same record.

Solicit codes restrict what gets sent to them, and the attribute would be
more for describing a preferred communcation method.

[Melissa Siobhan]

I have completely switched to using attributes for both. I use one called Approach Restriction and one called Special Mailing Codes. Solicit codes are not available in mail for filtering so you are limited to using a negative criteria in a query to get them excluded - I do not trust that.

Attributes can be excluded right from the attribute tab in Mail. I have saved mail runs that I keep for Annual Report, Newsletters, Direct Mail, Event Invitations which automatically exclude the right people for those mailings.

I use special mailing inclusions in my query to add them to the mail run. However, if they also have an approach restriction they can get pulled back out again in Mail - it is important to keep this information clean and I find having them both in attributes helps you catch those conflicting codes.

[Jo Ward]

[quote=Melissa Siobhan;18996]I have completely switched to using attributes for both. I use one called Approach Restriction and one called Special Mailing Codes. Solicit codes are not available in mail for filtering so you are limited to using a negative criteria in a query to get them excluded - I do not trust that.

Melissa,
I'm on 7.83 and you can filter by solicit codes in this version. I'm not sure when it first was added, but look for it on the Filters tab.

I tend to follow Peter's approach and use solicit codes that exclude. I also use mailing type attributes and some of them are includes, but some also exclude. I tend to use the includes for members of certain committees or mailing groups, where all constituents who are to get a certain mailing have been given a particular attribute.

Jo

[Melissa Siobhan]

Thanks for eltting me know. I am going to continue to use attributes because I can add dates and notes. I like knowing when and why an approach restriction was added.

[Melody Penner]

Hmmm, I have more thinking to do to before I decide on what to roll out.
We have solicit codes (suggestion of placing these in solicit codes came from the consultant when we converted) like canvass phone only - no mail OR canvass mail only - no phone that are specific to our annual giving program and I have solicit as single, solicit as couple that also belong to our annual giving program and are used in the complicated segmentation process that we use...so If I move them, the process will need to be changed to look for them in a differrent place. I am going to have to figure out where to put these IF I move them.

I see how I can move the existing "add to" solicit codes to an attribute because they are for specific mailings and would work well with Melissa's attribute something like "Special Mailing Codes". We would include these individuals with each specific mailing.

I am still a little stuck on how to include the "email only" along with the "specific email onlys". If I use an attribute for "Preferred communication method" . I guess that for every list we are extracting the attibute with the value of email only as well as the value for the specific email only will need to be considered.......

I am off to try this in our test database and see how it comes out. I am very visual and need see it. I will let you know how it all turns out

Thank you all so very much for your input. I appreciate your knowledge and experience.

Melody

[Anne Marie]

Quote:

Originally Posted by Melissa Siobhan

Thanks for eltting me know. I am going to continue to use attributes because I can add dates and notes. I like knowing when and why an approach restriction was added.

I have an idea Or at least I did 307 days ago!!


If you think like Melissa & I do - i.e. that Solicit codes should have a space for comments and dates, please vote for my terribly old Idea from last year.

You have to go to approx. page 19 of the Ideas section.

Hopefully this Idea might make it to conference this year - that is if the 35 old votes still count.

Peter, do old Ideas and votes count towards this year's tally for topics?

We used to use attributes for mailing codes back in the day, but then when Solicit Codes became available (yes, I know it was some time ago), BB strongly encouraged us to convert all our mailing attributes to solicit codes.

Hmmfph - of course no way to add comments and dates - a big hole if you ask me.

Thanks,

[Peter Gulka]

All ideas are valid as long as they flaot to the top for vote count and have
not already been implemented in a patch.

[Jo Ward]

Quote:

Originally Posted by Melissa Siobhan

Thanks for eltting me know. I am going to continue to use attributes because I can add dates and notes. I like knowing when and why an approach restriction was added.

I agree about tthe attributes being more valuable because of the date information. My solicit ocdes tend tto be more of the nature of "do not call - mail only" or "do not mail - requested removal". I like having those appear on the Bio1 screen, so people know this information without having to go to attributes.

[Faith D]

We follow a system similar to Jo and Peter - solicit codes are used for exclusions as it helps other staff to be able to see them on the Bio 1 tab.

We recently reviewed all of organization contacts and coded their mailing address (on the "More" tab) for mailing types: newsletter, reports, acknowledgements or event invitations. If we find that we need this level of detail for individuals, we'll expand the system. Mostly we were having trouble identifying which organizational contacts needed to receive which type of mail from us.

You could do a combination of things: a solicit code structure with "no contact" for those who do not want to hear from the organization in any way, "no mail" for those who want to physical mail, and an attribute for mailing preferences "email only" - or some other combination along those lines. Then you'd get the benefit of seeing something about their mailing preferences on the Bio 1 tab and you could also pull reliable lists using the mailing preferences attribute.

[ida]

Hi

We use Attributes and have:
1. Communication Restricted to - as in 'only send me...'
2. Communication Inclusion - as in 'make sure I get...'
3. Communication Exclusion - as in 'make sure I don't get...'
4. Overall Exclusion

For 1, 2 and 3 we have the same table, which includes specific regular mailings, such as our newsletter and seasonal appeals. We rely on the data entry staff to not record conflicting information and to enter dates as much as possible.

For 4, we have the 'No Mailings' type and we do not include Email as this is on Bio1 - Requested no email tick box - therefore we don't duplicate.

Hope that helps..
Ida