We’re trying to build bridges between technologists, advocates, trainers and donors. Doing so requires intelligent matchmaking between these groups, which requires a smart and scaleable system for organizing, finding and connecting contacts. That’s why one of our first steps has been to choose, and figure out how best to use, a Constituent Relationship Management system, or CRM.
How did we decide what to use? We broke down our decision making process into a set of criteria. This included:
- Was it open source?
- Could we host it either locally or on our own server so that we could ensure security of the data?
- Was it customizable, allowing us to add on features as we need them?
- Could we use it to conduct searches of our contact base that are as granular as we want? (Maybe I want to find the only person in Montevideo who’s been trained on Quantum GIS).
- Does it use database software that would be interoperable with other databases we might have? (We also use a wiki to document lessons learned for digital advocacy, and need to be able to do a search that queries the content in that Wiki as well as content we’ve put into CiviCRM manually).
| Open Source? (Y/N) | Host it ourselves? (Y/N) | Granular fields and search capability? | Database Software? | |
| CiviCRM | Y | Y | Y | MySQL |
| Salesforce | N | N | Y | Unknown |
| Highrise | N | N | Y | MySQL |
Because it is open source, easy to host on our own servers, highly customizable and uses MySQL we went with CiviCRM. The advantage for us, now that we’ve got our install up and running, is that we have a lot of control over the platform.
But with that control comes a lot of decisions. As anyone who’s ever tried to make effective use of CiviCRM knows, it can be quite daunting. CiviCRM has a bunch of different ways to organize people and events: custom contact types, tags, groups, smart groups, and cases. What should you use each one for? Here’s how we have done it:
Out of the box, CiviCRM comes with three different contact types: individuals, organizations and households.
We’re using the custom contact types as our first tier, most broad-brush, way to organize contacts. Our different types, as you can see above, include individuals (i.e., Susannah Vila), ad hoc networks (i.e, Standby Task Force) and organizations (i.e., the engine room).
Underneath these three contact types come subtypes – our second tier organization tactic. As you can see above, for each individual there are a handful of subcategories. They are:
- Resource Provider – Anyone (both professional trainers and practitioners) with skill sets that it would be helpful for others to learn and with the time or interest in sharing these skill sets.
- Advocate – Someone working (in either organized civil society or on their own/with an informal group) to bring about social or political change in their country
- Media – Someone who produces content for a media outlet
- Donor – Someone engaged in grant giving
- Technologist – Someone who develops tools (software or hardware)
- Researcher – Someone who is or had been engaged in scholarly research activities
To create these content types in Civi navigate to “Customize Data” and then “Contact Types” under the Administer menu.
Tags:
From the beginning, we foresaw the possibility of a resource provider also being an advocate and vice versa. To give an example: If an advocate we know in Saudi Arabia recently took a “training of trainers” (ToT) course on Security in a Box, giving him the skills necessary to train others in his city on digital security, should I categorize him as both an advocate and a resource provider? That would get messy. Instead, I keep him as his primary identity of advocate, and use tags to drill down on all the different sub-categories of resource provider:
Using tags, we will be able to to create a continuum of skill sets that can be applied with equal ease to any type of person in our CRM. We’ll do the same for issue areas. This is necessary for us because most of the time people will have at least one skill set that is worth sharing even if their primary content type isn’t resource provider.
Groups:
If tags are used to store meta-information about people we interact with, groups contain meta-information about those interactions.
Examples: we engaged with quite a few individuals around data gathering for the Social Tech Census, and therefore made a group of everyone who gave us feedback on the project. We’ll be getting back in touch with them soon to close the loop. Another example: we made a group for field researchers that made the short list or were hired to assess ICT use and needs of civil society organizations in their countries for the TechScape project, which we will be able to refer to in the future if we are doing more research in the region. Yet another (last!) example: if I contact a Drupal expert and ask them to share information with an advocate putting together a cool project, and they do it, then I need to be able to keep them in the loop about the project they helped. I can do it by making a group for that project, and including them in it.
Smart groups are a way to form groups automatically in CiviCRM based on contacts’ meta information. We aren’t using them (yet).
Cases
Cases are collections of activities designed with a certain goal in mind. You can use cases for project management, and use tools like timelines, activities and roles for different team members, or for smaller scale tasks – for instance, “I need to find 5 individuals in Latin America with experience in crowdsourcing by October 1st.” We haven’t started using Cases (still using Basecamp and Google Docs for project management!) but will update this post when we have.
To get up and running with Cases you have to enable it at System settings –> Enable CiviCRM components and add CiviCases and then follow these
instructions for further configuration.
If there is one thing we learned from developing this categorization system for our CRM, it’s that setting up the tool is no picnic but coming up with a smart strategy is the real challenge. We are just at the beginning of the process and will no doubt be shaping our system based on needs that arise in the coming months!
If you made it to the end of this post, then perhaps you are thinking practically about choosing and using your own CRM? We would love to hear about your experiences – please let us know in the comments or get in touch.
Kristin Antin
Thanks for sharing – I also like to document our adventures into configuring software and apps for Kabissa, my organization.
We use CiviCRM as well and have used it since 2007! There are some things we do with it that perhaps you’d be interested in learning about, such as using it to power our searchable member directory, newsletters (that’s how we use groups), and manage registration and payment for Africa Roundtable events. We also use it for accepting donations via our website.
New territory we are moving into that we’d love to brainstorm with others on is more traditional CRM contact management. That is, using CiviCRM to monitor who we are in contact with and keep track of what we’d like to do with them or have them do with Kabissa, and then generating reports to help us gauge how we are doing and the impact we are having on their work. This includes for example African organizations joining and adding profile pages to our directory, presenting at an Africa Roundtable event, posting to our blog, etc.
Warm regards,
Tobias