Discovery Sessions

• Video of Current and Future State – Internal Process conversation
• Video of Current and Future State – End User Process conversation

Process Overview

When a development officer identifies a prospect (mostly major gift, although some annual giving officers do have prospect assignments) they wish to cultivate, they submit an assignment request. All assignment requests are completed by the Prospect Development (PD) team. Currently, one PD staff member completes assignment requests, and one staff member serves as backup.

Prospect Management is tracked in ANDI through the creation of prospect records and prospect assignments. A prospect record is attached to an entity record but can include multiple entities. Once the prospect record is created, prospect assignments can be added. Prospect assignments designate development staff who will work to cultivate the prospect, so they are typically major gift officers. There is one primary assignment on each prospect record, and there can be one or more secondary assignments. Once a prospect assignment is created, that prospect is then part of the development officer’s portfolio. Prospect records are required for the creation of proposals.

Assignment requests are submitted in ANDI. Any required documentation or written permission for the assignment is sent to the Prospect Development email account. To initiate the request, the development staff selects the Add/Remove Assignment Request button on the entity record. An assignment request is automatically generated. From there, the development staff can add additional details to the request where it is housed on the Next Steps screen. Once submitted, a PD staff member receives the request on their home screen in ANDI. After checking that appropriate permissions have been granted where necessary, the PD staff can add the assignment. If the entity does not yet have a prospect record, they create the prospect record and link any additional entities. Then, they add the prospect assignments. Once all data has been added or updated, the request is marked complete on the Next Steps screen. The PD staff then sends an email to the development officer stating the request is complete.

There are pain points for both development staff and prospect development staff in this process. Documentation of permission for prospect assignments is required to make any changes or additions to an existing prospect record. However, this documentation cannot be submitted in the system. So, even though prospect assignments can be requested in ANDI, the process requires additional email communication. There is also no way to confirm in the system that the request is complete, so email notification is also required to finish the process.

Portfolio reviews are conducted on a unit-by-unit basis by PD staff. These reviews are usually conducted by sending an Excel file of all assignments, stages, and visit dates to the development officer. The development officer sends the spreadsheet back with any requested changes, and the PD staff makes the updates. The only way for a development officer to view their portfolio is to pull an excel report from ANDI or to open the staff metrics dashboard.

Prospect stages are used to note where the prospect is in their relationship with UT development. Some prospect stage changes are automated. When a contact report is entered, the prospect is moved to cultivation. When a proposal is entered, the prospect is moved to solicitation. If a proposal is funded, the prospect is moved to stewardship. However, most development staff indicate that they prefer manual changes to the prospect stage.

Opportunities

In-System Workflow & Communication: When a development officer is requesting an assignment to an existing prospect, allow for a workflow that prompts the current primary assignment to approve the secondary assignment or changes to the prospect. Once the primary assignment has approved the changes, prospect development will then be alerted to make the updates. Development officers could also send messages directly that could serve as a paper trail or permissions for documentation purposes.

Prospect Update Timeline: Allow for a historic record of changes on the prospect record. Have a separate section where current managers can see the updates made to a prospect over time. This will allow them a better understanding of the relationship the prospect has had with UT.

Prospect Management Workspace: development staff would like to be able to view their entire portfolio on a single screen that would include pertinent information such as assignment status (primary, secondary), stage, active proposals, visit dates, next steps, etc. They could easily sort and filter their portfolio by these criteria. They could also submit update requests directly from this screen (changes to stage, changes to assignments, etc.)

Complex and Personalized Portfolio Segmentation: Allow development staff to create their own segments in their portfolio. This would allow the development staff to view their portfolio in customized groups according to criteria that is valuable to their own workload (businesses vs. Individuals, proposals to be delivered this FY vs. those not being solicited this year, prospects that might support a specific initiative, etc.). This would avoid having to create special codes so different units can pull special lists of prospects.

Suspect Lists/Pools: PRM spends time validating and researching potential development suspects. Create an easily accessible list of validated suspects that can be pushed to relevant development staff. This pool could also include individuals that have positive changes in their wealth screening or engagement scores. These individuals could automatically be flagged for attention by unit.

Improve Prospect Record Coding: Remove the active/inactive designation on prospects – this will be determined by an active prospect assignment. Remove the start dates and stop dates – this will be noted in historical changes to the prospect record. There is no need to continue coding prospects as multiple or single (to denote number of associated entities). There is no need to code every prospect by campaign code (which is currently just used to denote fiscal year). Streamline the prospect record to only include the most important data. Allow development staff to use the segmentation feature to categorize prospects in their own portfolio.

Prospect Disqualification: Sometimes prospects are completely disqualified, but it can be difficult to find the reason since it might be buried on the entity record. Allow for more descriptive coding when a prospect is disqualified.

Mass Prospect Transfers & Updates: It is difficult to move a prospect portfolio from one assigned DO to another. All changes must be made manually, one record at a time. Allow for access at the PD staff level to modify assignments in a batch (either to inactivate, or to update assignment to a different development officer).

Prospect Data Pushes: Notify assigned development officers when a birthday is coming up, when a pledge payment is coming up/is overdue, when a change is made to their entity record (new employment, new address, etc.). It would be ideal for notifications to be pushed to the home page when updates are made on a shared prospect. This could include when someone visits a prospect, when a next step is entered, or when a proposal is entered. This will keep all development staff assigned to the prospect up to date on the prospect’s moves.

Giving Analysis: Provide a better overview of an entity’s giving, not just totals or allocations, but consecutive years of giving, areas of interest, day of giving participation, event giving, telefund pledges, payroll deduction or recurring pledges, and responses to solicitations.

Contact Report Drafts: Many DOs go on visits and want to be able to enter quick notes or voice memos in the system before returning to flesh out a contact report/next step. Allowing them to save this info in the system would streamline their process.

Constituent Photos: Include photos of prospects on their record.