Using solicit codes vs. attributes
Currently, they have a "Mail Restriction" attribute with a drop down list of different restrictions. The proper place for something like this is the solicit code but I am not sure if this is worth changing just because it isn't being used properly. I would appreciate people's opinions on using the mail restriction attribute vs. solicit codes and any positive or negatives you can think of.
Many thanks.
Courtney
Comments
-
I'll be honest. We use a mail attribute to indicate when people should receive a mailing (usually for our newsletter - those folks may not pull as a donor, but someone has indicated that they are important to us and should receive a mailing. Or an event invite).
I suppose it's not much different than using mail codes to exclude (which we do use).
But, I will say, it's near impossible to maintain. Unless you have a plan to go back through and review attributes - they live there in perpetuity.0 -
There really is not a right or wrong in using Attributes vs. Solicit Code, it's a preference. I find that it is easier to use solicit codes for contact exclusion because it is visible on the BIO 1 Tab and easy to use in Query or Mailings. The one negative I see is that you cannot add notes when you use solicit codes but you can with attribute. If I use the solicit code do not mail, there's no way to state why, but if I use an attribute I can add description and comments indicating why we are not allowed to mailed to the constituent
Example Constituent Attribute Contact Exclusion, do not mail, description written request by donor, Comments Donor requested no future mailingsor event invitations etc.. Refer to Impormatic article Using Solicit Codes Effectively in Raiser's Edge (Google article).
Hope this helps.6 -
Thank you everyone. Since solicit code is not being used in our database, I am wondering if I can use this as an inclusion now since the mail restriction attribute seems to be well established. We have a group of people that should be solicited for all events, whether they fall into list parameters or not. This would have to be managed on a yearly basis because they are board, ceo contact list, board member assistants etc. It is a small list but opinions again would be appreciated.0
-
There isn't any right or wrong, but if and when I leave my position I want whoever takes my place to be able to figure out why I did what I did. Taking over someone else's database isn't fun when there are multiple attributes to decifer. Solicit codes I think are easier for someone else to understand.2
-
I have heard before that solicit codes do NOT allow you anywhere to enter a comment vs. attributes that do - so that's one possible differentiation factor choosing one over the other.0
-
Hi Courtney -- Susan here from Blackbaud :-) Good for you for cleaning your new DB up!
There are a lot of good comments here -- it is true that either place will work, and there are some benefits/drawbacks to both.
My preference would be to put mailing information in Solicit Codes. As Dawn said, the Solicit Codes are in a more accessible place on the Bio 1 tab, and if you are using them for exclusions (Do Not Mail, Do Not Solicit), those people can be very easily pulled out of Mailings using the Solicit Code Filter. Also, most organizations I have worked with have a ton of other Attributes, so the Mailing one can tend to get lost in a sea of Attributes.
If you do need to make a comment about a Solicit Code, I usually keep a Note on the Notes tab for "Mailing Preferences" and add any notes associated with the Solicit Codes there. Not perfectly ideal, but it has worked for me.
Whatever you decide, consistency is key!
Good luck :-)
Susan5 -
My general rule of thumb is that if it is about EXCLUDING I use a solicit code and if it is about INCLUDING I use attribute or something else. That works for me.5
-
The issue I've had with using solicit codes and using criteria of 'not one of' in your query is duplication of data/gifts. It will show gifts for each solicit code even if you ask it to not include duplicates.
2 -
I have a solicit code Invite to all Events and I use Attributes to track groups and the events they should be invited to. Using a General Rule template to know who should be invited to a particular event I can code them as soon as they become a member of that group. So even if someone is not affiliated by a group they would get picked up in the mailing because of the solicit code. I can pull my mailing list by the Attribute Description "2015 Holiday" Party AND solicit code "Invite to all Events"
Hope this helps.
Example:
Attribute:
Category: Office List Group
Description: Foundation Board Member
Attribute:
Category: FY2014/2015
Description:2015 Holiday Party0 -
Jane - Just wondering, how do you track people who no longer fall into your grouping. Do you somehow check this and remove their event coding?0
-
Yes, I send a pdf report to the group contact with all current members and ask them to update their groups (change,add,remove). Prior to the beginning of the FY we add the event attributes with the FY upcoming Large events (using global add/constituent attributes from a query by group).
I run Event Attribute mail lists (include the solicit code - Invite to all events) for the team to review before we finalize the mail list to make sure we invite everyone we need to (or omit those we don't want to invite). The general rule has been a great tool for me to maintain the events.
Jane0 -
To be more specific, when someone is no longer a member I change the attribute code to zFormer Foundation Board. I also remove them from any upcoming events they were already coded for. z helps to sort those old members to the bottom of the drop down list in attributes.0
-
Dawn Lowe:
I find that it is easier to use solicit codes for contact exclusion because it is visible on the BIO 1 Tab and easy to use in Query or Mailings. The one negative I see is that you cannot add notes when you use solicit codes but you can with attribute.I'd like to second Dawn's suggestion for using Solicit codes to exclude, rather than include. The biggest reason for this is to simplify mailings. For example, filters in quick letters only have an "Exclude selected" option for Solicit Codes.
On the other hand, Attributes in quick letters allows one to include OR exclude constituents with specific constituent attributes:
Thus, one can create a mailing list, using constituent codes or constituent attributes to select the recipient groups, while using the solicit codes to manage exclusions, all without creating a query.1 -
We use the solicit codes, and enter the reason in the Notes tab. We created a note type called "Solicit Code Explanation". However, in the past it wasn't used consistently (it is now). It's simply of matter of who is doing the data entry and how well the procedures are enforced. It is frustrating to find a solicit code such as "Do Not Contact" or "Do Not Mail" which was probably entered years ago and there is no reason why!Dawn Lowe:
There really is not a right or wrong in using Attributes vs. Solicit Code, it's a preference. I find that it is easier to use solicit codes for contact exclusion because it is visible on the BIO 1 Tab and easy to use in Query or Mailings. The one negative I see is that you cannot add notes when you use solicit codes but you can with attribute. If I use the solicit code do not mail, there's no way to state why, but if I use an attribute I can add description and comments indicating why we are not allowed to mailed to the constituent
Example Constituent Attribute Contact Exclusion, do not mail, description written request by donor, Comments Donor requested no future mailingsor event invitations etc.. Refer to Impormatic article Using Solicit Codes Effectively in Raiser's Edge (Google article).
Hope this helps.0 -
We were hoping to use solicit codes in line with data proetction, does anyone add a action with a code so they have evidence of when permissions are recived or where data has come from?
Am i correct in thisnking people are suggesting using solicit codes for opt out as per data protection (mail)and attributes for opt ins (email)0 -
Mikaela, as far as using Solicit codes for data protection, we do have something similar. Although our organization does not share/sell our donor lists, one of our previous department managers was a big believer in the future of shared data. Because of this, we instituted the Solicit code "No Share" for any donor who prefers not to have their information shared. That way, if another manager comes along who wants to insititute sharing procedures, we already have the privacy system in place.
On the main topic of using Solicit codes for mailings, we recently switched to Solicit codes for all mailing info, inclusions and exclusions. Art has a great point about Solicit codes and Quick letters, but since we don't use Quick letters (most of our mailings are exported and merged out-of-house), we find Solicit codes more useful for reducing Attributes clutter.0 -
I switched from Solicit Codes to Attributes years ago after encountering difficulties with Solicit Codes. We export data and deal with it outside of RE for mailings and such, so RE canned process restrictions don't matter.
We have 3 Mailing Attributes, for 3 different categories of mail. The Description dropdown includes Mail All, Employee (i.e. inter-office and save the postage!), Electronic Only, Print Only, Remove per Constituent, Do Not Mail per Org (i.e. someone on our staff says to take someone off the list), and Special Instructions (i.e. solicit once a year in the spring, or don't solicit until May 2017, etc.). Every time an Attribute is added or changed, the Date is updated and the Comment includes additional information or a "see ConstNote" with additional information (such as a copy-and-paste of an email thread) about the Attribute.
The Attributes are mBR (the umbrella name for our big in-kind gift drives), mNL (donor newsletter), and mIS (invitations & solicitations...or "other mail"). The "m" prefix puts them together on the Attributes Tab. Many of our reply vehicles include an opt-out section, with 2-3 of these options (i.e. "check here to be removed from our newsletter mailing list").
If you put Include in one place and Exclude on another, be sure to document which one takes priority if a record ends up with both. Actually, document the heck out of whatever system you set up! As Karen mentioned, when you leave the org (for whatever reason...win the lottery and no longer need to work
), you want your successor to be able to easily understand how and why things are set up. 1 -
For the most part, our solicit codes are used for exlusions. We have created a note type for solicit codes. This way we can document who added the code and why. If the constituent sent us an email to opt out of something, we copy the email into the note. If we recieve a letter, we can scan it in to our paperless system and reference it in the note.
If we decide to add solicit codes such as No Contact, it has been helpful to know who requested it and why. If the constituent requested it, it is no problem to remove the solicit code if they contact us again to opt back in. However, if the solicit code was added by a staff member, we can read the note and determine if the code should be kept on.1 -
Michelle - do you have this note as a required field when people add a solicit code (if thats even possiable) otherwise how do tyou ensure this happens?
Thanks0 -
No, it's not required. Only a handful of people are able to put solicit codes on anyway. We have found that most poeple do not want to have learn how to enter data into Raiser's Edge, so it is easier for them just send us the request.
Not all of our solicit codes require notes. We also have solicit codes so that we can exclude records if they have an affiliation to an area of the college that we should not solicit. For instance, we have the Dance Center that does their own fundraising and events. We process the gifts, so the records are in our database. If the only affiliation they have is to the Dance Center, we certainly do not want to solicit them from this office. The only time we enter a note for the Center attributes is if we get a request from someone there that they are working with an individual personally but there is no known affinity yet.
There are also attributes specific to the Centers and other non-academic units for their use, but we found that it was to hard to exclude the ones who only had affinity to a particular center from the ones who are active all around the college.0 -
For data pulling sake its much easier to be able to pull by solicit codes than by attributes. I will say that both have the problem of not having "To" colums to notify that at a time someone requested a solicit code but changed their minds.0
-
I disagree on what is easier. I think that attributes are easier as do not even need to have an "exclude" query - in Mail (from which we "should" be doing most of our mailings) you use the attribute tab to exclude any/all attribute(s).2
-
Jane Kenny:
The issue I've had with using solicit codes and using criteria of 'not one of' in your query is duplication of data/gifts. It will show gifts for each solicit code even if you ask it to not include duplicates.
Not one of does not work like you think it will. You are best served merging queries and SUBtracting out the Solicit Codes that you do not want included.
In regards to dupes in your query list. That is always going to happen. Query is a grouping tool not a reporting tool. You need to pull your query through Export or a canned report to filter out dupes. :-)
2 -
Courtney Klein:
Thank you everyone. Since solicit code is not being used in our database, I am wondering if I can use this as an inclusion now since the mail restriction attribute seems to be well established. We have a group of people that should be solicited for all events, whether they fall into list parameters or not. This would have to be managed on a yearly basis because they are board, ceo contact list, board member assistants etc. It is a small list but opinions again would be appreciated.Definitely headed in a good direction. We also have fine-tuned our Solicit Codes to include more detail. For instance, we have a "Do not mail - Partner record" when we must have two records for a married couple, "Solicit only through business" for major foundation contacts who should also receive invitations at home but not solicitations. Be careful you do not create so many that it is easy to forget to include/exclude when building a mailing list etc.
0 -
Our organisation has always used Solicit codes to exclude from mailings. However, with the potential change in fundraising regulations we are looking into moving over to Attributes. We are running our data through MPS and DPS to flag individuals who no longer wish to be contacted, but we need to record a date that this was flagged, hence why we are looking at Attributes.
In addtion to this, we may need to start recording when an individual is opting in or out of receiving specific mailings, and again a date and comment will need to be added. But the down side of using attributes is that there is no 'To' date that can be used if an individual decides to change their mailing preference.
We feel that a separate module needs to be developed to record mailing preferences, and to keep all historical preferences logged going forward.0 -
Nicola Rendell:
Our organisation has always used Solicit codes to exclude from mailings. However, with the potential change in fundraising regulations we are looking into moving over to Attributes. We are running our data through MPS and DPS to flag individuals who no longer wish to be contacted, but we need to record a date that this was flagged, hence why we are looking at Attributes.
In addtion to this, we may need to start recording when an individual is opting in or out of receiving specific mailings, and again a date and comment will need to be added. But the down side of using attributes is that there is no 'To' date that can be used if an individual decides to change their mailing preference.
We feel that a separate module needs to be developed to record mailing preferences, and to keep all historical preferences logged going forward.Nicola, you should add this to the RE:7 Idea Bank, and then post a link back here. Additionally, this could be helpful for those using Online Express (OLX) if we ever get the ability to allow constituents to deteremine what kind of emails they want to receive from us.
1 -
Jen Claudy:
Nicola Rendell:
Our organisation has always used Solicit codes to exclude from mailings. However, with the potential change in fundraising regulations we are looking into moving over to Attributes. We are running our data through MPS and DPS to flag individuals who no longer wish to be contacted, but we need to record a date that this was flagged, hence why we are looking at Attributes.
In addtion to this, we may need to start recording when an individual is opting in or out of receiving specific mailings, and again a date and comment will need to be added. But the down side of using attributes is that there is no 'To' date that can be used if an individual decides to change their mailing preference.
We feel that a separate module needs to be developed to record mailing preferences, and to keep all historical preferences logged going forward.Nicola, you should add this to the RE:7 Idea Bank, and then post a link back here. Additionally, this could be helpful for those using Online Express (OLX) if we ever get the ability to allow constituents to deteremine what kind of emails they want to receive from us.I was just thinking that! I cant find any existing ideas on this - has anyone else created one?
1 -
Courtney Klein:
Hi everyone. So I've been hired as the database manager. One of my tasks has been to clean up the database, implement policies and procedures that are better suited for the department.
Currently, they have a "Mail Restriction" attribute with a drop down list of different restrictions. The proper place for something like this is the solicit code but I am not sure if this is worth changing just because it isn't being used properly. I would appreciate people's opinions on using the mail restriction attribute vs. solicit codes and any positive or negatives you can think of.
Many thanks.
CourtneyLast week I saw a preview for upcoming features for NXT and this will be included soon in both NXT "standard" RE (driven by new regulations in the UK).
0 -
Courtney Klein:
Hi everyone. So I've been hired as the database manager. One of my tasks has been to clean up the database, implement policies and procedures that are better suited for the department.
Currently, they have a "Mail Restriction" attribute with a drop down list of different restrictions. The proper place for something like this is the solicit code but I am not sure if this is worth changing just because it isn't being used properly. I would appreciate people's opinions on using the mail restriction attribute vs. solicit codes and any positive or negatives you can think of.
Many thanks.
CourtneyHi Courtney,
We actually use both. Before we had the solict code table we used attributes so we've continued the process. In our database Attributes are both positive and negative statements, but the Solict code is restricted to a negative statement e.g. No mail, unsubscribed to eblasts etc. I like the solicit code table because it is right on the Bio 1 tab and staff don't need to hunt for this type of information.
0 -
I prefer attributes as you can filter them out via mail and not have to worry about excluding them via query AND you can add a note/comment and date.1
Categories
- All Categories
- Shannon parent
- shannon 2
- shannon 1
- 21 Advocacy DC Users Group
- 14 BBCRM PAG Discussions
- 89 High Education Program Advisory Group (HE PAG)
- 28 Luminate CRM DC Users Group
- 8 DC Luminate CRM Users Group
- Luminate PAG
- 5.9K Blackbaud Altru®
- 58 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 409 bbcon®
- 2.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- donorCentrics®
- 1.1K Blackbaud eTapestry®
- 2.8K Blackbaud Financial Edge NXT®
- 1.1K Blackbaud Grantmaking™
- 527 Education Management Solutions for Higher Education
- 1 JustGiving® from Blackbaud®
- 4.6K Education Management Solutions for K-12 Schools
- Blackbaud Luminate Online & Blackbaud TeamRaiser
- 16.4K Blackbaud Raiser's Edge NXT®
- 4.1K SKY Developer
- 547 ResearchPoint™
- 151 Blackbaud Tuition Management™
- 1 YourCause® from Blackbaud®
- 61 everydayhero
- 3 Campaign Ideas
- 58 General Discussion
- 115 Blackbaud ID
- 87 K-12 Blackbaud ID
- 6 Admin Console
- 949 Organizational Best Practices
- 353 The Tap (Just for Fun)
- 235 Blackbaud Community Feedback Forum
- 55 Admissions Event Management EAP
- 18 MobilePay Terminal + BBID Canada EAP
- 36 EAP for New Email Campaigns Experience in Blackbaud Luminate Online®
- 109 EAP for 360 Student Profile in Blackbaud Student Information System
- 41 EAP for Assessment Builder in Blackbaud Learning Management System™
- 9 Technical Preview for SKY API for Blackbaud CRM™ and Blackbaud Altru®
- 55 Community Advisory Group
- 46 Blackbaud Community Ideas
- 26 Blackbaud Community Challenges
- 7 Security Testing Forum
- 1.1K ARCHIVED FORUMS | Inactive and/or Completed EAPs
- 3 Blackbaud Staff Discussions
- 7.7K ARCHIVED FORUM CATEGORY [ID 304]
- 1 Blackbaud Partners Discussions
- 1 Blackbaud Giving Search™
- 35 EAP Student Assignment Details and Assignment Center
- 39 EAP Core - Roles and Tasks
- 59 Blackbaud Community All-Stars Discussions
- 20 Blackbaud Raiser's Edge NXT® Online Giving EAP
- Diocesan Blackbaud Raiser’s Edge NXT® User’s Group
- 2 Blackbaud Consultant’s Community
- 43 End of Term Grade Entry EAP
- 92 EAP for Query in Blackbaud Raiser's Edge NXT®
- 38 Standard Reports for Blackbaud Raiser's Edge NXT® EAP
- 12 Payments Assistant for Blackbaud Financial Edge NXT® EAP
- 6 Ask an All Star (Austen Brown)
- 8 Ask an All-Star Alex Wong (Blackbaud Raiser's Edge NXT®)
- 1 Ask an All-Star Alex Wong (Blackbaud Financial Edge NXT®)
- 6 Ask an All-Star (Christine Robertson)
- 21 Ask an Expert (Anthony Gallo)
- Blackbaud Francophone Group
- 22 Ask an Expert (David Springer)
- 4 Raiser's Edge NXT PowerUp Challenge #1 (Query)
- 6 Ask an All-Star Sunshine Reinken Watson and Carlene Johnson
- 4 Raiser's Edge NXT PowerUp Challenge: Events
- 14 Ask an All-Star (Elizabeth Johnson)
- 7 Ask an Expert (Stephen Churchill)
- 2025 ARCHIVED FORUM POSTS
- 322 ARCHIVED | Financial Edge® Tips and Tricks
- 164 ARCHIVED | Raiser's Edge® Blog
- 300 ARCHIVED | Raiser's Edge® Blog
- 441 ARCHIVED | Blackbaud Altru® Tips and Tricks
- 66 ARCHIVED | Blackbaud NetCommunity™ Blog
- 211 ARCHIVED | Blackbaud Target Analytics® Tips and Tricks
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- Luminate CRM DC Users Group
- 225 ARCHIVED | Blackbaud eTapestry® Tips and Tricks
- 1 Blackbaud eTapestry® Know How Blog
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)
- 1 Blackbaud K-12 Education Solutions™ Blog
- 280 ARCHIVED | Mixed Community Announcements
- 3 ARCHIVED | Blackbaud Corporations™ & Blackbaud Foundations™ Hosting Status
- 1 npEngage
- 24 ARCHIVED | K-12 Announcements
- 15 ARCHIVED | FIMS Host*Net Hosting Status
- 23 ARCHIVED | Blackbaud Outcomes & Online Applications (IGAM) Hosting Status
- 22 ARCHIVED | Blackbaud DonorCentral Hosting Status
- 14 ARCHIVED | Blackbaud Grantmaking™ UK Hosting Status
- 117 ARCHIVED | Blackbaud CRM™ and Blackbaud Internet Solutions™ Announcements
- 50 Blackbaud NetCommunity™ Blog
- 169 ARCHIVED | Blackbaud Grantmaking™ Tips and Tricks
- Advocacy DC Users Group
- 718 Community News
- Blackbaud Altru® Hosting Status
- 104 ARCHIVED | Member Spotlight
- 145 ARCHIVED | Hosting Blog
- 149 JustGiving® from Blackbaud® Blog
- 97 ARCHIVED | bbcon® Blogs
- 19 ARCHIVED | Blackbaud Luminate CRM™ Announcements
- 161 Luminate Advocacy News
- 187 Organizational Best Practices Blog
- 67 everydayhero Blog
- 52 Blackbaud SKY® Reporting Announcements
- 17 ARCHIVED | Blackbaud SKY® Reporting for K-12 Announcements
- 3 Luminate Online Product Advisory Group (LO PAG)
- 81 ARCHIVED | JustGiving® from Blackbaud® Tips and Tricks
- 1 ARCHIVED | K-12 Conference Blog
- Blackbaud Church Management™ Announcements
- ARCHIVED | Blackbaud Award Management™ and Blackbaud Stewardship Management™ Announcements
- 1 Blackbaud Peer-to-Peer Fundraising™, Powered by JustGiving® Blogs
- 39 Tips, Tricks, and Timesavers!
- 56 Blackbaud Church Management™ Resources
- 154 Blackbaud Church Management™ Announcements
- 1 ARCHIVED | Blackbaud Church Management™ Tips and Tricks
- 11 ARCHIVED | Blackbaud Higher Education Solutions™ Announcements
- 7 ARCHIVED | Blackbaud Guided Fundraising™ Blog
- 2 Blackbaud Fundraiser Performance Management™ Blog
- 9 Foundations Events and Content
- 14 ARCHIVED | Blog Posts
- 2 ARCHIVED | Blackbaud FIMS™ Announcement and Tips
- 59 Blackbaud Partner Announcements
- 10 ARCHIVED | Blackbaud Impact Edge™ EAP Blogs
- 1 Community Help Blogs
- Diocesan Blackbaud Raiser’s Edge NXT® Users' Group
- Blackbaud Consultant’s Community
- Blackbaud Francophone Group
- 1 BLOG ARCHIVE CATEGORY
- Blackbaud Community™ Discussions
- 8.3K Blackbaud Luminate Online® & Blackbaud TeamRaiser® Discussions
- 5.7K Jobs Board