[RyanAbbott]

Hi,

I wondered if someone could give me some feedback regarding mail stops. The database I am managing has not be managed for the last two years so there are various different ways of adding a mail stop on the database. I am hoping to gather all of this information and store it in one location so it will be easier to query on the Do not mails etc...

The problem i have is creating the mail stop entries, If i have the standard Do not mail, Do not Phone and Do not Email, What entry do people create if someone only wants to hear from us through email, phone or Mail?

E.G. If someone wants to only receive emails from us, do you suggest I give them the mail stops of Do not mail & Do not phone?

As I say any feedback would be appreciated and if anyone wants to share there mail stop list that would be a great help too.

Many Thanks

Ryan Abbott

[Anne Marie]

Hi Ryan

You may not get many responses today due to the US July 4th holiday.

Anyway, do you use Solicit Codes or Attributes for your "mail stops"? Does your version have "solicit codes"? Perhaps the terminology is different in your version.

Some folks use Solicit Codes for the restrictive negatives: Do Not Mail, Do Not Phone etc.

Some use Attributes for the positives: Wants email, newsletters etc.

We use Solicit Codes for anything to do with sending appeals to a constituent and attributes for other types of mailings - newsletter, freebies etc.

If someone only wants e-mail from you, then I would definitely use Do Not Mail & Do Not Phone. You could also put in a "positive" like Wants E-mail Only. When you are selecting your constituents who only wish to receive e-mail, you can query on that particular solicit code.

Likewise if you specify Spring Mailing only, you can also pull those folks in a Query.

Don't know if I've been helpful or not, but there are several options you can use - attributes or solicit codes. And you can query on either of those.

The short-coming with Solicit Codes is that there is no place for Comments where you could explain why a constituent is coded in that way. It's one of my pet peeves!

Cheers,

[RyanAbbott]

Hi Anne Marie,

Thank you for your reply.

I am thinking of using Solicit codes instead of Attributes.

Basically I just dont want to over complicated things and i'm just trying to find out the best possible way of doing this.

So you suggest to have a positive solicit code i.e. 'Email Only' so when an individual requests to be mailed just by email, I will give that person the solicit codes that equal, 'Do not mail', 'Do not Phone', 'Email only'?

so if I have three positives and three negatives regarding Phone, Mail & Email you reckon it will work and not complicate things?

Thank you for all your help?

Ryan

[Anne Marie]

If you are only going to use Solicit Codes, then I do not think it will be too complicated. Others may suggest you put the positives in Attributes, and only use Solicit Codes to exclude.

But we put exclusions (negatives ie. Do Not) and Inclusions (positives ie only Email, Spring Mailing etc.) in Solicit Codes.

I would think that if you have Do Not Mail, Do Not Phone, Email Only it gives a clear picture of what the constituent's wishes are. If you only have the Do Nots, then how would you know that it is okay to send emails? Unless you have determined that anyone who does not want phone or mail defaults to email.

So, when doing a solicitation by Mail, you can exclude those Do Not Mail. When doing a phone ask, you can exclude those Do Not Phone, and when you send e-mail appeals you can include those who want only email.

This is assuming you will do queries to gather your group.

To me it is not complicated because you have, in one place, the complete picture of the constituent's wishes. I like to have as much info as possible in the record. And just because someone is Do Not Mail, Do Not Phone doesn't mean that they will accept Email.

I am sure others may have different ideas, but they're all off today enjoying their holiday, ha ha.

[dyednwool]

Ryan -

I like to keep the exclusion system as simple as possible but I think how you structure it depends to a great extent on who is running the system. Who is putting the coding onto the records and who is creating the queries?

I've worked in both a highly centralized and highly decentralized RE environments with users who have different system skill levels. In the decentralized situation I found the "dual" system of exclusions & inclusions and having codes in multiple places (solicit codes & attributes) was too confusing for the average RE user and this created problems when structuring mailings - so we had to simplify our system to use only exclusions and we also had to tighten rights for who was putting the coding on the records to ensure it was done properly.

If you use exclusions only, you do run into the issue of having to put a lot of codes on (for example, someone who only wants the Annual Report needs exclusion codes for every other type of mailing).

Also, maintenance can be an issue because if you add a new solicit code exclusion, you may need to add it onto certain records (so taking the above example,if you added a new solicit code of "No Quarterly Regional Newsletter" then you'd need to add this new exclusion on the record of the constituent who only wants the Annual Report).

Also, if you do decide to use solicit codes you can always create a Note type to explain why the codes were added (since you can't add a note or comment directly attached to the solicit code).

So not sure there's any easy one-size-fits-all solution to this one, I would say it depends on your organization and the complexity of your exclusion scenarios?