A database upgrade is an excellent opportunity to examine prospect management practices. In addition to enhanced technology functionality, this transition can bring process changes, policy refinements, and opportunities for training and business conversations.

At UNICEF USA, we broke the mold of our old prospect management system, creating a new one with both guardrails and flexibility. Our new common prospect management criteria and language allow for enriched reporting and stronger data. By collaborating closely with frontline fundraising teams and deeply understanding their business, a prospect development team can help ensure greater adoption of the new database, better prospect management and, in turn, more successful fundraising.

Taking a Team Approach

A few years ago, UNICEF USA decided to switch to a new constituent relationship management (CRM) database. As development’s main liaison to the technology division, prospect development coordinated the conversion for all development teams. Since beginning this process, we have continued to work in partnership with frontline fundraisers.

Over the past few years, prospect development and frontline fundraising teams have been in conversation: This is how our business works; this is what needs improvement; these are the challenges of data maintenance; this is the report we need; and so forth. We have met with teams over a sustained time period to build and refine the prospect management system.

During pre-launch, each team nominated a frontline fundraiser to be a design lead to collaborate on the design and write test scripts. When the CRM went live, each design lead guided its initial team training, with support from prospect development. The design leads were critical to adoption because they were the ambassadors of the database to their immediate colleagues.

In addition to offering extensive training at launch, prospect development has led dozens of hours of ongoing training — including pipeline management, portfolio management and revenue entry, to name just a few. The team also offers three regularly scheduled trainings per month: Data 101; open office hours; and topic-specific training.

To provide immediate service and training, prospect development continues to maintain a ticketing system just for prospect management and data questions. We reply to over a dozen per day. Most are quick requests — assignments, record merges or questions with clear answers — but some raise important new business issues that require us to partner with the fundraising teams’ design leads to resolve.

Once the CRM launched, we wanted to define the role that each member of the division will play:

• Division/Team Leaders:
  • Define report requirements
  • Grant team members time to manage data
• Prospect Managers:
  • Maintain constituent records
  • Record all interactions with a constituent
  • Oversee their own portfolio within the database
• Design Leads:
  • Represent their fundraising team in conversations with prospect development about data needs
  • Maintain their fundraising team’s business rules
• Super-Users:
  • Be a knowledge base for routine activities and their team’s business rules
  • Understand how to fill out a revenue entry form and how revenue inputs affect reports later
• Prospect Development:
  • Ensure that development’s use of data and the database are in line with the division’s reporting needs
  • Ensure that development is in line with the organization’s data model and processes
  • Assign the prospect manager on constituent records
  • Merge duplicate records of development constituents
  • Prepare fundraising reports and guide staff on self-service queries
  • Audit development’s use of the database to preserve data hygiene
  • Train development staff on data and database
  • Liaise between the development division and the technology division

Significant Design Decisions

Throughout the design phase, prospect development required a uniform prospect management data model and language for the development division. However, understanding that each frontline fundraising team’s business is unique, we partnered with each to ensure the system would work.

Early on, four prospect management stages were created with unanimously agreed-upon names: Discovery, Engagement, Solicitation and Stewardship. We spent time listening to design leads explain their business so we could ensure these stages covered their needs. As an example of why these conversations were so important, one team initially requested seven stages, each with different names than first proposed. Setting four stages was a fundamental decision that now allows us to pull standard reports across the division.

Next, after considering many options, we concluded that each prospect must have at least one open strategy at all times, and it could be in any stage. In other words, if the prospect was rather cold, it might stay in Discovery for years, or conversely, if the prospect is paying a multi-year pledge, the strategy might be in Stewardship for years.

We decided that an ask would not be required. If one did occur, however, there could only be one ask per open strategy. This was a business decision, despite the system allowing multiple asks per strategy, so Prospect Development now runs an audit report to catch and correct these anomalies. When a frontline fundraiser has a new ask of a prospect, she must create a new prospect strategy and add the new ask to that.

A major shift in our division’s thinking, driven not only by the functionality but also by the blank slate, was the temporal nature of prospect strategy records. In our old system, we created one strategy per prospect per fiscal year, and named the strategy for the fiscal year in which it was started. While this fit internal budgeting needs, it did not reflect how donors behave.

As a result, we changed business rules and the semantics around opening and closing strategies. In the new system, a strategy may be started at any time and can remain open for as long as needed. The strategy name also includes the calendar year — not the fiscal year — in which it was started. The flexibility in prospect strategy records was a major factor in the institutional partnership team’s adoption of the system, as it better reflected their donors’ giving.

Another change driven by functionality was the ability for each constituent to have its own record. Indeed, we now require it. Before, for example, two spouses, a family business and a family foundation might be on the same constituent record. Now each has its own. This shows the complexity of relationships, allows us to better understand which giving vehicles donors are using, and honors how donors want to be recognized and stewarded.

Reimagining Portfolios and Pipelines

At UNICEF USA, a portfolio is comprised of prospect strategies, not of constituents. If a prospect has, for example, eight open strategies, they will appear in the portfolio eight times. As a pipeline is simply the subset of the portfolio with open asks, and a pipeline requires a separate line for each ask, our portfolios and pipelines have the same logic. We pivot on these reports to count constituents and constituent pipeline totals.

Shortly after the new CRM went live, we expanded our pipeline criteria to include any asks in Discovery, Engagement or Solicitation. Before, prospects were only included in Solicitation, which incentivized frontline fundraisers to put prospects prematurely into Solicitation instead of demonstrating accurately where the prospect was in the prospect management cycle. Our new method allows for more nuance in internal conversations about donors. Since an open strategy does not require an open ask, we are now able to capture all possible asks, but not force asks where the prospect is not ready.

