CRM for Extension – Evaluating the Basics

Stephen Judd is serving as the eXtension Foundation Customer Relationship Management Fellow. This post is an update on progress on this funded Fellowship from the USDA-NIFA New Technologies for Agricultural Extension (NTAE) Cooperative Agreement.

Virtually all customer relationship management systems (CRM) will have some common core functionality. These features are prerequisites for a CRM to be useful, but the implementations can be different. As an early step in your evaluation, assessing how this core functionality works, how configurable it is, and how it fits with your use cases is important. 

Common functionality

• Contacts – the people you are keeping track of
• Accounts – a grouping of contacts, could be a business/company, farm, organization, household, etc.
• Lists / Campaigns – a set of accounts or contacts that share common attributes or interests
• Reports – customizable views of the data stored in the CRM
• Users – the staff who will be interacting with the CRM

People example

A CRM needs to be able to store information about people (contacts.) Typically, a contact will be a single record that has values for various attributes or fields (e.g., first name, last name, email, phone, address.) You should ensure that the provided fields will enable your use cases, or that custom fields can be easily added, given your organizational resources. 

Some attributes may require multiple values, like email. The contact record may have multiple fields – email1, email2, email3 – or it may have a separate record for each email address and allow you to relate them to the contact. Depending on what you know about the contacts you will be storing and how you plan to use the addresses, one method may be better than the other.

Considerations / Questions

• Object and fields – Does the CRM you are evaluating have the types of objects (contacts, accounts, etc.) you will need, based on your use cases? If not, is there a way to create custom objects or fields, given your organizational resources?
• Licensing / Pricing – What is the per user cost of the CRM? Is there a limit on contacts that can be stored? Is cost based on the number of contacts?
• Permissions / Privacy – What information can different users view and edit? Do you need to restrict access for certain users? Can attributes/fields have view/edit restrictions or is it at the object (e.g., contact) level?
• Types of records – Can there be different types of records and how does that work? You may want certain attributes only for certain types of records, for example, for volunteers you may want the year they started volunteering, but not want that field on other types of contacts.
• Lists / campaigns – How does the CRM handle creating lists of contacts? Can you send email to these lists directly from the CRM or do you need to export to another system? Is there a cost associated with sending emails? 
• Interactions – How can you track the interactions with contacts in the CRM? Are these visible to everyone, just the user recording them, or customizable? 
• Reports – How difficult is it to create reports and run them? Can the report information be exported for use in other programs or visualizations? How is access to reports controlled?
• Duplication – How does the CRM determine that records are duplicates of each other? Is there an easy way to merge them?
• Integration – Can the CRM be integrated with other systems you are currently using (e.g., event registration, mass email)? 
• Bulk data – What is the process to get existing data into the CRM?

Summing up

Given the personas and use cases you’ve compiled, evaluating the basic CRM functionality, as outlined above, will give you a good first pass at the CRM systems you’re evaluating. This will help you determine which ones should be evaluated further, and which are not suitable for your needs.

I welcome feedback and questions at stephen.judd@unh.edu 

Previous post: CRM for Extension – Use Cases