When doing your advancement Constituent Relationship Management (CRM) implementation, you need input from a cross-functional team of stakeholders. This helps to understand the requirements and expectations across the board. Specifically, identifying what is required for the new advancement CRM in the way it’s configured and implemented that would enable and support the business needs of all your fundraising and engagement areas.

 

What’s more critical to consider is when those units are decentralized—whether that means different locations or reporting structures. For example, reporting structure could be related to other parts of the organization or diverging organizational structure (not all reporting to the same person.) 

 

Key elements may be taken for granted in a more centralized fundraising environment. But in a decentralized environment, you must make strategic decisions more carefully regarding time and effort. 

 

Here’s how to implement your new advancement CRM in a decentralized environment. 

Relationship Management

Establish a strategy around relationship management. Constituent management is usually a source of concern when moving toward a decentralized fundraising model. 

 

Assuming from a legacy standpoint, everyone had their own system in their world—it was easier to protect their constituents. However, once all the constituents come together in a single CRM; how do you manage these concerns? 

 

• “If I share my constituents, what will happen?” 
• “Will you poach them?” 
• “What happens if you’re talking to “my” constituents without me knowing?” 

 

To resolve this, the primary objective should be that every constituent belongs to the intuition, and decisions need to be made from that perspective. Designate a group or individual poised to “manage” constituents. This committee can evaluate conflicts that may arise in this decentralized fundraising environment. Once decided, this designation should be a part of a strategic plan or guidelines stating how they will manage the constituent. 

 

The constituent relationship manager or committee should act as a gatekeeper, coordinating every interaction collaboratively to maximize opportunities for the constituent to support the institution. In this scenario, everyone benefits from having a 360-degree view of all constituents, allowing them to see how they fully engage with the institution, including all the touchpoints.

Data Model

The second area needing focus in a decentralized CRM implementation is your data model. Again, the baseline assumption is that up until now, each site or decentralized group had an individual database. But now you must bring this information together. 

 

First, have a data expert from each bearing group come together and decide the standard data points across each fundraising group.

 

Is there an opportunity to agree on standard definitions for those that are different? For example, is the data more similar than different? Or could you move toward a best practice about a particular data point to help you standardize it across groups? 

 

Your last resort is to identify requirements for “site-specific” or “group-specific” data fields. 

Security Model

Finally, the third area to consider in the decentralized advancement CRM environment is your security model. Your security model should designate who gets to do what within the system. The recommendation—and most optimal way to collaborate—is that viewing a record is allowed across the entire institution. 

 

Remember, if you can’t see a record managed by a specific fundraising group or location, then that’s like having individual databases. Being able to view the information for all constituents should be the goal.

 

You have two options for editing and managing constituent information.

 

Option A: Establishes a completely centralized group for data management in which everyone needs to request changes made in your new advancement CRM. 

 

The upside of this scenario is that you have standardized data management, high data quality, similarity across the board, and it follows business rules. But the downside is this model is extremely resource intensive. Your institution may not be able to staff up a team to support a 100% centralized data model. 

 

Option B: Decentralized data management is aligned with the group managing the constituent relationship because they likely have the most updated data. In this aspect, the relationship manager or group managing the relationship must be equipped to take on the workload. 

 

In the distributed model, another committee to consider is a data governance committee and leverage representation in these distributed areas. The data governance committee helps make strategic decisions for managing decisions in this distributed model. Specifically, what data is being captured, how it should be captured, and the business rules around capturing data to make it the most useable and accurate for everyone.

 

Whether you choose Option A or Option B, what’s critical, is that you have a request and workflow process. But keep in mind that whoever is managing the constituent records does not absolve everyone else from being responsible for data quality. Users should still be accountable if they see incorrect or missing information and make that request to have information updated.