Functional requirements

In this section, we're going to delve more deeply into the functional areas supported by CiviCRM. We'll be reviewing the kinds of questions to ask, often of a more technical nature that will help in planning your implementation. These topics and questions, in our view, are the top-level broad-stroke issues that should be sorted out before specific workflow matters are examined.

Contact record management

CiviCRM has three basic types of contacts: individuals, households, and organizations. The fields and kinds of relationships that can be created may vary by the type of contact. For example, individuals have first and last names, current employer and job title, while organizations have an organization name, a legal name, and employees. CiviCRM's rich model for storing address, phone, and e-mail information is shared by all three types of contacts.

Contact subtypes

In some cases, it is possible to identify unique constituent subtypes. Contact subtypes in CiviCRM extend the three basic contact types, allowing you to further segment your constituent records. A contact may only be assigned a single primary contact type (for example, individual), but may have multiple subtypes assigned. Most organizations using subtypes will make them relatively exclusive, meaning only one subtype generally applies for a given contact. For example, students at a primary school are never teachers, though at a university it is possible for an instructor to also be a student. In the latter example, you might find yourself applying two subtypes to a single contact.

Try to identify subtypes early in your process, as it will help structure relationships and keep your data organized. Special relationship types can be set up that only allow a contact subtype at one or both ends of a relationship, such as teacher and student subtypes being the only ones allowed in a teaches/is taught by relationship. Custom data fields may also be created that apply to a single or multiple subtypes, such as the classroom of a primary student return. This is actually the main reason for setting up contact subtypes. It is recommended to set up a contact subtype if you are sure you want to track custom data for the type of constituent. These fine-grained approaches to data fields and relationship types help reduce clutter (the field and relationship types are not visible unless they apply to the contact type) and help improve data consistency (staff are not able to record information that doesn't apply for a certain contact type).

Custom data

After identifying the types of constituents your organization interacts with (for example, granting agencies, staff, clients, volunteer lawyers, and donors at a free law clinic), determine the data to be tracked for each type. At this point, we're primarily interested in identifying the kind of information that the organization tracks for the individual, organization, household, or any subtypes you've constructed. Since this data is attached directly to the contact record, it will generally consist of attributes about the contact, such as their expertise or volunteer interests, rather than their interactions with your organization, such as what they did the last two times they came in to volunteer.

Let's take a moment to drill home that last point. As you begin using CiviCRM, you will find there are lots of ways to store data about constituents. At first, the different methods and storage places may seem duplicative or outright confusing. Should I store this information in a custom field in the contact record? Or create a new activity? Or save it in a note? Or does it belong someplace else?

When creating custom fields (which will be discussed in more detail later), the important question to ask is: what type of data am I extending? Is this an attribute of the contact himself/herself, or about the communication I had with him/her? Is this data type common to most contacts or unique to this one, and consequently should I create a field to segment and store it for all records, or simply add it as a note to a single record? And most importantly, what would be logical from the user perspective, where would the user look for this data?

Different groups of constituents will often need to have different types of custom fields used to track information about them. For example, whether donors prefer a single annual tax receipt, or one per donation, the policy area interests of an organizational contact, and what an individual's volunteer interests are. Before trying to capture these needs, either through interviews or examining existing data, it may be helpful to review the material in later chapters where we discuss where the data should reside and how you may want to structure the field itself (for example, as text or integers, Yes/No checkboxes, single or multi-select fields, and so on).

E-newsletters and bulk e-mails

Your organization probably sends, or could benefit from sending, blast or bulk e-mails, such as newsletters and appeals. CiviCRM is good at sending e-mails to lists and tracking which ones are opened, clicked through, and forwarded. Ask the following questions about your bulk e-mail needs:

• What bulk e-mail lists exist, and are planned?
• How are contacts added to the list? Ensure that appropriate authorization is being acquired for every bulk e-mail sent to every e-mail address. Also, make sure there are appropriate mechanisms in terms of prominent website blocks and subscription enticements so that you have enough list growth to feed your contact funnel.
• How many custom templates with graphics are required for each e-mail list? Sometimes, different communication products are mailed to the same list, with each requiring its own template.
• How big is each list and how often is it mailed? This may affect server sourcing in terms of CPU resources, bandwidth, or perhaps e-mail caps.
• Spend some time on determining how mail servers are blacklisted and what this means for your configuration.

Beyond the mechanics of configuring the system and designing the mailings, discuss how the different departments or office roles will coordinate mass e-mail scheduling.

Payment processing

Will your CiviCRM installation need to accept online payments? If you want to accept online payments for events, memberships, or donations you will need to set up arrangements with an online payment processor such as PayPal, Authorize.net, or any of the other processors CiviCRM supports integration with.

One important consideration when selecting a payment processor is whether you need recurring payment support. Getting donors to set up recurring monthly payments provides a steadier and generally larger donation revenue stream, but not every payment processor supports that functionality. If recurring support is something you require, be sure to research the processor options available with regard to this feature. You will also need to check that the popular payment methods in your area are supported.

There are a number of different service charge models employed by different payment processors. You will be able to compare and shop better if you know the average number and amount of transactions you process. You may be able to get a better deal if you consolidate payment processing with a single provider. For example, including a Point of Sale (PoS) terminal already used and potentially dealing with a credit union or bank that handles your checks may result in significant savings.

Tip

If you are just moving into electronic payment processing, be clear about your needs for accepting payment at the door of events. You may need a PoS terminal if there is no Internet connectivity.

Development and fundraising staff will be pleased to know that CiviCRM supports pledges of future gifts. When soliciting CRM requirements from staff, make sure to determine how they view their prospect funnel and what their needs are for segmenting contacts into different groups. They will probably have the most sophisticated needs in these areas in your organization, and may have techniques that can be deployed successfully for volunteer recruitment and event marketing.

Larger and older organizations are more likely to have direct mail and telemarketing campaigns. Gather information on the data export and import requirements for their systems (such as transfers to accounting software) as you work through your planning process.

Memberships and subscriptions

A membership can be defined as time-defined access to organization benefits. In traditional member-based organizations, a contact demonstrates support for the organization and alliance with the organization through membership, and will generally receive benefits and services as a result of that relationship. However, the CiviCRM membership model can also be used in organizations that sell subscriptions or other service-type offerings where the member receives access for a defined period of time.

Existing membership and subscription forms should be used when developing your statement of requirements. Ask if there are any changes desired in the information collected on the form. These fields, some of which will be custom-defined, will make up the profile used on the membership signup form. The form will generally list all available membership types, their costs and benefits, and their terms (who can sign up, how long they last, and so on). Pay particular attention to benefits that are to be automatically provided, including access to special areas of the website, free newsletters, discounts for events, premiums such as calendars or mugs to be delivered, and so on. Also note when special functionality is available only to certain membership categories, such as a youth newsletter or more communications to Platinum members.

You may also need to define what contact types are eligible for a given membership type, which in turn may influence how your signup forms are constructed. For example, if you have three membership categories available to organizations, and three available for individuals, you may decide to create two separate signup/renewal forms so you can target each respective audience more directly. When working through membership type configuration, consider whether there are any inheritance rules to consider. For example, do employees of a member organization inherit membership by virtue of their employment?

Some membership types may not be available for purchase, such as lifetime members earned through long service. Find out if these exist, and who would need to manage them. Ask about special workflows, such as membership application review steps, revocation of memberships, subscription refunds, or new subscriptions.

Events

As you review event management requirements, use signup forms from recent events to reveal the kind of data collected about participants and options required, such as breakout session selections and food preferences. Try to get forms for several events. If events are supposed to be the same, are there variations in the information collected on the form? Are they at different locations or times? Event templates can create similar events, but aren't worthwhile if there are too many variations.

More generally, are some events paid, and if so, can people pay at the door, by check, or online? Are ticket prices for different events the same? Complex price systems that are used repeatedly can be set up as easy-to-reuse price sets. Is space limited for the event, and how do you manage a wait list? Can someone be allowed to register multiple people at the same time? Do certain events require prerequisites or an approval process?

Many logistical requirements with an impact on CiviEvent won't be found on signup forms. For example, how are speakers for the event registered and are provisions required to give special guests free passes? What are the procedures to be followed at the door? Do people have to have a printed receipt or a mailed ticket in order to get it, or just be on a list of registrants? Are nametags provided?

Are blast e-mails used to invite registrations? Do your registrants often come to more than one event? If so, do you need to pre-populate the registration form used as a landing page for people's click-throughs with their name and other data? What reminders need to be sent prior to the event?

Do you need to provide a way for registrants to contact each other before, during or after the event? Is it important to protect their e-mails while providing this access? Should only names and organizations be shared? Is it okay if non-participants see the personal information being shared among participants?

Grant management

Does your organization provide grants or disbursements to individuals or organizations? Examples could be a grant for 2 month's rent, fellowships for artists, or program grants to organizations working in an environmental policy. The CiviGrant component helps organizations like yours by recording when applications are received, the decision to approve or turn down the application, when payments are made, and whether follow-up reports on the grant have been received.

You'll need to know what information is tracked about your grants. The fields in the application form are the best starting place; they are supplemented by internal forms, such as fields to record reviewers' ratings.

Although the CiviGrant component was not designed for tracking your organization's application for grants, some CiviCRM users have found it can be used for this purpose with only minor tweaking of field names. If your organization needs to track its grant applications, review the typical fields that are tracked, starting with application closing dates. Some may need to be supported through custom fields. If your needs extend beyond the structures provided in CiviGrant, consider using the CiviCase and/or CiviCampaign tools for this purpose.

Activities

CiviCRM uses the term activity to indicate any engagement of constituents or other actions related to your interaction with the contact. CiviCRM automatically records a number of activities, including donations received, registrations for events, memberships purchased, membership renewal reminders, and event reminder emails. You can also use it to manually record interactions such as meetings, phone calls, and e-mails sent from your normal e-mail client.

A robust use of activities within your organization will build relational depth into your data. If the goal of your CRM is to manage data for your constituents with a view toward understanding them better and interacting with them more knowledgeably, then activity records form a critical piece of the puzzle, providing the tools to track every piece of communication you have with the contact. While the full use of activities does require an administrative commitment (it takes some discipline to log every phone call or discussion against the contact record), the benefits are significant, as you will be creating a history of contact interactions that can be consulted later. Being able to pull up details of a call taken a few months ago, by a different staff person, can help quickly resolve an issue rather than forcing it to be addressed from scratch. Furthermore, that detailed history of communication is invaluable when you experience staff turnover or lack institutional history.

As you configure your system, ask if there other kinds of activities you would like to record about your constituents beyond the types preconfigured in the system. For example, will you use activities to track mail correspondence, speeches given by legislators on topics of concern to your organization, or media stories published by particular journalists or outlets, or integrate with Twitter to record tweets, including hash tags of interest?

Determine which activities and custom activities are to be tracked, and also what additional custom fields are needed to record details about the activity, such as a hardcopy correspondence file number, URLs to a speech, or a description of action items that should flow from the interaction.

Case management

Whereas activities record single specific actions or interactions, such as a meeting, phone call or e-mail, cases pull together multiple activities dealing with the same issue or concern, and allow them to be managed as a unit. Cases are very useful when it takes multiple steps over different days or months, perhaps involving multiple people, to resolve the problem or finish the work. In addition, a case can be configured in a structured timeline, where the full set of steps are defined and created as activities when the case is first opened.

Many organizations need to manage cases for clients or constituents. These cases may involve requests for a legislator to attend a speaking engagement, assisting a homeless constituent to find housing, or providing a client with treatment referrals of various sorts (mental health, addiction recovery, emergency income assistance, job placement, and so on).

The requirements for a case management system are much more complex than just supporting the activities involved in the cases. You will want to determine the following:

• The different types of cases your organization handles
• The kinds of custom activities each type requires besides standard ones such as opening cases and changing their status
• The workflows for different case types in terms of various kinds of activities (for example, intake, screening, referral, follow-up, and so on) that may occur at pre-defined or ad hoc times
• What statuses are used to track your cases
• What roles are involved in each kind of case activity
• What custom data is required for the case and its various activity types
• What resources, such as career counseling services available in your area, are needed for different case types
• What relationships clients may have with individuals or organizations external to your organization that need to be tracked in the system, such as with their physician, social worker, or parole officer
• What terms may need to be redacted during reporting, such as client names and e-mail
• What permissions are granted to individuals in different roles to view and edit information about their own cases or all cases

For those requiring structure and detail, it's worth investing the energy to define your requirements before you begin configuring the case type. Start by categorizing the types of issues or extended workflows you have with clients. Then outline the specific steps typically required to bring that issue to a resolution. Identify who the key players are, both within the organization (staff and management) and outside your organization (affiliates, partners, local agencies, etc.) who are potentially involved in the case process. Once you have these puzzle pieces together, begin the process of configuring the case. Remember to test thoroughly, and solicit feedback from staff, to ensure the case configuration strikes the necessary balance between structure and flexibility.

Campaigns

Does your organization create campaigns where there is a specific, focused fundraising effort which may be combined with a membership outreach program or special series of events? Do you define fundraising goals for periods of the year and build your communication plan around that effort? Are you involved in an annual election cycle, either trying to support certain candidates or seeking to promote specific issues and influence the public?

CiviCRM's campaign tools provide connections between other resources (such as a contribution page and an event, or a membership initiative and online survey), and your constituents. During your initial implementation of CiviCRM, you may not have the immediate need to build those links, as they are more likely to become useful once the system is implemented and actively in use. But take the time to ask questions about the links that could and should exist between your different organizational units as they collaborate to reach constituents more effectively.

Volunteer management and human resources

CiviCRM has a growing set of tools that can be implemented as optional extensions to the core software. These include tools for managing volunteers (specifically, at events) and human resources (your staff). Are either of these areas something you will use? If so, plan to install these extensions early in your implementation process and think through how they will be used. And note that your CiviHR system is usually separate from your main CiviCRM system because HR data is usually only accessible for a small part of the organization.

Roles and permissions

We will not get into all the details of technical configuration, but it is important that you determine what roles you should have (back office support, fundraiser, project manager, volunteer manager) and what data they should be able to access and manage. It is a good idea to create a matrix based on the permissions that the combination of CiviCRM and your CMS supports.

CMS integration

Integration between CiviCRM and Drupal, Joomla!, or WordPress involves people and content. Because CiviCRM is implemented directly in your website CMS, it bridges the gap between raw data in your database and the end user interacting with your organization through your website.

But not all contacts in CiviCRM will need to have user accounts in the CMS used to power your website. For example, your CRM may include all voters in a jurisdiction while your website is not designed to support logins for anyone but site administrators. However, in many cases, actions in CiviCRM, such as buying a membership, will lead to login access and extra permissions in your CMS. These may include access to member-only pages, a discussion forum, or self-serve contact profiles where users can update their address and phone details.

You should anticipate possible content crossover between your CMS and CiviCRM. One common case is sending newsletters with CiviMail containing teasers of articles in your CMS with links driving people to the full articles on your site. Another common crossover point is restricting access to the secure areas of your site based on the user's membership status, which will require additional extensions. If a person's membership has expired, you want to block their access and encourage them to renew in order to benefit from the member-only content. A third example is to use online event registration as a way to solicit interest areas for an individual. You can use that data to follow up at a later time and recruit for committee involvement.

While CRM systems are good at managing contacts and relationships, CMSes are good at managing content. In some cases, the strengths of CMS content management need to be applied to CRM contacts. For example, members of visual arts, music, or video artist organizations may need to have rich media associated with those contacts as well as have all of their dues and grant application transactions tracked. In these cases, the CRM contacts will need CMS user accounts and those accounts will have CMS profiles with rich media associated with them.

The growing number of Drupal modules, Joomla! extensions, and WordPress plugins that integrate with CiviCRM—particularly those that expose CiviCRM data to the CMS—provide increasing opportunities to develop cost-effective custom websites based on contact and relationship data. For example, an activist organization may want to display a mash-up of contact information, such as their photos, quotes on a topic, or a map, in which case the information is all coming from the CRM and the functionality driving it is coming from the CMS. In-house or external consultant resources will be able to assist in gathering your custom CRM requirements in these areas.

Implementation plan

After conducting interviews and soliciting input through surveys, and other means, with key users and stakeholders, you should be in a good position to develop a phased implementation plan that schedules the delivery of chunks of functionality over the life of the CRM rollout. Depending on your process and methodology, you might start working on some easy low-hanging fruit with users in one area, while the scope and requirements in other areas remain vaguely stated in a one-page plan. Alternatively, you might choose to have a multi-year plan with significant specifications for all phases in a set of documents.

In any case, your organization should recognize that its CRM initiative is not just a technology project. For each segment of constituents, the CRM plan should have a strategy targeting the number of constituents involved, the level of their involvement, the quality of their experience in the organization, and a clear sense of how this will help achieve the mission of your organization. Ideally, it will specify 10 to 15 metrics that will be used to measure how well the initiative assists in realizing the organization's objectives.

As part of this process, the organizational structure should be examined, and possible organization restructuring plans and processes considered. The engagement strategy for each segment of the constituents will be translated into work processes for Communications, Membership, Events, Fundraising, Volunteer Organizing, Grant Management, and Case Management. Where processes are automated, use cases will ensure that strategic objectives of the organization are kept in focus as user experiences are optimized.

The people side of the project should ensure that staff and volunteers are communicated with effectively, in light of your organization's culture. Engagement and involvement mechanisms should be used to address inevitable fear, uncertainty and doubt, and assist with initial and on-going matters of motivation. Where job responsibilities change and people need to begin using new systems such as CiviCRM, appropriate initial training and ongoing reinforcement training should be planned. Your goal, over time, should be to encourage consistent use of the most essential areas of the system, and progressive growth with the more advanced and scenario-specific needs.

The technology side of the project will include more or less formal plans covering the following:

• Installation
• Configuration
• Customization
• Data migration
• Graphic design
• Theming
• Testing
• Deployment
• Verification of the new system

The deployment plans may involve a phased rollout of new features or a big bang introduction to the new way of doing things. Particularly in the case of financial systems, consideration should be given to operating the old and new systems in parallel, for a reporting period or more, in order to make sure that the new system is operating correctly, and to determine the ways in which old and new reports differ in terms of the data they present.