Hello Blog Reader!
Well, the holiday season is upon us, and first and foremost let me offer peace, love and best wishes to you and yours! Stay safe and have fun!
Let’s talk about training and instructional sessions. Have you ever sat in on a training session and then left the room saying to yourself, “Well, there’s 2 hours of my life I’ll never get back….What a waste of time!” Yes, we all have.
What makes for an interesting, informative and comprehensive training session? Here at RESolutionsTECH, we do a lot of training, both in-person, and on-line and our goal is always straightforward and simple: to provide customized, specific training sessions tailored to meet the needs of the individual client.
Unlike some Raiser’s Edge training offered by other organizations where the information presented is very general and generic sample data is utilized, here at RESolutionsTECH we use examples from the client’s actual live database, thus providing relevant and real time examples in the sessions.
Here are my top ten suggestions for a successful training experience for you and your staff:
1) Use data examples that the participants recognize and are relevant and meaningful to them.
To this end, whenever feasible, we remotely connect directly to the client’s Raiser’s Edge and present from there, thus showing them their actual data and the information in their specific drop down menus.
2) Encourage conversation, questions and feedback.
By working with just one specific client at a time, we are able to customize each training session to ensure the client’s specific priorities are being met. We also send out a survey before the training to gauge their needs and a second, follow-up survey once the training is completed to ensure the information presented was meaningful and relevant.
3) Ensure the participants can see how the information presented will make the tasks that they need to perform on a daily basis easier and more efficient.
The goal of the training is always to give the participants a deeper appreciation for the capabilities of Raiser’s Edge and to ease their apprehensions regarding the complexity of the database.
4) Divide diverse topics into separate sessions.
Whether the desire is to learn about Mailings, Queries, Security, Record management, or any of the optional Raiser’s Edge modules, we create individualized sessions that focus on the clients’ needs.
5) Keep the sessions manageable and not too lengthy.
Generally, the sessions we offer run no longer than 90 minutes, so the information is parsed in such a way that people have plenty of opportunity for discussions and questions without feeling overwhelmed with too much information.
6) Offer follow-up sessions and encourage open communication to counter any difficulties the client may face moving forward.
Here at RESolutionsTECH we are always accessible and available to directly answer one-on-one questions or concerns your staff may have following the training sessions.
7) Appreciate that different people have different learning needs and not everyone is a computer wizard.
Never assume the participants have an in-depth working knowledge of Windows or related software, such as Excel. Keep the training sessions simple and easy to follow and offer real-world examples whenever possible.
8) Know the participants’ role in their organization.
In this way, the sessions are prioritized and the participants are gaining access to information that is specifically relevant to their daily work needs.
9) Keep the sessions light and stress-free.
People can sometimes be a little nervous if they’re being asked to openly participate in the session and are sometimes afraid to admit what they don’t know. By encouraging active questions and asking for specific examples of where they’ve run into trouble or confusion, the participants feel more comfortable engaging with the presenter and the session will be more interactive.
10) Have fun!
Enthusiasm is contagious!
Thanks for reading my latest blog and have a great holiday season!
Tuesday, December 22, 2009
Thursday, October 15, 2009
Solicit Codes
Hello Blog Reader!
Welcome to October! Kids back to school and settled into their daily routines, Canadian Thanksgiving behind us, but when’s the next long weekend??
For those of our clients that live in more temperate zones than us -- Philadelphia, New Jersey, and our newest client in California – YES! California! – trust me when I say these dank, cold, wet October days in Canada are enough to make one yearn for warmer climes! The mornings are dark and cold, and May seems a long time away!
Its also the time of year when germs seem to be at their most virulent, and my daughter and I are taking turns sneezing on each other….
And it’s a busy time of year for all….we’ve got Halloween just around the corner, and then end of the year celebrations rushing towards at supersonic speed….But for now, let’s take a bit of a break, breathe a deep sigh, grab a coffee and spend the next 10 or 15 minutes discussing the most appropriate use of Solicit Codes in Raiser’s Edge.
Solicit Codes are populated on the BIO1 Tab of the Constituent record and are essential in maintaining a healthy relationship with all of your Constituents, most notably your key donors. Solicit Codes are used to identify and track rules of contact that exist between that specific Constituent and your organization. For example, if a Constituent has indicated to you that they do not wish to receive mail, you would populate their Constituent Record with a Solicit Code of “Do Not Mail”.
Like most fields in Raiser’s Edge, Solicit Codes are very powerful, in that the drop down menu is customizable, and thus, unique to your organization. While several Solicit Codes are common across most of the organizations that we work with – for example, “Do Not Mail”, “Do Not Phone” – your organization can customize Solicit Codes for your own unique needs. For example, say your organization is running a weekend-long phonathon, you will want to have a very specific Solicit Code populated that indicates, “Do Not Phone On Weekends”.
Thus, your organization can create very specific and tailored Solicit Codes to meet your Constituents’ needs.
Solicit Codes are very convenient in that they are extremely easy to query upon. What I mean by that is when the time comes to generate lists of Constituents out of Raiser’s Edge, for example, a specific group of Constituents that you have identified to send an Appeal to, it is very easy to identify, through query, those Constituents who have a Solicit Code of “Do Not Mail” or "Do Not Solicit" populated on their record.
The key points to remember about Solicit Codes are:
1) Ensure you are populating your Constituents' contact preferences through the use of Solicit Codes.
2) Ensure you keep the Solicit Codes up to date for each Constituent, as frequently their contact wishes will change over time.
3) Ensure to query on your Solicit Codes before you ever contact a group of Constituents to be certain that you are eliminating from that contact list any Constituent that has requested not be contacted.
Furthermore, make sure that the query is specific enough to not only exclude those with a specific Solicit Code, such as “Do Not Solicit”, but that it also excludes those that have a very specific Solicit Code populated that may be related to the means by which you are contacting this group, such as “Do Not Phone On Weekends”.
One thing to note about Solicit Codes….you will see there is a check-box on the BIO1 Tab that indicates “Do Not Email”. Many organizations choose to use BOTH this check box and a Solicit Code of “Do Not Email”. If your organization chooses to track this in both places, ensure you are being consistent across EVERY record that has the check-box checked off.
Solicit Codes are not the same as the Do Not Contact option available to you for specific phone numbers. Solicit Codes are intended to be slightly more general than that…ie, if the Constituent does not want any phone calls at all, you would use a Solicit Code of “Do Not Phone”. If, on the other hand, a Constituent has several different phone numbers populated on their record – eg, Home, Business, Parent -- and has requested not to be contacted via one specific phone you would use the Do Not Contact feature for that specific phone number only, not an overall Solicit Code.
As discussed, you can create and customize a limitless number of Solicit Codes to identify all possible rules of contact. It is important, however, that Solicit Codes are not duplicated and that you are not tracking the same information by more than one Solicit Code phrased slightly differently. For example, in your Solicit Code drop down menu, you would NOT want to have one Solicit Code that says “Do Not Phone” and another Solicit Code that says “No Phone Calls”. Ensure that any information you are tracking is only tracked in one location. This will ensure your query results are accurate when the time comes to retrieve the information from Raiser’s Edge.
It is also essential that the names given to Solicit Codes are as self-explanatory as possible so as to prevent confusion as to what is actually being tracked.
Two “take aways” to remember about Solicit Codes:
1) They are a short two or three word phrase that specifically describes contact rules between your organization and the given Constituent.
2) They are very easy to query upon, and thus are extremely beneficial to you in maintaining healthy relationships with your Constituents.
If you ever have any questions about Solicit Codes, or any other Raiser’s Edge question or technology issue, please email me at plucas@resolutionstech.com and perhaps your question will become my next Blog!
Thanks for reading my blog, and don’t forget to tour the website and check out Robin’s Blog too!
Welcome to October! Kids back to school and settled into their daily routines, Canadian Thanksgiving behind us, but when’s the next long weekend??
For those of our clients that live in more temperate zones than us -- Philadelphia, New Jersey, and our newest client in California – YES! California! – trust me when I say these dank, cold, wet October days in Canada are enough to make one yearn for warmer climes! The mornings are dark and cold, and May seems a long time away!
Its also the time of year when germs seem to be at their most virulent, and my daughter and I are taking turns sneezing on each other….
And it’s a busy time of year for all….we’ve got Halloween just around the corner, and then end of the year celebrations rushing towards at supersonic speed….But for now, let’s take a bit of a break, breathe a deep sigh, grab a coffee and spend the next 10 or 15 minutes discussing the most appropriate use of Solicit Codes in Raiser’s Edge.
Solicit Codes are populated on the BIO1 Tab of the Constituent record and are essential in maintaining a healthy relationship with all of your Constituents, most notably your key donors. Solicit Codes are used to identify and track rules of contact that exist between that specific Constituent and your organization. For example, if a Constituent has indicated to you that they do not wish to receive mail, you would populate their Constituent Record with a Solicit Code of “Do Not Mail”.
Like most fields in Raiser’s Edge, Solicit Codes are very powerful, in that the drop down menu is customizable, and thus, unique to your organization. While several Solicit Codes are common across most of the organizations that we work with – for example, “Do Not Mail”, “Do Not Phone” – your organization can customize Solicit Codes for your own unique needs. For example, say your organization is running a weekend-long phonathon, you will want to have a very specific Solicit Code populated that indicates, “Do Not Phone On Weekends”.
Thus, your organization can create very specific and tailored Solicit Codes to meet your Constituents’ needs.
Solicit Codes are very convenient in that they are extremely easy to query upon. What I mean by that is when the time comes to generate lists of Constituents out of Raiser’s Edge, for example, a specific group of Constituents that you have identified to send an Appeal to, it is very easy to identify, through query, those Constituents who have a Solicit Code of “Do Not Mail” or "Do Not Solicit" populated on their record.
The key points to remember about Solicit Codes are:
1) Ensure you are populating your Constituents' contact preferences through the use of Solicit Codes.
2) Ensure you keep the Solicit Codes up to date for each Constituent, as frequently their contact wishes will change over time.
3) Ensure to query on your Solicit Codes before you ever contact a group of Constituents to be certain that you are eliminating from that contact list any Constituent that has requested not be contacted.
Furthermore, make sure that the query is specific enough to not only exclude those with a specific Solicit Code, such as “Do Not Solicit”, but that it also excludes those that have a very specific Solicit Code populated that may be related to the means by which you are contacting this group, such as “Do Not Phone On Weekends”.
One thing to note about Solicit Codes….you will see there is a check-box on the BIO1 Tab that indicates “Do Not Email”. Many organizations choose to use BOTH this check box and a Solicit Code of “Do Not Email”. If your organization chooses to track this in both places, ensure you are being consistent across EVERY record that has the check-box checked off.
Solicit Codes are not the same as the Do Not Contact option available to you for specific phone numbers. Solicit Codes are intended to be slightly more general than that…ie, if the Constituent does not want any phone calls at all, you would use a Solicit Code of “Do Not Phone”. If, on the other hand, a Constituent has several different phone numbers populated on their record – eg, Home, Business, Parent -- and has requested not to be contacted via one specific phone you would use the Do Not Contact feature for that specific phone number only, not an overall Solicit Code.
As discussed, you can create and customize a limitless number of Solicit Codes to identify all possible rules of contact. It is important, however, that Solicit Codes are not duplicated and that you are not tracking the same information by more than one Solicit Code phrased slightly differently. For example, in your Solicit Code drop down menu, you would NOT want to have one Solicit Code that says “Do Not Phone” and another Solicit Code that says “No Phone Calls”. Ensure that any information you are tracking is only tracked in one location. This will ensure your query results are accurate when the time comes to retrieve the information from Raiser’s Edge.
It is also essential that the names given to Solicit Codes are as self-explanatory as possible so as to prevent confusion as to what is actually being tracked.
Two “take aways” to remember about Solicit Codes:
1) They are a short two or three word phrase that specifically describes contact rules between your organization and the given Constituent.
2) They are very easy to query upon, and thus are extremely beneficial to you in maintaining healthy relationships with your Constituents.
If you ever have any questions about Solicit Codes, or any other Raiser’s Edge question or technology issue, please email me at plucas@resolutionstech.com and perhaps your question will become my next Blog!
Thanks for reading my blog, and don’t forget to tour the website and check out Robin’s Blog too!
Thursday, July 23, 2009
Peter's 2nd Blog -- Constituent Codes
Welcome to Peter’s 2nd Blog!
Today we’ll be talking about Constituent Codes in the Raiser’s Edge® database system.
It is common for organizations that use Raiser’s Edge® to misuse several of the tables / data entry fields throughout the Constituent Record, and we will discuss more of those in future blogs.
It is crucial, when tracking information in your database, that you follow two simple and fundamental policies:
1) Always track specific information in the pre-specified fields within Raiser’s Edge®
2) Never track the same information in more than one location
This is important, as when it comes time to both query and report on the data, you will pull specific information from specific fields.
Constituent Codes are one of those tables in Raiser’s Edge® that are frequently misunderstood and misused. Also, an organization may also have far too many Constituent Codes populated in the table.
First off, what is a Constituent Code?
A Constituent Code defines the relationship a given Constituent has with your specific organization.
In other words, a Constituent Code tells you why the Constituent is in your database in the first place and how their relationship with your organization has changed over time.
The Constituent Code should be a one or two word, very specific, self-explanatory description of how this particular individual or organization is related to your organization.
Examples of Constituent Codes may include Alumni, Board Member, Donor, Employee, Friend, Prospect, Supplier, & Volunteer.
It is important to note that Constituent Codes are very organization / industry specific and differ depending on the type of organization and the type of Constituents.
For example, a university or college may have a Constituent Code of Alumni or Student, whereas neither one of these would be appropriate for, say, a Hospital Foundation.
The number of Constituent Codes that you have populated in the Constituent Code drop down menu can vary however in most circumstances they should not exceed 20.
With the additional optional Raiser’s Edge® modules that your organization may have installed, it is very easy to track the information you need to without having an abundance of Constituent Codes. For example, you can have one, rather generic Constituent Code of “Prospect” and then further define the type of prospect via the optional Prospect Tab.
In a similar way, you can have a single Constituent Code of “Volunteer” and further define the type of Volunteer and their tasks via the optional Volunteer Tab.
Each Constituent record in your database should have at least one Constituent Code listed, while some may have several. For example, if you have a Constituent that is both a Volunteer and a Donor, then that Constituent should have two codes populated.
It is also important to note that the Date To and Date From fields should be utilized along with the Constituent Code, thus making it very easy to see the transition that your Constituents make with their relationship to your organization over time. For example, if a Constituent becomes a volunteer, you would populate their record with a Constituent Code of Volunteer, use the Date From field to indicate the date they first volunteered and then, if/when they cease their volunteering activities with your organization, you can use the Date To field to indicate the date they ceased being a Volunteer.
Using the Date To field provides the additional benefit of not needing additional Constituent Codes to indicate former relationships, eg Ex-Board Member, Ex-Employee, Ex-Volunteer. These can be identified simply by having the Date To field populated.
It is essential that the names given to Constituent Codes are as self-explanatory as possible so as to prevent confusion as to what is actually being tracked.
A tremendous benefit of Constituent Codes is that they are extremely easy to query upon. For example if you want a very easy way to count or to list, for example, all of your donors who are also volunteers, this becomes a very simple query to run if you are using Constituent Codes to track that information.
Note that the Constituent Code is populated via the BIO2 tab of the Constituent record, and the code that you select for a given Constituent is displayed in red at the bottom on the BIO1 Tab.
Two “take aways” to remember about Constituent Codes:
1) They are a one or two word, very specific explanation of how the Constituent relates to YOUR organization.
2) Every Constituent should have at least 1, some Constituents may have several.
If you ever have any questions about Constituent Codes, or any other technology issue, please email me at plucas@resolutionstech.com and perhaps your question will become my next Blog!
Thanks for reading my 2nd Blog, and don’t forget to tour the website and check out Robin’s Blog too!
Today we’ll be talking about Constituent Codes in the Raiser’s Edge® database system.
It is common for organizations that use Raiser’s Edge® to misuse several of the tables / data entry fields throughout the Constituent Record, and we will discuss more of those in future blogs.
It is crucial, when tracking information in your database, that you follow two simple and fundamental policies:
1) Always track specific information in the pre-specified fields within Raiser’s Edge®
2) Never track the same information in more than one location
This is important, as when it comes time to both query and report on the data, you will pull specific information from specific fields.
Constituent Codes are one of those tables in Raiser’s Edge® that are frequently misunderstood and misused. Also, an organization may also have far too many Constituent Codes populated in the table.
First off, what is a Constituent Code?
A Constituent Code defines the relationship a given Constituent has with your specific organization.
In other words, a Constituent Code tells you why the Constituent is in your database in the first place and how their relationship with your organization has changed over time.
The Constituent Code should be a one or two word, very specific, self-explanatory description of how this particular individual or organization is related to your organization.
Examples of Constituent Codes may include Alumni, Board Member, Donor, Employee, Friend, Prospect, Supplier, & Volunteer.
It is important to note that Constituent Codes are very organization / industry specific and differ depending on the type of organization and the type of Constituents.
For example, a university or college may have a Constituent Code of Alumni or Student, whereas neither one of these would be appropriate for, say, a Hospital Foundation.
The number of Constituent Codes that you have populated in the Constituent Code drop down menu can vary however in most circumstances they should not exceed 20.
With the additional optional Raiser’s Edge® modules that your organization may have installed, it is very easy to track the information you need to without having an abundance of Constituent Codes. For example, you can have one, rather generic Constituent Code of “Prospect” and then further define the type of prospect via the optional Prospect Tab.
In a similar way, you can have a single Constituent Code of “Volunteer” and further define the type of Volunteer and their tasks via the optional Volunteer Tab.
Each Constituent record in your database should have at least one Constituent Code listed, while some may have several. For example, if you have a Constituent that is both a Volunteer and a Donor, then that Constituent should have two codes populated.
It is also important to note that the Date To and Date From fields should be utilized along with the Constituent Code, thus making it very easy to see the transition that your Constituents make with their relationship to your organization over time. For example, if a Constituent becomes a volunteer, you would populate their record with a Constituent Code of Volunteer, use the Date From field to indicate the date they first volunteered and then, if/when they cease their volunteering activities with your organization, you can use the Date To field to indicate the date they ceased being a Volunteer.
Using the Date To field provides the additional benefit of not needing additional Constituent Codes to indicate former relationships, eg Ex-Board Member, Ex-Employee, Ex-Volunteer. These can be identified simply by having the Date To field populated.
It is essential that the names given to Constituent Codes are as self-explanatory as possible so as to prevent confusion as to what is actually being tracked.
A tremendous benefit of Constituent Codes is that they are extremely easy to query upon. For example if you want a very easy way to count or to list, for example, all of your donors who are also volunteers, this becomes a very simple query to run if you are using Constituent Codes to track that information.
Note that the Constituent Code is populated via the BIO2 tab of the Constituent record, and the code that you select for a given Constituent is displayed in red at the bottom on the BIO1 Tab.
Two “take aways” to remember about Constituent Codes:
1) They are a one or two word, very specific explanation of how the Constituent relates to YOUR organization.
2) Every Constituent should have at least 1, some Constituents may have several.
If you ever have any questions about Constituent Codes, or any other technology issue, please email me at plucas@resolutionstech.com and perhaps your question will become my next Blog!
Thanks for reading my 2nd Blog, and don’t forget to tour the website and check out Robin’s Blog too!
Monday, July 13, 2009
Peter's 1st Blog
Hello Blog Reader!
Welcome to Peter’s first blog! There’s a good chance you’ve either met me in person or spoken to me on the phone at one time or another if you are a client of Resolutionstech…if you’re not, you should be! If you take a look on the “Company” page on the website, you’ll see a goofy picture of me --- of all of us here, actually --- Trust me, I’m not nearly as bald as I appear!
So what’s this blog all about? Plenty of excitement, a little humour, hopefully impart some wisdom here and there….There will be regular postings on a wide range of subjects, though I imagine I will focus primarily on questions, issues, and commentaries related to Donor Database Management and on-line fundraising tools. As we go forward, please email me any questions, comments or suggestions and I could turn your question into my next blog: PLucas@RESolutionstech.com
So, since this is my blog after all, a little bit about me…My name is Peter Lucas and my role here at RESolutionstech is a varied one. As some of you will know, I work a lot one-on-one with our clients to assist them in using both Raiser’s Edge and the Artez on-line system more effectively and comprehensively. We all wear many hats around here, and that is what makes each day both challenging and rewarding.
In my next blog I shall be talking about Constituent Codes in Raiser’s Edge….what are they and how are they best used? Future blogs will look at things such as how to best use User Defined Fields in Artez and why posting gifts by batch in Raiser’s Edge is a better method than inputting them manually.
Any issue or problem or question that you think others could benefit from and would make a good blog, well, I want to hear from YOU!
Thanks for taking the time to read my first blog and watch this space for more to come soon.
Tour the website, and don’t forget to check out Robin’s blog too!
Welcome to Peter’s first blog! There’s a good chance you’ve either met me in person or spoken to me on the phone at one time or another if you are a client of Resolutionstech…if you’re not, you should be! If you take a look on the “Company” page on the website, you’ll see a goofy picture of me --- of all of us here, actually --- Trust me, I’m not nearly as bald as I appear!
So what’s this blog all about? Plenty of excitement, a little humour, hopefully impart some wisdom here and there….There will be regular postings on a wide range of subjects, though I imagine I will focus primarily on questions, issues, and commentaries related to Donor Database Management and on-line fundraising tools. As we go forward, please email me any questions, comments or suggestions and I could turn your question into my next blog: PLucas@RESolutionstech.com
So, since this is my blog after all, a little bit about me…My name is Peter Lucas and my role here at RESolutionstech is a varied one. As some of you will know, I work a lot one-on-one with our clients to assist them in using both Raiser’s Edge and the Artez on-line system more effectively and comprehensively. We all wear many hats around here, and that is what makes each day both challenging and rewarding.
In my next blog I shall be talking about Constituent Codes in Raiser’s Edge….what are they and how are they best used? Future blogs will look at things such as how to best use User Defined Fields in Artez and why posting gifts by batch in Raiser’s Edge is a better method than inputting them manually.
Any issue or problem or question that you think others could benefit from and would make a good blog, well, I want to hear from YOU!
Thanks for taking the time to read my first blog and watch this space for more to come soon.
Tour the website, and don’t forget to check out Robin’s blog too!
Subscribe to:
Posts (Atom)