Raiser's as an Organization-Wide CRM tool - request for advice

F. O. · April 2015

My organization is positioning itself to expand the use of Raiser's Edge from the Development Office to other departments/geographies as a general contact management tool for the organization.

We have moved to cloud hosting as a first step to establish the infrastructure and access. But now are mulling over the best practices for the next steps - policies, configuration, training, support, etc...

I'm very much hoping to connect with others who have any experience/advice on the best way to move forward, things to be cautious about, what NOT to do, and so on.

Thanks in advance for your input!

Nicole S · April 2015

I don't know about as a CRM tool, but I have used it as a way for people outside of development to access contacts and it works pretty well. Training is a hurdle. And you need to be sure to have your security groups set up so that no one has access to change, delete or view information that they shouldn't. I have people outside of development typically set up as read-only and restrict them to view contact info only, not gifts or financial data.

Gina Gerhard · April 2015

I'll just throw into the conversation about considering if extending to this broader group of contacts will end up pulling them into mailings, appeals and event invitations when they perhaps should be excluded.

We ran into this when we entered our investment managers in order to have better access to their contact information. We didn't have any specific categorization/coding to tag them so they ended up in our annual meeting invitation - and we then realized that they thought that somehow they were EXPECTED to attend and this created an issue.

So I'd perhaps think through the 'what-if's' if you enter these additional constituents and how their data will work with the other development-based data you have in there. Perhaps you can structure their constituency coding or some other categorization to clearly mark they are in a specific 'category' of records vs. your other data?

F. O. · April 2015

Many thanks for your feedback! I noted the following from your responses:

- focus on training (this could be challenging due to offices being located around the globe..) and restrict access to view or edit only what's needed for their roles.

- Special coding to filter non-development contacts out of fundraising activity. I was wondering about the best way? Constituent codes, solicit codes, attributes?

Thanks again and I hope to hear more of your ideas/experiences

Nicole S · April 2015

We use a constituent code of "vendor" and you could similarly use a solicit code to help exclude them. But we have not had and issues and I put our vendors on mailings as well. And some of them GIVE!

Susan MaidaChurch · April 2015

I think what you have listed is a great start - I would suggest using a combination of constituency codes and attributes to segment your database. Depending on how your organization is set up, you can use the constituency codes to segment by department, and the the attributes to refine further. This should allow for more flexibility and give each department an opportunity to be able to view/mail appropriate donors. Plus - using the cominbation of the two will keep your tables smaller. I think solicit codes, when strategically used, are a good option for solicitation suppression or inclusion, but I wouldn't recommend it for segmentation. But those are just my thoughts...

Thanks,

Susan

F. O. · April 2015

This is all very helpful, thanks! And thanks for the advice against using solicit codes to segment, these suggestions are what I was hoping to get from posting on the forum.

We are currently updating the policy/standard operating procedures for inputting contacts into RE, now that there will be different departments in the database. Some departments are interested in organizations and others in individuals within the organization.. we need to provide guidance and flexible rules on how records should be added to avoid chaos..

If anyone has something they could share with me, please contact me at filsan.omer@cusointernational.org. Thanks!

Gina Gerhard · April 2015

As you mention, you have some staff interested in the organization and others interested in the people related to the organization. Here's an issue with identifying contacts that might be helpful to think through as you think through how you want to structure your information.

Raiser's Edge is structured to allow you identify individuals as 'Contacts' and then allows you a choose the Contact Type from a drop-down menu - but you can only pick ONE.
- So essentially you only have one way of coding Contacts -- and that's often not sufficient to handle the different ways that staff think of individuals at organizations.
What would work better is if they allowed you to select MULTIPLE contact types for a contact -- so that you could mark individuals as different types of contacts for different viewspoints/purposes.
- For example, we have our contact types structured as Primary, Secondary, Other and we try to only have one Primary contact selected for an organization. This serves our basic needs for general mailings, event invitations, etc. -- who is the most important person at the organization from this GENERAL perspective.
- But what about specific scenarios? We have other needs for contact coding - like who is the Grants Management contact, who is the Scholarship contact, who is the Financial Aid contact, etc.
- If we could use the Primary/Secondary/Other system but also then be able to pick some supplemental values, that would work for our needs. But we can't.
What Blackbaud suggests for these 'sub-coding' systems is to set them up as contact attributes. That works, but these codes are hidden from view on the contact's attribute tab and you can't see them either on the first screen or on any of the grid views. So often people don't realize there is this second way of coding contacts.
- We did use this to mark contacts who should receive gift acknowledgments - our Accounting department understands how to use this 'sub-coding' and it works for their purposes so they can direct the check to the correct person at the organization. And we actually commandeered an unused field on the main contact screen so we could add a visible code - as a workaround for the 'hidden' issue.
On the IdeaBank, you'll see many requests for making the way RE handles contacts more flexible. If they just allowed you to check MULTIPLE contact types that might solve a lot of the issues but right now you can't, so you're stuck.

Jennifer McHale · April 2015

We use Raiser's Edge as a CRM tool ... but only development has access to the database.

While it's great to have control over how the information is put into the system, it makes it very challenging to keep the contacts up-to-date (I just don't know everyone at every company and when they leave a job or start a new one!). We're now trying to figure out a system for keeping contacts current. That is definitely one item you will want to have in place - otherwise, your mailings will all go to the wrong people!

Good luck!

F. O. · April 2015

Thank you for the input about maintaining Contact information - a lot of food for thought!

Raiser's as an Organization-Wide CRM tool - request for advice

Comments

Categories