Because open strategies are now included in our pipeline at all stages, it was important that we have a consistently applied definition of what activities comprise each stage and what indicates a change in stage. These can vary greatly for each team, and the design leads have spent a lot of time and effort defining stages for their teams.

One change driven by functionality was our new ability to assign roles at both the constituent level and prospect strategy level. This, again, was key in the institutional partnership team’s adoption because they manage such complex relationships with multiple staff members on a single account. With a wealth of roles that can be assigned, we defined how to include senior management, various development staff, program staff, prospects’ spouses, estate attorneys, board members and volunteers.

Finally, as we talked with teams about how to manage their portfolios and pipelines, we learned that we had no common understanding of likelihood; therefore, we defined it as the chance that an expected amount would be given by the expected date. In addition, each team had different definitions for low, medium and high likelihood; we eventually agreed that low is 0-50 percent, medium is 51-75 percent, and high is 76-100 percent.

Importance of Documentation

When you need to explain design decisions and new processes, it makes sense to document them.

Business rules clarify processes and expectations. Robust data plus powerful technology without business rules is insanity — a Wild West. Our development data and prospect management business rules alone total more than four pages.

Each frontline fundraising team — with prospect development’s support and encouragement — wrote its own data user guide with detailed how-to instructions and screenshots.

In addition, prospect development has been documenting its own work:

• For each report: Why it exists, who runs it and how to use the results
• For each Development appeal code: What it means and when to use it
• For each operations process: Why it exists, who runs it, which queries to use and step-by-step instructions

Altogether, the development division now has over a hundred pages of thorough data documentation; before, we had none.

Outcomes

In the past year and half, our development division has made significant progress in prospect management. Our biggest change was creating portfolios and associated pipeline information in the CRM for the corporate partnership, NGO partnership, foundation partnership and major gifts (individuals) teams. Through our uniform portfolio model, made possible by all of our design decisions, prospect development can create standardized reports across fundraising functions.

Our pièce de résistance is a division-wide pipeline, which we call the One Development Pipeline. It rolls up all of the largest asks for the chief development officer to review. The pipeline, combined with revenue received in this fiscal year, allow the chief development officer to make confident revenue projections.

Through the process of creating the One Development Pipeline, prospect development has learned that, to respond to any new request around data, reporting requirements will drive the input, which determine the design, business rules and training. Therefore, when we talk with frontline fundraising teams’ design leads, we always start with the question: When we finish this project, what report will you want to see to answer your business problem?

In total, prospect development, occasionally with the help of our technology team developers, has built over 400 CRM queries. Our regular reports, shared with all division members weekly, include portfolios, pipelines and revenue for each team, the One Development Pipeline, as well as other more specific requests.

We have placed 100 reports in a development “self-service” report folder within the CRM so frontline fundraisers can access and run them as needed. This puts information and decision-making power directly into their hands.

Of the 400 reports, over 30 are audit reports that prospect development runs to make sure the prospect management system is in balance. Some questions these reports answer are:

• Does each development constituent have a prospect strategy?
• Does each prospect strategy have only one associated pipeline entry?
• Is all revenue received tied back to its associated pipeline entry?
• Are there any gifts that have not been coded as acknowledged with a tax receipt?

The development division is setting itself up to make more data-driven decisions, to communicate across the division and organization with a common data-based language, and to preserve organizational knowledge.

Lessons Learned

In our switch to a new CRM database, we have learned:

• Involve frontline fundraisers to get their ideas and put data directly in their hands.
• Understand each team’s fundraising strategy. They must describe the business problem, and you must find a data solution.
• Have a point of view about the role of prospect management in fundraising. Do you know the phrase: “If you don’t stand for something, you’ll fall for anything?” That applies here. Stay strong with business rules; prospect development has not only a pipeline-level view across all fundraising teams, but also implements industry best practices. The more tentacles data have into the business, the fuller the picture of the donor relationship. Data should capture the complexity of the relationship, not smooth out the nuances.
• Remember data quality. Without clean data, fundraisers may doubt the validity of the entire system. A conversion will expose old data problems and possibly create new ones. Spend time creating the foundation of the house, including revenue coding, suppression codes, salutations and addresses, etc. All reporting and data-driven decision-making depends on it.

With new and emerging technology available, development’s data opportunities are growing. In the future, prospect development would like to make improvements in the following areas of prospect management:

• Stronger fundraising performance metrics across the division
• More robust use of the database for documenting donor strategies
• Analysis of pipeline accuracy, made possible now because each revenue transaction is tied back to its pipeline entry
• Fuller picture of a donor’s activities across the organization, not just development

In the end, the true measure of success of prospect management is the impact on sustained, long-term fundraising and, in turn, the organization’s mission.

---

To solidify our division’s culture around prospect management, I recently created tenets that form the rationale behind UNICEF USA’s Development business rules and processes.

UNICEF USA Development Data Tenets: Good data improves fundraising. When we have clean, consistent, usable data, staff can make strong decisions about donor strategy, fundraising program strategy, and resource allocation Everyone has a role to play with data. Regardless of their job function, each development division staff member contributes to the prospect management system. The data belong to the organization. Given that development data are a part of a larger set of data — the organization’s entire supporter file — they need to work seamlessly together. Data must be accessible. Others in the division and organization need to be able to access the information in a usable format for many years to come. Data must be secure. Donor privacy is the right thing to do, and strategy needs to be protected. Data should be complex, but not complicated. The complexity of development data should reflect the complexity of donor relationships. Maintaining institutional knowledge means maintaining donor relationships. Staff must record — in an accessible, secure location — all contact activity, prospect strategy, gift commitments and subsequent reporting requirements, and contact information. What comes out must go in. Setting report requirements is vital for ensuring robust data entry and quality.